Linux has been described as one of the most secure operating systems available, but the National Security Agency (NSA) has taken Linux to the next level with the introduction of Security-Enhanced Linux (SELinux). SELinux takes the existing GNU/Linux operating system and extends it with kernel and user-space modifications to make it bullet-proof. If you’re running a 2.6 kernel today, you might be surprised to know that you’re using SELinux right now! This article explores the ideas behind SELinux and how it’s implemented.
Anatomy of Security-Enhanced Linux (SELinux)
About The Author
Eugenia Loli
Ex-programmer, ex-editor in chief at OSNews.com, now a visual artist/filmmaker.
Follow me on Twitter @EugeniaLoli
I am going to wear linux!
The most value i see in flask is the fact that it is being implemented on multiple platforms (SELinux, OpenSolaris FMAC, SEDarwin, SEBSD), being able to deliver security policies across multiple platforms.
I haven’t seen it enabled on too many servers. Redhat and Fedora enables SElinux by default (what quickly gets turned off by the admins), pbly the problem not just that the average admins don’t have enough experience in RBAC/DAC but applying it in production environment is hard (qaing a mirror of the system then applying it on the main server, and still can something go wrong) to accomplish especially if you want to install new packages on the servers from time to time, not just configuring a box for dns server, then using the basic selinux configuration and leave it that way.
I think moving forward to virtualization is much more popular. I even doubt the nsa use selinux on their own servers.
> I think moving forward to virtualization is much more popular.
You can do both.
And you can use SeLinux with virtualisation.
EC2 ( http://aws.amazon.com/ec2 ) permit SeLinux :
$ ssh [email protected] getenforce
Enforcing
Btw, my personnal system :
$ /usr/sbin/getenforce
Enforcing
A log of RHEL / Fedora have SeLinux in Enforcing mode.
In my opinion SELinux is irrelevant for most users, and for the rest it is waaaay too hard to use. I am more interested in that new access control feature in the linux kernel (Smack or something?) as this seems to be similar to only the easiest part of SELinux.
Personally I think MAC is the way to go for long-lived background services that the user will not interfere with, but for foreground applications should not be such restrictions yet before they have found a proper way to implement it that does not interfere with the users workflow…(I am talking about enduser systems ofc).
> In my opinion SELinux is irrelevant for most users
In my opinion Unix/Linux/BSD is irrelevant for most users.
That was true.
It is disturbing that SELinux is being presented essential and a panacea. To read the popular propaganda, you’d think that it was impossible achieve anything better than a security sieve without it. SELinux is an effective, if somewhat complex, tool which provides very fine-grained security. It comes at a cost of some (perhaps unnecessary[1]) complexity, and a bit of performance. There are other solutions which hit a different balance of fine-grainedness vs complexity, including the traditional unix permissions which have served us pretty well over the last few decades before SELinux showed up. I am far from a RedHat basher (I have huge respect for them), but RedHat has been pushing SELinux very hard for their own business reasons, and this has created a vortex which has sucked in many bystanders. Distros and savvy individuals should make their own choices, which make the most sense for their situation.
[1] “The more they over-think the plumbing, the easier it is to stop up the drain.”
– Montgomery Scott, Star Trek III: The Search for Spock
Edited 2008-05-12 13:22 UTC
Redhat mainly uses SELinux for confining system daemons. They have done a pretty good job of making the default configuration work out of the box. One big problem area are services like Apache where users need to label files and there aren’t good simple docs on how to do this. The other problem is with third-party software, like VMware, that doesn’t know about SELinux.
There has been some work done on confining Firefox. My guess is that it will be an option for people who want the extra security and are willing to put up with limitations on downloading files and loading plugins.
… what I’d really like to see is pf ported to Linux.
Looks unlikely to happen because (as I understand it – I’m not a network guru) Linux handles networking quite differently to how the BSDs do.
I use pf with FreeBSD (I dual-boot that with Linux)
and I’m sold on pf’s *great* rule syntax, elegance and
effectiveness!
Edited 2008-05-12 06:37 UTC
What do you mean by “Guru”? If you mean what i mean, then this could be for you 🙂
http://www.fwbuilder.org/
Or this
http://firehol.sourceforge.net/
not every problem can be solved with adding another layer of complexity.
(and this is also true for SEL)
And complexity is antagonistic to security.
I like SElinux and it features. But I can understand people are overwhelmed by it’s way of working. It requires to think in an other way and has a rather high learning curve.
People like Dan Walsh publish a lot simple and daily usage examples.
we curently see a shift in our daiywork towards the apparmor stuff as it lowers the curve quite a bit.
problem with selinux indeed is the steep curve and unix people are hard to find, especialy when thy are not a consultant. So, keeping the stuff working and safe is better, so it seems.
Both products use the same system calls afaik. apparmor can do less at some points but so much easier to administer. Things management like.
I have never used selinux, but according to what I have read from others who know it well-one must understand the code of the application to really grok how to get it to work well with selinux. If this is true most admins are basically screwed, because few admins are programmers at heart. Having a deeper understanding of how the code works of the many thousands of apps which compose a system is simply not in the domain of knowledge or skills for a good admin-and shouldn’t be: this is why there are programmers and admin-two seperate skillsets with only a degree of overlapping.
I may of course be wrong-but I have read this kind of thing one too many times. I suspect selinux will really start to make a difference when the applications themselves have been modified to properly support selinux. This is what Redhat/Fedora are doing now-working with upstream to make applications play properly with selinux. I suspect that in a couple of years most of the basic applications which compose a system will be patched to play nicely-at which point we won’t have to understand how the code works to be able to easily manage selinux.
On another note:
I love reading planet gnome and watching the poor programmers struggling to do simple admin stuff-so much they know, so much they don’t understand.
And related to this:
/rant
a lot of system applications are being written now by programmers who have basically no experience administering system and this is really painful-traditionally system apps were written *for* admins- not against them-NetworkMangler(TM) is a wonderful example of this. Most of the anti-admin system software seems to be comming from Redhat unfortunately. Basically any software that configure the system which is exposed directly to users is anti-admin- the needs of users are at direct odds with admins- admins need control, users need few options and minimal control-to keep them from messing things up. Of course admins are users too- and in Linux land, lots of users are admins by default.
NetworkMangler/Policykit/Pulseaudio/Hal are each plagued by these problems- they are so tightly coupled with the particular distribution that they only work if they are properly implemented by the distributors themselves-and thus the admin role-being between distributors and users is totally shortchanged-this all in an effort to make things easier for end users. The documentation of this class of software is basically non-existant, only those working for the distribution which is producing this software has any real insight into how this stuff works-yet admins need to be able to work with and around such software for they are the ones responsible for the users. As wonderful as NetworkMangler(TM) is for modern laptop wireless users, it remains an abomination for admins who simply want to implement static ip addresses. It’s voodoo is wrapped up in binaries which cannot be changed and has effectively 0 user-editable configuration files, which basically screws admins. Hell if the damned program would simply produce gconf entries which could be programmaticaly changed(gconftool-2) that in itself would be a wonderful improvement.
rant/
I may comment on a few of your statements:
Well, it’s not that easy. Too few options: “I can’t setup anything!”, but too much option: “That’s all silly stuff I don’t need.” In opposite to “average users”, admins usually know what they want and what they need.
You’re right, but feel free to extend this statement: On most home PCs, the user is the admin – admin and user in one and the same person. “I don’t need to administer my system, it does it by itself!” is, as you surely know, nonsense. Making computers accessible to everyone makes system designers abandon well intended means of security, just to increase the comfortability of the user. On the other hand, this may cause more trouble for “real admins” who have to repair the holes in the security concept afterwards.
Here, a look to the BSDs is very welcome. The security software, belonging to the base OS and being maintained by the OS crew, offers excellent documentation which is available right after install via the “man” command. Corresponding sections in the handbook illustrate and explain the more complex topics. I do agree with you: Documentation is very important, especially if an incorrect setup security software makes your system vulnerable to attackers.
(I can’t make very accurate statements about SELinux – so I won’t even try – because I’m mostly using pf on BSD, but still the article was very interesting.)
I could be wrong, but my understanding of pf on BSD is that it’s basically for building firewalls. It’s Linux equivalent would be iptables. In terms of syntax, may say that pf is superior to iptables, and I won’t argue with that – they are probably correct. However, I don’t think that pf is equivalent to SELinux. SELinux is a MAC (mandatory access controls), and the article states that BSD has it’s equivalent is TrustedBSD.
I have no criticisms of pf, I just don’t think it’s equivalent to MACs. But then, I’m no expert (wish I were).
Edited 2008-05-14 22:33 UTC
This illustration is correct. Another firewall mechanism on BSD is the IP firewall, ipfw2. Is is more port oriented and doesn’t seem to take packet content much into concern. As far as I know, ipfw is available on Mac OS X, too.
On FreeBSD, “man 3 mac” gives you the section 3 manpage for the kernel interfaces of the mandatory access control which can be enabled by putting “options MAC” into your kernel configuration file. Different mac_*.ko loadable modules are available, too. According to TrustedBSD you mentioned, the manpage states: “Support for Mandatory Access Control was introduced in FreeBSD 5.0 as part of the TrustedBSD Project.” The file /etc/mac.conf controls the MAC framework (see “man 5 mac.conf”; sebsd is mentioned there, too). The system developer’s manual adds further information (see “man 9 mac”).
I think you’re right. The machanisms of ipfw and pf provide excellent means of security, and the TrustedBSD MAC framework complements to this concept.
http://tomoyo.sourceforge.jp/
http://tomoyo.sourceforge.jp/wiki-e/?WhatIs
http://kerneltrap.org/Linux/TOMOYO_Linux
http://lkml.org/lkml/2007/12/25/18
(You could have written a short introduction to Tomoyo too besides of just providing the links. Anyway: ) on that site there’s a nice “Secure OS Comparison At a Glance”, including SELinux, Tomoyo, AppArmor and Smack:
http://tomoyo.sourceforge.jp/wiki-e/?WhatIs#comparison
I haven’t used SELinux, but it simply seems too difficult to set up, and too difficult to maintain. Plus, mainstream adoption has been either non existent, or very slow. Lack of documentation doesn’t help, lack of mainstream applications fully supporting or integrating with SELinux doesn’t help either.
I really do honestly think that a lot of basic security comes down to commonsense stuff like making hard to guess passwords, not opening emails from people you don’t know, running Linux as a normal, not root user (obvious I know, but some people do run it as root), and avoiding dubious websites. Basics like avoiding using html in emails don’t hurt either.
The sad thing is most people using computers (and not just Linux, mostly Windows) should NEVER be allowed near a computer. They are not interested in learning how to securely use their computer in the slightest, they have no interest in learning how to effectively maintain their computer, they are plain lazy and stupid. Sorry, I might sound like an elitist, but as someone who has worked in support for a good number of years, I KNOW that I am 100% accurate in this comment. I have long championered the idea of every computer user MUST be licensed to use it if it is connected to the Internet, or shares files with others in any way, shape or form.
Microsoft Windows is mostly to blame for this phenomena, as it has long sacrificed security for ease of use with exceptionally bad design points in relation to security and reliability. 15 years ago and only the computer literate used a computer, and you *had* to learn how to use the computer. These days, every Tom, Dick & Harry uses it and usually cocks things up on a regular basis. Herein lies the problem – why should the network bandwidth of the Internet be reduced to allow for idiots who get viruses, worms, trojans, diallers and act as SPAM bots etc? Why should I have a slower Internet connection because of congestion due to other users who simply do not secure their system and act in a responsible way?
Dave