4 ms·

SELinux is not not worth saving because security has been moving steadily into namespace separation (E.g., containers, virtual machines). Giving an application

SELinux is not not worth saving because security has been moving steadily into namespace separation (E.g., containers, virtual machines). Giving an application/user and entire trimmed down OS namespace reduces damage done from getting pwned significantly. Why use a system that protects processes from running alongside each other when I can just give them their own, fenced-in home?

viraptor 10y ago
No. No, no, no. Virtual machines - yes, to an extent. Containers - no. Containers still use the same kernel, have access to the same filesystems (in practice), same devices, same ioctls, etc. There can be a lot more separation done in the future, but right now, you definitely gain a lot by isolating your containers using selinux. Even with virtual machines, you want any breakout / external write vulnerability to be contained. That's why libvirt/kvm relies on selinux (or apparmor) for system protection and for cross-vm protection (https://libvirt.org/drvqemu.html#securityselinux https://libvirt.org/drvqemu.html#securityselinux)
- matt_wulfeck 10y ago
  I realize the system is not perfect, but it's so much better than nothing, and significantly easier to use than virtualmachines/selinux. It's naive to dismiss something because it doesn't meet the goal of "100%" secure. In practice it gets you very close and takes almost no effort, no maintenance, no headache. Historically that kind of thing will win in the long run.
  - viraptor 10y ago
    I'm not arguing that VMs are not an improvement in many areas. They are a MASSIVE improvement and I'd love the unikernel apps to become more popular and push it even further. QubesOS also shows the power of safe virtualisation. But it doesn't mean "SELinux is not worth saving". Some kind of LSM (selinux/apparmor) is still a great safety net and protects us from an issue that VMs actually introduce. Once you break out of your VM, you have access not to a single host, but to a number of them in a way that no in-VM protection can stop or even detect. That's the reason we really need LSM protection. Not necessarily selinux, but something needs to be there.
- djsumdog 10y ago
  I felt the same way about Docker containers. Now I work for a company that uses Docker containers in production. The fact that the process, by default, runs as root and PID 1 within the docker container still has be going "You gotta be fucking kidding me?!" I realize Docker has come a long way since the days of it being LXC based. Cgroups and several other safeguards have done a lot of docker security, and containers are much more lightweight than full VMs, but I'm still a little on edge about the security aspect.
  - teabee89 10y ago
    Since Docker 1.10, you can specify --userns-remap=default on the daemon and root inside the container will not be root outside: https://docs.docker.com/engine/reference/commandline/daemon/#starting-the-daemon-with-user-namespaces-enabled https://docs.docker.com/engine/reference/commandline/daemon/...
    - e12e 10y ago
      I have the impression that regrettably many docker users expect things to be the other way around: that the actual default docker behaviour resides behind a --ridiculously-insecure, not that you need to specify --i-actually-want-my-container-to-try-to-contain to get that expected behaviour. Hopefully more people are becoming aware of the actual default behaviour.
  - boryas 10y ago
    Perhaps I'm misunderstanding the second line of your post, so I apologize if that's the case, but the whole idea of the PID namespace is so that the container's init can run as pid 1 in the container without access to the rest of the host's processes. Likewise for root and user namespaces. (Though I understand that one is really tricky to get right)
andrey_utkin 10y ago
How would you run VoIP calls in skype? You would have hard time passing your media sources and outputs through VM or container. Pulseaudio doesn't work fine even if you run two audio activities from two different system users. Also moving data across VM/container boundary all the time is not a fun. Been there, done that even in lighter manner (with separation of system accounts for different activities).
- viraptor 10y ago
  Sound works quite well in VMs actually. You just get a virtualised audio device which then plays into system's pulseaudio. It "just works" for me. Potential pulseaudio issues are not VM audio issues. As long as you establish some read-write and read-only shares between vms/containers, there should be no problem with moving the data. As in, you don't have to move it in the first place, but you need to design it the right way.

viraptor 10y ago

No. No, no, no. Virtual machines - yes, to an extent. Containers - no. Containers still use the same kernel, have access to the same filesystems (in practice), same devices, same ioctls, etc. There can be a lot more separation done in the future, but right now, you definitely gain a lot by isolating your containers using selinux. Even with virtual machines, you want any breakout / external write vulnerability to be contained. That's why libvirt/kvm relies on selinux (or apparmor) for system protection and for cross-vm protection (https://libvirt.org/drvqemu.html#securityselinux https://libvirt.org/drvqemu.html#securityselinux)

matt_wulfeck 10y ago
I realize the system is not perfect, but it's so much better than nothing, and significantly easier to use than virtualmachines/selinux. It's naive to dismiss something because it doesn't meet the goal of "100%" secure. In practice it gets you very close and takes almost no effort, no maintenance, no headache. Historically that kind of thing will win in the long run.
- viraptor 10y ago
  I'm not arguing that VMs are not an improvement in many areas. They are a MASSIVE improvement and I'd love the unikernel apps to become more popular and push it even further. QubesOS also shows the power of safe virtualisation. But it doesn't mean "SELinux is not worth saving". Some kind of LSM (selinux/apparmor) is still a great safety net and protects us from an issue that VMs actually introduce. Once you break out of your VM, you have access not to a single host, but to a number of them in a way that no in-VM protection can stop or even detect. That's the reason we really need LSM protection. Not necessarily selinux, but something needs to be there.
djsumdog 10y ago
I felt the same way about Docker containers. Now I work for a company that uses Docker containers in production. The fact that the process, by default, runs as root and PID 1 within the docker container still has be going "You gotta be fucking kidding me?!" I realize Docker has come a long way since the days of it being LXC based. Cgroups and several other safeguards have done a lot of docker security, and containers are much more lightweight than full VMs, but I'm still a little on edge about the security aspect.
- teabee89 10y ago
  Since Docker 1.10, you can specify --userns-remap=default on the daemon and root inside the container will not be root outside: https://docs.docker.com/engine/reference/commandline/daemon/#starting-the-daemon-with-user-namespaces-enabled https://docs.docker.com/engine/reference/commandline/daemon/...
  - e12e 10y ago
    I have the impression that regrettably many docker users expect things to be the other way around: that the actual default docker behaviour resides behind a --ridiculously-insecure, not that you need to specify --i-actually-want-my-container-to-try-to-contain to get that expected behaviour. Hopefully more people are becoming aware of the actual default behaviour.
- boryas 10y ago
  Perhaps I'm misunderstanding the second line of your post, so I apologize if that's the case, but the whole idea of the PID namespace is so that the container's init can run as pid 1 in the container without access to the rest of the host's processes. Likewise for root and user namespaces. (Though I understand that one is really tricky to get right)

andrey_utkin 10y ago

How would you run VoIP calls in skype? You would have hard time passing your media sources and outputs through VM or container. Pulseaudio doesn't work fine even if you run two audio activities from two different system users. Also moving data across VM/container boundary all the time is not a fun. Been there, done that even in lighter manner (with separation of system accounts for different activities).

viraptor 10y ago
Sound works quite well in VMs actually. You just get a virtualised audio device which then plays into system's pulseaudio. It "just works" for me. Potential pulseaudio issues are not VM audio issues. As long as you establish some read-write and read-only shares between vms/containers, there should be no problem with moving the data. As in, you don't have to move it in the first place, but you need to design it the right way.