6 ms·
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 supp
by hapless 12y ago
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.
- rwmj 12y agoOr real virtualization + SELinux + sVirt ... libvirt on RHEL/Fedora/CentOS puts the qemu process into a container too.
- fleitz 12y agoFor security yes, however, for performance / resource requirements docker is going to beat libvirt/qemu.
- rwmj 12y agoOr for running anything other than Linux on the exact same kernel. Running Windows, for example, or older copies of Linux.
- edwintorok 12y agoI think of docker as a "nicer chroot", i.e. it might be nice for testing deployment of networked applications with lots of servers, where setting up a new VM for each one would be both slow and an overkill. Is running something inside docker worse than running the same application on the host from a security pov? If not then you can consider docker just as one way of deploying an application on the host, i.e. not something for shared hosting of independent/possibly malicious applications.
- rwmj 12y agoIn addition, we have repeatedly hit problems with our "mock" build system which uses a different kernel from what userland software is normally tested with. eg: [1] [2]. This stuff is going to hit Docker users sooner or later. It is also infuriatingly hard to debug. [1] http://bugzilla.redhat.com/1062533 http://bugzilla.redhat.com/1062533 [2] https://bugzilla.redhat.com/563103#c8 https://bugzilla.redhat.com/563103#c8
- rdtsc 12y agoDoes it run Windows? Because libvirt/qemu does. A slow speed beats 0 speed usually? ;-)
- icebraining 12y agoA slow speed beats 0 speed usually? ;-) Not if you're running Windows.
- rdtsc 12y ago> Not if you're running Windows. Not if Windows puts money in the pocket
- pling 12y agoJust buy more computers. Works for us and is cheaper than VMWare ESX (the thing we replaced). Xen would be cheaper and give us better utilisation but getting rid of VMware was a good step towards cost savings :)
- saosebastiao 12y agoI can't help but be skeptical about SELinux, having been written by the NSA. What would make you choose SELinux over AppArmor?
- nickstinemates 12y agoIsn't it for the NSA, but by Red Hat? May have my history mixed up.
- citruspi 12y agoI believe that the National Security Agency was the original developer, but that Red Hat is significant contributor.
- mpyne 12y agoNSA developed it and open-sourced it (much like their development of the crypto hash used for git), but Red Hat and the Linux kernel devs have pushed it the most since.
- SwellJoe 12y agoWhile I'm as suspicious of the NSA and their intentions as anyone (I am very actively involved in my local Restore the 4th and Cryptoparty chapters), the fact is that the code is Open Source, and has been vetted by some of the best, and most trustworthy, developers in the world (it has been in the mainline Linux kernel for over a decade). I trust SELinux. I don't necessarily trust my understanding of SELinux...it is a complicated beast. But, I believe that when configured correctly, it is a very powerful tool. As I understand it, SELinux covers more ground than AppArmor. I have low familiarity with AppArmor, however, so don't know enough to argue why one might choose one over the other. But, I don't have any suspicion of SELinux containing exploitable code inserted by the NSA.
- zobzu 12y agothe principles are really not that complicated really. I like this diagram of a similar implementation: http://www.rsbac.org/_media/documentation/rsbac_handbook/architecture_implementation/functional_diagram_gfac_rsbac2.png?w=&h=&cache=cache http://www.rsbac.org/_media/documentation/rsbac_handbook/arc...
- growupkids 12y agoUse grsecurity and a least privilege policy generated specifically for your exact system, and not generic policies.
- amscanne 12y ago> Nothing with a shared kernel is going to be very secure. SELinux is still operating in a shared kernel.