14

I have to set up a server that should be as secure as possible. Which security enhancement would you use and why, SELinux, AppArmor or grsecurity? Can you give me some tips, hints, pros/cons for those three?

AFAIK:

  • SELinux: most powerful but most complex
  • AppArmor: simpler configuration / management than SELinux
  • grsecurity: simple configuration due to auto training, more features than just access control
  • A "server" to provide what kind of service? To what audience, in what environment? What constitutes "secure" to you in this context? Lots more information would be necessary to provide a useful answer. For instance, a pure IP Time-of-Day server can be very secure -- all ROM firmware, radio imput, self contained battery power with automatic charging. But that's probably not a useful answer for you. So, what kind of service? Internet wide, enterprise wide, trusted work team, dedicated point-to-point networking, etc.? Is high availability a need? Reliability? Data Integrity? Access control? Give – mpez0 May 18 '10 at 14:21

2 Answers2

7

I have done a lot of research in this area. I have even exploited AppArmor's rulesets for MySQL. AppArmor is the weakest form of processes separation. The property that I'm exploiting is that all processes have write privileges to some of the same directories such as /tmp/. What nice about AppArmor is that it breaks some exploits without getting in the user/administrators way. However AppArmor has some fundamental flaws that aren't going to be fixed any time soon.

SELinux is very secure, its also very annoying. Unlike AppAmoror most legitimate applications will not run until SELinux has been reconfigured. Most often this results in the administrator misconfiguration SELinux or disabling it all together.

grsecurity is a very large package of tools. The one i like the most is grsecuirty's enhanced chroot. This is even more secure then SELinux, although it takes some skill and some time to setup a chroot jail where as SELinux and AppAprmor "just work".

There is a 4th system, a Virtual Machine. Vulnerabilities have been found in VM environments that can allow an attacker to "break out". However a VM has a even greater separation than a chroot becuase in a VM you are sharing less resources between processes. The resources available to a VM are virtual, and can have little or no overlap between other VMs. This also relates to <buzzword> "cloud computing" </buzzword>. In a cloud environment you could have a very clean separation between your database and web application, which is important for security. It also maybe possible that 1 exploit could own the entire cloud and all VM's running on it.

Rook
  • 2,615
  • 5
  • 26
  • 34
  • instead of the `` tag you can just write "my butt", everyone will know what you mean ;) – Daniel Dinnyes Dec 04 '16 at 05:49
  • By VM do you mean Xen, KVM, or LXC/Docker? Also, please reference your evaluations. – Daniel Dinnyes Dec 04 '16 at 05:54
  • 1
    @Daniel Dinnyes there are no references here, this is all personal opinion as a hacker who attacks modern applications that are protected with these mitigation techniques - the big take away is that nothing is perfect. – Rook Dec 04 '16 at 16:13
  • I meant some links to further read up on the subject, and understand why you have that opinion. I was asking for it, because based on your answer you seemed someone who has experience on it. – Daniel Dinnyes Dec 04 '16 at 16:17
  • 1
    @Daniel Dinnyes If you are interested in misuse-cases, start with the intended use cases. Install distros that use these technologies, and deploy apps on them. Read about deploying and configuring these security systems, and then look for weaknesses. – Rook Dec 04 '16 at 17:17
  • I am actually in the middle of doing that, experimenting with switching to Debian from RHEL, and doing some analysis on SELinux alternatives (that's how I ended up on this thread). Also have some experience with KVM and Docker. I am just asking for something to read up on, instead on doing it (so I can procrastinate a bit) – Daniel Dinnyes Dec 04 '16 at 17:55
  • 1
    @Daniel Dinnyes look at the CVEs issued and especially any public exploits for each platform. There was a really good SELinux bypass found recently: https://www.exploit-db.com/exploits/40419/ – Rook Dec 04 '16 at 18:53
  • Mike, I happen to have some time now until the end of the year to do my research on the subject. OTOH, there are limited hours in a day, and limited days in a lifetime, so I am looking for advice in the directions to focus by brain capacity on, with the highest ROI. The space for understanding the context for choosing this direction is vast, way too much for the human brain to comprehend in a lifetime (I've never even heard of exploit-db.com before) – Daniel Dinnyes Dec 04 '16 at 19:56
  • Regarding the VMs for process isolation purposes: Docker has so many exploits (from gaining elevated privileges on the host, to loads of 0days coming out daily). I would not feel confident running it without some strong MAC policies applied on the docker daemon itself. Based on my understanding, KVM would fare much better in this regard. Also, compared to main MAC choices (SELinux, AppArmor), what would you say about Tomoyo Linux? I am a complete noob on all the MAC choices out there, so possibly my best option would be to dive deep into SELinux, despite all its PITA issues. and go from there. – Daniel Dinnyes Dec 04 '16 at 20:14
  • Let us [continue this discussion in chat](http://chat.stackexchange.com/rooms/49609/discussion-between-daniel-dinnyes-and-rook). – Daniel Dinnyes Dec 05 '16 at 17:40
1

Personally, I would use SELinux because I would end up targeting some flavor of RHEL which has this set up out of the box for the most part. There is also a responsive set of maintainers at Red Hat and a lot of very good documentation out there about configuring SELinux. Useful links below.

Ophidian
  • 2,158
  • 13
  • 14
  • yeah but yum and selinux are so damn annoying. – Rook May 19 '10 at 08:55
  • 1
    I find yum's CLI significantly more intuitive than apt. SELinux is annoying when you're trying to go your own way with non-stock apps, but I've never had issues with the stock stuff beyond needing to turn on some sebool's to enable non-default functionality (e.g. Let httpd php scripts connect to the database) – Ophidian May 19 '10 at 12:43