4 ms·

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

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.

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.