31–40 of 91 posts
Here is your annual reminder: Use SELinux. Nothing with a shared kernel is going to be very secure. That's just the nature of the beast. It's why Docker supports SELinux. It's why RHEL and CentOS ship with pre-written SELinux policy for common daemons. If you intend to have more than zero services on the system, you want SELinux.
Here is your annual reminder: Use SELinux. Nothing with a shared kernel is going to be very secure. That's just the nature of the beast. It's why Docker supports SELinux. It's why RHEL and CentOS ship with pre-written SELinux policy for common daemons. If you intend to have more than zero services on the system, you want SELinux.
Or real virtualization + SELinux + sVirt ... libvirt on RHEL/Fedora/CentOS puts the qemu process into a container too.
To fix this you can shutdown the container, edit the config in /var/lib/lxc//config and add dac_read_search to lxc.cap.drop. Voila.
[*] Resolving 'etc/shadow'
[-] open_by_handle_at: Operation not permittedHere is your annual reminder: Use SELinux. Nothing with a shared kernel is going to be very secure. That's just the nature of the beast. It's why Docker supports SELinux. It's why RHEL and CentOS ship with pre-written SELinux policy for common daemons. If you intend to have more than zero services on the system, you want SELinux.
I can't help but be skeptical about SELinux, having been written by the NSA. What would make you choose SELinux over AppArmor?
Earlier quoted context omitted.
This phrasing unfairly conflates VM/hypervisor technology and containers. Containers being a pure software technology do require near superhuman ability to secure but VM/hypervisors can lean on chip-level separation. People forget that in-chip memory protection didn't come about for security reasons, memory errors were a particularly dangerous and particularly common kind of bug and the hardware was extended to help…
You now rely on chip designers being super-human. The real truth is that the difficulty of containment is proportional to the interface that is available to the contained process. You don't need VM or hypervisor technology to build a virtually unbreakable container. You only need to prevent the contained process from using any syscalls at all. Hardware only seems better at this kind of stuff because (a) it's harder t…
You can't just argue away the fact that a certain class of error has been all but eliminated by hardware-supported virtual memory. Multi-tasking as we know it today would basically be impossible without it. The reliability of "just get it right" systems like the early Macintosh isn't even comparable to, for example, a modern Linux machine that uses the chip to trap large classes of erroneous memory accesses.
Given that we have the above, a case of a class of error that programmers seemed unable to eliminate (practically) eliminated, I'm not really sure what you're arguing. Are you saying that hardware designers of the 80's were superhuman?
Okay... maybe Jay Miner...
Hi all, I'm a maintainer of Docker. As others already indicated this doesn't work on 1.0. But it could have . Please remember that at this time, we don't claim Docker out-of-the-box is suitable for containing untrusted programs with root privileges. So if you're thinking "pfew, good thing we upgraded to 1.0 or we were toast", you need to change your underlying configuration now. Add apparmor or selinux containment, m…
Earlier quoted context omitted.
Except the software running a tank.
I write software that runs on tanks, its not bullet proof. Most the communication protocols just use security though obscurity. If you tell a gear box to shift form 1st to snip it'll do it, and break everything. But when you considered air gap, and physical security surrounding it (12 inches of plate steal, 5 man team with guns, massive main gun), its pretty secure.
Earlier quoted context omitted.
I can't help but be skeptical about SELinux, having been written by the NSA. What would make you choose SELinux over AppArmor?
Isn't it for the NSA, but by Red Hat? May have my history mixed up.
Earlier quoted context omitted.
Except the software running a tank.
I write software that runs on tanks, its not bullet proof. Most the communication protocols just use security though obscurity. If you tell a gear box to shift form 1st to snip it'll do it, and break everything. But when you considered air gap, and physical security surrounding it (12 inches of plate steal, 5 man team with guns, massive main gun), its pretty secure.
I write software that runs on tanks
Ha! Only on HN...