21 ms·

If people rant and rave about how hard pulse audio is to configure, then I can only imagine how much kick back there will be about having to configuring apparmo

by esaym 9y ago

If people rant and rave about how hard pulse audio is to configure, then I can only imagine how much kick back there will be about having to configuring apparmor etc. Just saying. Personally, I'll be keeping it disabled. I used to use selinux, but eventually stopped as I didn't find the constant headache of trying to figure out why something wasn't working was related to SE or not worth it.

SteveNuts 9y ago
Disabling SELinux is a mistake, especially now that there are tools that will scan the audit.log and tell you exact commands on how to fix each thing it finds. If you want to do something weird like allowing nginx or apache to serve your home directories, it takes maybe 5 minutes to google the correct se context to set on the directory and apply it, otherwise any standard installation works out of the box. There's literally no reason to turn it off nowadays, other than laziness/unwillingness to learn.
- rightos 9y ago
  How about lack of necessity? I isolate my systems in many ways, using vms, tunnels and network isolation, but SELinux just doesn't fall into that, if anything's getting compromised it's the service in question that's the problem. Just because something exists doesn't mean you have to learn it and it doesn't make you lazy for refusing to do so. Proper protections extend far beyond using tools like this. Additionally, if you're running a desktop system and software installation is a frequent task, you'll have to deal with that constantly, often many times for the same application. At some point you're going to give up and say it's not worth it. Most people can't even stand the GUI based notifications of Outpost or ZoneAlarm in my experience.
  - emmelaich 9y ago
    > it's the service in question that's the problem .. But that's what selinux limits -- the "blast radius" from a compromised service.
    - rightos 9y ago
      Precisely what I'm saying, the limitation to the blast radius is already there if you've done the isolation yourself and it's only that one service that gets hit. If your Web server is on a private network with your app server and your load balancer, there's no way it can attack your database server. Basically, policies are implemented at the network and host level rather than the process and file level.
      - emmelaich 9y ago
        The risk is that an app compromised could lead to local access which allows local (root/kernel) exploits.
      - angry_octet 9y ago
        You're entirely correct, but we've become infected with SOE-think. Eventually you are always going to have a compromised node, and defence/detection in the node is hard and constantly evolving. The kernel attack surface is still large and complicated. In contrast, network interfaces are well controlled. If people started with 'deny all' in their fw permissions then added the minimal necessary holes then lateral movement would be a lot harder. I think the best argument for selinux/apparmor is that a lot of application specific security hardening can be packaged into standard configs. In contrast, there is little to orchestrate this for VMs/containers/physical hosts. Inter-VM/CNTR network control seems difficult (open vSwitch). If we could have easily configured, hypervisor enforced firewalling and encrypted tunneling then that would be more useful confinement.
  - SteveNuts 9y ago
    SELinux is all about minimizing and isolating collateral damage after a service is compromised, so if you care about that at all I'd suggest leaving it on. Also, it's probably the best protection from a zero-day exploit there is.
    - rightos 9y ago
      Yeah what I'm saying is that I've already done so myself and have no need for SELinux. Proper network and VM isolation is far better than SELinux. I don't want it forced on me and will disable it. Not out of laziness, but due the lack of a purpose.
      - sleepydog 9y ago
        Security is best implemented in layers. VMs are not impermeable. Case in point: the VENOM vulnerability: https://access.redhat.com/articles/1444903 https://access.redhat.com/articles/1444903 , which was thwarted by SELinux's protections for virtual machines (sVirt).
        deleted 9y ago
        [deleted]
        deleted 9y ago
        [deleted]
        rightos 9y ago
        That's pretty sweet, if I had to manage my own VMs I'd definitely look into SELinux for that feature. I can see an argument for a defense in depth approach here, but if there's only one service per VM and that service is already restricted to only the stuff it needs to talk to on the network level I'm not convinced it makes much sense. As far as I know at least, SELinux won't be able to prevent kernel exploitation or the like.
        ungamed 9y ago
        It absolutely prevents kernel exploitation by stopping certain syscalls. I guess you can argue that it doesn't stop "The exploit" in syscalls it allows but it does prevent syscalls from being run.
- jron 9y ago
  I can think of a great reason to disable SELinux; you actually use linux for a workstation and don't want fight with it every time you install a new application.
  - Hello71 9y ago
    do you also do chmod -R 777 /?
    - xyzzy_plugh 9y ago
      That seems excessive. Why not just run as root?
    - yjftsjthsd-h 9y ago
      Pretty sure that actually breaks stuff
      - jameskegel 9y ago
        This is correct.
  - Spivak 9y ago
    But you don't. Almost all 'applications' run unconfined.
  - pjmlp 9y ago
    I can think of a great reason not to disable it, exposing $HOME to the world.
    - deleted 9y ago
      [deleted]
    - hobarrera 9y ago
      Have had SELinux for almost 10 consecutive years. $HOME has never been exposed. I've no idea what you're going on about.
- throw2016 9y ago
  Selinux will become useful when it precisely lists out what it disables with transparent explanations for assumptions made. And clear error messages or alerts when it has just disabled something with proper logging. Unlike with most open source software for things like selinux that disable a host of stuff by default, documentation cannot be an after thought. And why invent weird vague terminology, what is a context? Things are complex as it is and people need to get things done. To have to waste man hours that could be used more productively more than once only to figure out its caused by selinux 'silently' without any proper error messages or logging and you do the sensible thing and disable it.
  - Spivak 9y ago
    > what it disables with transparent explanations setroubleshoot > documentation cannot be an after thought Take a look at selinux-policy-doc, it's extensive. > what is a context It's a type. But 'type' as it refers to files means something else. It's just a label that describes what kind of file it is. user_home_dir_t is user files, httpd_sys_content_t is content that can be served by apache, nfsd_fs_t are files that that can be exported by NFS. > proper error messages or logging Every single denial is logged and it contains all the details why it was denied. You're asking for SELinux to log why it wasn't allowed which is done by setroubleshoot but isn't possible in general.
    - emmelaich 9y ago
      > Every single denial is logged Not quite true. Some need to have debug turned on. See my other comment.
- staticassertion 9y ago
  Building policy by just auditing is a bad idea - you'll end up with overly general roles. Policy building is best left to the author of the applications so that they can test against it and lock it down.
  - problems 9y ago
    So what's your suggestion? Just disable SELinux for that application if it's failing?
- emmelaich 9y ago
  I mostly agree with you but sometimes it is extraordinarily difficult to find out what went wrong. audit2allow and audit2why are often helpful but at least as often they offer the wrong solution. Did you know that some selinux violations are not even reported by default? This was the case for me; selinux transitions are prevented by a filesystem mounted _nosuid_. The failure is not reported because transition failures are apparently so common and unimportant selinux does not report them by default. Took me a looong time to troubleshoot this.
- naasking 9y ago
  > Disabling SELinux is a mistake, especially now that there are tools that will scan the audit.log and tell you exact commands on how to fix each thing it finds. If it were actually that easy, then you wouldn't need this step since SELinux would just do it for you. Clearly that isn't the case.
  - yorwba 9y ago
    SELinux can't tell which of those accesses were intended, and which were actual security violations it should keep preventing. That requires human intervention. Maybe it could be made more convenient by a tool that parses the log and automatically runs the commands when you answer the question with "y".
    - naasking 9y ago
      > SELinux can't tell which of those accesses were intended, and which were actual security violations it should keep preventing. That requires human intervention. Right, it requires intervention by a person who doesn't actually understand the minutiae of what the software is trying to do, so obviously they can make a properly informed choice as to what is and is not a security violation. Modern operating systems are so broken...
- hobarrera 9y ago
  > There's literally no reason to turn it off nowadays, other than laziness/unwillingness to learn. Sometimes is as simple as not having time for that. If I've urgent work to do, I can't stop my work and well my boss/client "hang on, I need to learn to configure SELinux first!". The fact that it DOESN'T work out-of-the-box immediately and needs for me to configure it (regardless of how well documented it is) is its major pitfall. These things need to work without adding ANY burden to the user. Otherwise, they'll end up disabled.
aidenn0 9y ago
I still can't get PA to directly work with my USB sound card. I ended up configuring alsa dmix for it (which is definitely not easy to configure), and pointing PA at dmix. Supposedly it should see the card arrive through hotplug and add it to the device list, but that has never happened.
- cat199 9y ago
  I've not had issues on this on Fedora (24+) - I did have to kill pulseaudio 1st though.. might try that if you have not already
- digi_owl 9y ago
  dmix is hard to configure?
  - aidenn0 9y ago
    Configuring ALSA to work properly with my USB sound was the single hardest thing I did on my gentoo box. The documentation ranges from terrible to nonexsitent and it is unclear how to generalize many of the example configurations.
- monksy 9y ago
  I have a mediabox which decided it was time to install PulseAudio for kodi. Which, that perceeded to complexly screw over audio over HDMI. (No idea why it was refusing to play audio until I disabled pulseaudio).
viraptor 9y ago
Having done all 3, I'd order them from the hardest as selinux, pulseaudio, apparmor. Out of these 3, apparmor has the most user-friendly tools to apply changes. It also allows you to easily turn off a single profile without disabling the whole system. Given those, I don't expect that many issues. But also, worth remembering that this is a proposal for an experiment. One of the things they're going to judge is how much does it affect regular users.
oliwarner 9y ago
Ubuntu has used AppArmor for years. Debian users will benefit from those years use.
upofadown 9y ago
People rant and rave about how pulseaudio is broken on their system. Pulseaudio is pretty easy to configure for most things. Sometimes it even (unexpectedly) configures itself!

by esaym 9y ago

SteveNuts 9y ago

Disabling SELinux is a mistake, especially now that there are tools that will scan the audit.log and tell you exact commands on how to fix each thing it finds. If you want to do something weird like allowing nginx or apache to serve your home directories, it takes maybe 5 minutes to google the correct se context to set on the directory and apply it, otherwise any standard installation works out of the box. There's literally no reason to turn it off nowadays, other than laziness/unwillingness to learn.

rightos 9y ago
How about lack of necessity? I isolate my systems in many ways, using vms, tunnels and network isolation, but SELinux just doesn't fall into that, if anything's getting compromised it's the service in question that's the problem. Just because something exists doesn't mean you have to learn it and it doesn't make you lazy for refusing to do so. Proper protections extend far beyond using tools like this. Additionally, if you're running a desktop system and software installation is a frequent task, you'll have to deal with that constantly, often many times for the same application. At some point you're going to give up and say it's not worth it. Most people can't even stand the GUI based notifications of Outpost or ZoneAlarm in my experience.
- emmelaich 9y ago
  > it's the service in question that's the problem .. But that's what selinux limits -- the "blast radius" from a compromised service.
  - rightos 9y ago
    Precisely what I'm saying, the limitation to the blast radius is already there if you've done the isolation yourself and it's only that one service that gets hit. If your Web server is on a private network with your app server and your load balancer, there's no way it can attack your database server. Basically, policies are implemented at the network and host level rather than the process and file level.
    - emmelaich 9y ago
      The risk is that an app compromised could lead to local access which allows local (root/kernel) exploits.
    - angry_octet 9y ago
      You're entirely correct, but we've become infected with SOE-think. Eventually you are always going to have a compromised node, and defence/detection in the node is hard and constantly evolving. The kernel attack surface is still large and complicated. In contrast, network interfaces are well controlled. If people started with 'deny all' in their fw permissions then added the minimal necessary holes then lateral movement would be a lot harder. I think the best argument for selinux/apparmor is that a lot of application specific security hardening can be packaged into standard configs. In contrast, there is little to orchestrate this for VMs/containers/physical hosts. Inter-VM/CNTR network control seems difficult (open vSwitch). If we could have easily configured, hypervisor enforced firewalling and encrypted tunneling then that would be more useful confinement.
- SteveNuts 9y ago
  SELinux is all about minimizing and isolating collateral damage after a service is compromised, so if you care about that at all I'd suggest leaving it on. Also, it's probably the best protection from a zero-day exploit there is.
  - rightos 9y ago
    Yeah what I'm saying is that I've already done so myself and have no need for SELinux. Proper network and VM isolation is far better than SELinux. I don't want it forced on me and will disable it. Not out of laziness, but due the lack of a purpose.
    - sleepydog 9y ago
      Security is best implemented in layers. VMs are not impermeable. Case in point: the VENOM vulnerability: https://access.redhat.com/articles/1444903 https://access.redhat.com/articles/1444903 , which was thwarted by SELinux's protections for virtual machines (sVirt).
      - deleted 9y ago
        [deleted]
      - deleted 9y ago
        [deleted]
      - rightos 9y ago
        That's pretty sweet, if I had to manage my own VMs I'd definitely look into SELinux for that feature. I can see an argument for a defense in depth approach here, but if there's only one service per VM and that service is already restricted to only the stuff it needs to talk to on the network level I'm not convinced it makes much sense. As far as I know at least, SELinux won't be able to prevent kernel exploitation or the like.
        ungamed 9y ago
        It absolutely prevents kernel exploitation by stopping certain syscalls. I guess you can argue that it doesn't stop "The exploit" in syscalls it allows but it does prevent syscalls from being run.
jron 9y ago
I can think of a great reason to disable SELinux; you actually use linux for a workstation and don't want fight with it every time you install a new application.
- Hello71 9y ago
  do you also do chmod -R 777 /?
  - xyzzy_plugh 9y ago
    That seems excessive. Why not just run as root?
  - yjftsjthsd-h 9y ago
    Pretty sure that actually breaks stuff
    - jameskegel 9y ago
      This is correct.
- Spivak 9y ago
  But you don't. Almost all 'applications' run unconfined.
- pjmlp 9y ago
  I can think of a great reason not to disable it, exposing $HOME to the world.
  - deleted 9y ago
    [deleted]
  - hobarrera 9y ago
    Have had SELinux for almost 10 consecutive years. $HOME has never been exposed. I've no idea what you're going on about.
throw2016 9y ago
Selinux will become useful when it precisely lists out what it disables with transparent explanations for assumptions made. And clear error messages or alerts when it has just disabled something with proper logging. Unlike with most open source software for things like selinux that disable a host of stuff by default, documentation cannot be an after thought. And why invent weird vague terminology, what is a context? Things are complex as it is and people need to get things done. To have to waste man hours that could be used more productively more than once only to figure out its caused by selinux 'silently' without any proper error messages or logging and you do the sensible thing and disable it.
- Spivak 9y ago
  > what it disables with transparent explanations setroubleshoot > documentation cannot be an after thought Take a look at selinux-policy-doc, it's extensive. > what is a context It's a type. But 'type' as it refers to files means something else. It's just a label that describes what kind of file it is. user_home_dir_t is user files, httpd_sys_content_t is content that can be served by apache, nfsd_fs_t are files that that can be exported by NFS. > proper error messages or logging Every single denial is logged and it contains all the details why it was denied. You're asking for SELinux to log why it wasn't allowed which is done by setroubleshoot but isn't possible in general.
  - emmelaich 9y ago
    > Every single denial is logged Not quite true. Some need to have debug turned on. See my other comment.
staticassertion 9y ago
Building policy by just auditing is a bad idea - you'll end up with overly general roles. Policy building is best left to the author of the applications so that they can test against it and lock it down.
- problems 9y ago
  So what's your suggestion? Just disable SELinux for that application if it's failing?
emmelaich 9y ago
I mostly agree with you but sometimes it is extraordinarily difficult to find out what went wrong. audit2allow and audit2why are often helpful but at least as often they offer the wrong solution. Did you know that some selinux violations are not even reported by default? This was the case for me; selinux transitions are prevented by a filesystem mounted _nosuid_. The failure is not reported because transition failures are apparently so common and unimportant selinux does not report them by default. Took me a looong time to troubleshoot this.
naasking 9y ago
> Disabling SELinux is a mistake, especially now that there are tools that will scan the audit.log and tell you exact commands on how to fix each thing it finds. If it were actually that easy, then you wouldn't need this step since SELinux would just do it for you. Clearly that isn't the case.
- yorwba 9y ago
  SELinux can't tell which of those accesses were intended, and which were actual security violations it should keep preventing. That requires human intervention. Maybe it could be made more convenient by a tool that parses the log and automatically runs the commands when you answer the question with "y".
  - naasking 9y ago
    > SELinux can't tell which of those accesses were intended, and which were actual security violations it should keep preventing. That requires human intervention. Right, it requires intervention by a person who doesn't actually understand the minutiae of what the software is trying to do, so obviously they can make a properly informed choice as to what is and is not a security violation. Modern operating systems are so broken...
hobarrera 9y ago
> There's literally no reason to turn it off nowadays, other than laziness/unwillingness to learn. Sometimes is as simple as not having time for that. If I've urgent work to do, I can't stop my work and well my boss/client "hang on, I need to learn to configure SELinux first!". The fact that it DOESN'T work out-of-the-box immediately and needs for me to configure it (regardless of how well documented it is) is its major pitfall. These things need to work without adding ANY burden to the user. Otherwise, they'll end up disabled.

aidenn0 9y ago

I still can't get PA to directly work with my USB sound card. I ended up configuring alsa dmix for it (which is definitely not easy to configure), and pointing PA at dmix. Supposedly it should see the card arrive through hotplug and add it to the device list, but that has never happened.

cat199 9y ago
I've not had issues on this on Fedora (24+) - I did have to kill pulseaudio 1st though.. might try that if you have not already
digi_owl 9y ago
dmix is hard to configure?
- aidenn0 9y ago
  Configuring ALSA to work properly with my USB sound was the single hardest thing I did on my gentoo box. The documentation ranges from terrible to nonexsitent and it is unclear how to generalize many of the example configurations.
monksy 9y ago
I have a mediabox which decided it was time to install PulseAudio for kodi. Which, that perceeded to complexly screw over audio over HDMI. (No idea why it was refusing to play audio until I disabled pulseaudio).

viraptor 9y ago

Having done all 3, I'd order them from the hardest as selinux, pulseaudio, apparmor. Out of these 3, apparmor has the most user-friendly tools to apply changes. It also allows you to easily turn off a single profile without disabling the whole system. Given those, I don't expect that many issues. But also, worth remembering that this is a proposal for an experiment. One of the things they're going to judge is how much does it affect regular users.

oliwarner 9y ago

Ubuntu has used AppArmor for years. Debian users will benefit from those years use.

upofadown 9y ago

People rant and rave about how pulseaudio is broken on their system. Pulseaudio is pretty easy to configure for most things. Sometimes it even (unexpectedly) configures itself!