Submitted by “Should Security Enhanced Linux be designated as the sole security framework for Linux? While most security specialists would agree on the high quality of SELinux, proponents are arguing this framework is the only one that should be needed for the open-source operating system kernel. In fact, it would eliminate the need for the Linux Security Module, an open platform for outsider developers to build their own security frameworks for Linux. And this idea has raised the ire of Linux keeper Linus Torvalds.”
Linux is about freedom of choice, not just for the end user, but for the distro makers too. Developers should be free to explore new possibilities, and that is precisely what LSM provides.
Furthermore, Linux is not about enabling the biggest vendor to promote their technology to the exclusion of the rival technology promoted by the second and third biggest vendors. The only consensus for SELinux is the one that Red Hat is desperately trying to manufacture in the face of an increasingly popular alternative.
Agree this is clearly an attempt to de-capitate AppArmor now that the devs are looking for mainline inclusion.
Between this situation and the previous CFS/CK scheduler debate, I’m beginning to wonder about Red Hat’s actual commitment to community vs. self-attainment. Either incident on their own I could dismiss as typical LKML bickering, but RH is showing a pattern now and while I’m not an RH user with either RHEL or Fedora, I have always respected the commitment and investment they’ve made in linux overall development. Now I’m wondering, because they’re beginning to act with a bit of an entitlement mentality, so it certainly begs closer consideration.
“””
“””
News flash! Developer employed by a major distro speaks his mind on LKML, initiating a controversy! Film at 11. 😉
I would not worry too much. Why would RH want to decapitate AppArmor? What would be the motivation? AppArmor is a solution to a slightly differet problem and RedHat may need it for something someday. Just like they might need any other piece of OSS code that they do not happen to be using today.
RedHat is *very* active in kernel development. As an entity, RedHat is generally responsible for more kernel development than any other single entity, other than unaffiliated devs, which is still the largest category of Linux kernel contributors. So *of course* RedHat devs are going to be associated with various controversies. Note that developer Morris seems unlikely to get his wish, as Linus seems disinclined to remove the LSM. Though, as always, he is willing to listen to arguments. CFS is in. LSM will likely stay in. Win some. Lose some. Looks like a healthy bazaar environment to me. 🙂
You’re kidding, right? RH wants to standardize SELinux with RH packaging standards for commercial software. As has been posted, SELinux is only useful with a proper security policy compiled for applications, and guess who stands to be the standard bearer for secure package deployment?
[/q]
RH has core developers on the kernel, no doubt about it, but then so does Novell (including Greg KH, who has stepped in for Linus on commit responsibility when he’s unavailable), as well as IBM, HP, Oracle et al. RH employs a number of kernel developers, but no more than many other organizations, so claiming that is some sort of justification for their objections and interjections carrying more relevance due to numbers is a stretch at best.
CK is a perfect example. The CK patchset has been around for ages (in internet years), yet it wasn’t until Linus mentioned he was finally considering inclusion in mainline that the controversy started and Ingo decided to kick in his own scheduler, based in part of CK’s work (with credit given). Where was CFS last year, or the year before?
Red Hat seems to get a pass when they exert control in the OSS sphere. Put another way, if it was a Novell engineer proposing SELinux be dropped (and don’t kid yourself into thinking that this is about anything but competitive gain), people would be screaming bloody murder and accusing them of acting as a Microsoft puppet. Yet RH gets a free ride.
It’s hypocrisy, and I still think people need to watch RH closely if they’re truly concerned about ensuring the free and open nature of the kernel.
“””
“””
Sorry if I was not clear. I’m not saying that their objections carry more weight. Or that they *should* carry more weight. I’m saying that they are a major player, with lots of employed devs, and that it should be expected that their employees would frequently be at the heart of kernel debates. You were using their presence in the scheduler and LSM removal debates as evidence that there is a problem. I was simply pointing out that there is nothing particularly surprising or worrisome about it.
But why don’t you just go ahead and say that RedHat is the next Microsoft and be done with it? You know you want to. 😉
SELinux doesn’t seem to be the answer as I have heard many compliants about it’s complexity and my personal experience in trying to learn about SELinux is that understanding the policies is quite difficult.
Security that is difficult to understand is not good security.
The idea that you have to use Mandatory Access Control in order to secure your system and applications I find absolutely ridiculous. The MAC model used by RedHat and the NSA work as long as you are willing to accept default configurations of applications that come with RHEL, Fedora or any other Linux distro that uses SELinux. For example, if you decide to compile apache yourself because you might want to use modules that are not supported by SELinux and the particular distro you are using, then you had better be prepared to test this yourself before deploying it because at that point, you are on your own because you have changed the defaults and the security policy created by RedHat or other distro will no longer work. And while there is a learning mode, most people don’t have the time, equipment, skill or inclination to test in order to create a policy based on their configuration of either system, application or both. I am not a big fan of “one size fits all” soultions.
You are right, the learning curve is steep and I think you can get a lot more security with far less effort. I have yet to see a paper or serious discussion showing that using SELinux gives an administrator a distinct advantage over using least privilege, permissions, ACL’s and proper system and application administration procedures. I also don’t like being locked into a particular solution, and unfortunately that is what SELinux does. Administrators should have a choice, including LSM gives administrators a choice of methods to secure a system and its applications and should be part of Linux.
> For example, if you decide to compile apache yourself because you might want to use modules that are not supported by SELinux
If you decide to use /home/www (instead of /var/www) it does not work. And it’s not a SeLinux issue, it’s a security issue.
And “chmod -R 777 /” is not the best solution.
If you decide to use /home/www (instead of /var/www) it does not work. And it’s not a SeLinux issue, it’s a security issue.
Why? I’d really like to see this "idea"
One’s choice of paths should not be an issue if permissions are properly set. For all you know /var/www and /home/www could be mounted to a different drive from everything else. So it really should have no bearing on Security as to the path. Permssions, that’s a different issue.
And “chmod -R 777 /” is not the best solution.
And use Microsoft’s security model? Yes – that really would be incompetency in the admin doing that.
The idea that you have to use Mandatory Access Control in order to secure your system and applications I find absolutely ridiculous.
Have to agree really. It’s like jumping on every mole hill in a field.
The MAC model used by RedHat and the NSA work as long as you are willing to accept default configurations of applications that come with RHEL, Fedora or any other Linux distro that uses SELinux.
In a lot of ways I think that’s the point. You really have to depend on Red Hat’s packages and their configurations, when really, you should be able to easily decide what you want to do and have the security and policy system help you out.
I simply don’t have the time or inclination to implement an all encompassing security and policy system that tries to stuff square pegs into round holes.
The user friendlyness tends to be disproportional with real security. While the default SELinux implementation of for example Fedora perfectly fits, there are allways scenarios where the default just isn´t good enough.
I think firms like the NSA itself wouldn´t want to share secrets the majority of people isn´t ready for. Thus SELinux might be a good point to start the hardening process with. Personally i prefer grsecurity/rsbac though.
A non executable stack can be circumvented by returning to mrprotect(). This example and many more will not get unnoticed if you configure your grsecurity patched kernel.
Edited 2007-10-23 06:18
> Security that is difficult to understand is not good security
Security is always difficult to understand. It’s true with SeLinux, it’s true with Linux 2.0, it’s true with Windows 3.1, etc…
“””
“””
But the tool should not make the level of security required more difficult for the admin to see and understand than necessary. In that respect, SELinux has the same problem as iptables for the average, competent administrator. One must get too caught up in syntax and low level details to pay one’s full attention to the high level problem. One easily, even likely, makes mistakes which would have been avoidable if attention could be focused upon the problem and goal, and not the tool itself.
If an organization has the actual need for the kind of fine grained security that only SELinux can afford, then it is possibly the best tool for the job. But that organization must understand, up front, that they are going to need an *exceptional* Linux administrator, and are going to have to allow him *plenty* of time to get everything right, and more importantly, assure himself that everything is actually right.
The rest of us, being mere mortal folk, are *far* more effective, from a security standpoint, setting SELinux to “Permissive” when problems arise, and focusing our attentions upon simpler, more easily understandable, traditional security mechanisms.
To an extent, security *is* complex. But the basics are not so much. And the *vast* majority of actual, real world, attacks can be stopped by attention to basic security principles using traditional tools, along with relatively simple and effective proactive built in security features like exec-shield, FORTIFY_SOURCE, and nx.
Always remember that the reason distros like Fedora and RHEL come with SELinux installed and enabled by default are very much RedHat business reasons. RedHat very much *wants* the business of those organizations which *need* SELinux… a MAC framework sometimes being required by law. I am not *criticizing* RedHat for this. Merely noting the reason *why* so many desktop boxes and garden variety servers have the SELinux sledge hammer (inappropriately) included on them in the first place.
Edited 2007-10-21 15:43
The biggest security hole is the USER and ADMINISTRATOR. Somewhat weak security that’s easier to understand is more effective than strong security that confuses the people managing it.
>Security that is difficult to understand is not good security.
This saying is real nonsense! A *nix operating system doesn’t fit for everyone.
“””
>Security that is difficult to understand is not good security.
This saying is real nonsense! A *nix operating system doesn’t fit for everyone.
“””
OK. Then how about this? Complexity is antagonistic to good security. A security policy should be as simple as possible to meet wisely chosen goals, but no simpler. The goals should be chosen with the resulting level of complexity firmly in mind.
The reason why “James Morris proposed on the Linux kernel mailing list that SELinux should be the de facto security framework for Linux” is not so much the better quality of SELinux when compared to its alternatives but his desire to get rid of the underlying LSM (Linux Security Moduls). According to him “LSM is actively hindering the security of Linux. It is a ‘magnet for bad ideas,’ he wrote.”
SELinux is not perfect but neither is LSM. Whether the criticism may sometimes be rather theoretical or not, James Morris is not the only one who is critical of LSM. Other security frameworks like RSBAC or Grsecurity do not use or support LSM for various different security, technical and other reasons:
http://en.wikipedia.org/wiki/Linux_Security_Modules#Criticism
One of these days we are going to see him having a heart attack.
First the scheduler and now this security frameworks…
Dunno, he seems to have a substantially calmer disposition than his counterparts (the Steves). Sometimes a benevolent dictator has to use ALL CAPS to differentiate decisions from suggestions. As soon as Linus starts rearranging furniture, we’ll think about arranging an intervention on LKML.
“””
“””
And the tabloid^WIT press is right there to frame it as “crisis and conflict”. The end of the world is nigh.
I dont see the problem with SElinux being on by default aslong as they have a well written “targeted” policy for things like servers and things users should never have to do. Most people seem to agree SElinux is extremely powerful. If it can do everything LSM can do and more why not phase it out? This isn’t much different than IPchains when IPtables came along is it?
Linux was hard to learn at first too, but once you get it the flexibility is incredible.
“””
I dont see the problem with SElinux being on by default aslong as they have a well written “targeted” policy for things like servers and things users should never have to do.
“””
What’s a user? I administer a lot of machines. And I have spent a substantial amount of time on problems caused by SELinux. For example, something as simple as creating a printer with the lpadmin command fails silently with no error message due to SELinux. (Doing it this way is necessary because many of the machines I admin are POS stations, which do not run a gui, and the creation of the printers is done by a script which runs after the install.) So you create a printer and it works just fine… until reboot. Then it just disappears. Or you install ntpd and it works just fine… until the next reboot. It’s like it was never configured.
I have problems like this on the diverse set of machines that I admin *all the time*. It is *not* a rare event. Are these things that the user should never need to do?
Fortunately, I’ve gotten wise. Weird, inexplicable problem? No problem! Set SELinux to “Permissive”. Wow! Now it works. So *now* I have time to do a basic security audit on this machine to double check that everything is reasonable, rather than spending half the afternoon trying to figure out how to fix this SELlinux-caused malfunction which was not a security vulnerability in the first place.
For those instances where such fine grained control is necessary, SELinux is invaluable. For the rest of us, it is a damned waste of time that keeps us from attending to more basic security strategies.
Edited 2007-10-21 17:34
So what I think James Morris is really getting at is being limited by the LSM. SELinux is starting to really get a lot of nice features added to it and the software that supports it. With every new release of the targeted policy, more and more software is covered by new policies. I have to wonder what the SELinux team is wanting to implement next, but I have no doubt in my mind that it would be much easier to implement without having to code to LSM. I haven’t delved into the design of LSM too much, but it wouldn’t surprise me if there are features that are just absolutely impossible to implement with LSM in between SELinux and the kernel.
Is SELinux the absolute way to go? I’m not sure. I’m a big fan of SELinux and would like to see what all could be done without the LSM, but at the same time, I haven’t evaluated security options such as AppArmor and generally fall on the side of giving people more choice (LSM) than taking it away. On the other hand, as security becomes more important in the computing world, I have to wonder when removing LSM is a good move as to bring the security of Linux up that many more notches by being able to develop directly at the kernel layer.
I love the above comment because it shows an absolute lack of understanding of SELinux. SELinux in targeted fashion allows programs that have no policy written for them to run as if they are not running on an SELinux system. SELinux also prevents daemons from accessing content marked with the type user_home_t, which happens to be the data in your home directory. So even on a garden variety server or desktop box, SELinux is offering you protections that you might not be aware of.
I am not going to sit here and take the stand that SELinux is easy to get accustomed to. It has taken me quite some time to understand SELinux and get to the point that I feel comfortable in an SELinux environment. However, the power of SELinux and number of protections that are turned on by default make the system worth running. Most folks discount SELinux because it throws an AVC denial when they try to complete a common task. This is common and to be somewhat expected. Enter setroubleshoot around the Fedora Core 6 time frame. This tool tries to help explain the problem and what you can do.
To wrap this up without going too far down the rabbit hole, I think that Linux administrators should take the time to acquaint themselves with SELinux. It’s quite painful at first, but then, wasn’t learning Linux and all of the associated services? Technology advances — and it’s our job to follow it and know the new stuff. I’m not saying remove LSM — I’m just saying that Linux admins shouldn’t be so negative about a system that has a lot of power and benefit. I fully expect that over time, working with an SELinux system will become easier.
“””
“Merely noting the reason *why* so many desktop boxes and garden variety servers have the SELinux sledge hammer (inappropriately) included on them in the first place.”
I love the above comment because it shows an absolute lack of understanding of SELinux. SELinux in targeted fashion allows programs that have no policy written for them to run as if they are not running on an SELinux system.
“””
Nice fantasy world you live in. Install a RHEL5 or CentOS5 box and create a printer with lpadmin. Test the printer. It should work. Now reboot the machine. Try the printer. It won’t work. Look in /etc/cups/printers.conf. You will find no sign of it.
Now, set SELinux to permissive. Create the printer with lpadmin. Reboot the machine and test. It works. That is one of many issues I noted in the last batch of 18 machines I set up recently.
No need to look to third party software for problems; SELinux even breaks stuff that is included in the OS by default. Basic stuff like lpadmin.
Why should admins who *do not need* the fine grained security, and associated complexity (hence, obscurity) of SELinux waste *large amounts of time* studying it, when that time could be *much* more effectively spent verifying, and enhancing more traditional security policies? Policies which are both *effective* and *clear*.
But that is the standard retort from SELinux fans: All admins but us are just too lazy and dumb.
Yeah. Right…
Edit: I will repeat, however, that where SELinux is needed, it is no doubt invaluable. It is the pounding of the SELinux round peg into a multitude of square holes that I find unwise.
Edited 2007-10-22 00:20
Thats a bug in the policy then. If its not experiencing any level of widespread use, then these bugs will never get fixed as the devs won’t know about them. SELinux, when functioning properly, shouldn’t get in the way of anything and should just let things work normally, except when there is a security problem. We shouldn’t just sit with our old security systems and ignore the next generation one just because there are a few bugs that haven’t been resolved quite yet in the default policies. Over the next release or two, almost all of them will likely be fixed, and people will leave it enabled by default, and all linux boxes will end up being a bit more hardened to make it harder for hacks. If we leave it disabled until all security policies are bug free, we’ll never get it included anywhere. Thanks to RedHat, its made a lot of progress already and them having it enabled by default is really doing wonders for it. I have it enabled on RHEL5 and it hasn’t really caused any complications anywhere. I have a basic understanding of it but hardly know how to use it, but it seems to be doing its job. I’ve had a few problems with it when I first got my first RHEL5 server and redhat helped resolve the issues and said it would be fixed in the next release.
So a rogue binary would just bypass SELinux? Beautiful. What’s the point of SELinux again?
“””
So a rogue binary would just bypass SELinux? Beautiful. What’s the point of SELinux again?
“””
Traditional file permissions, however, would not be bypassed. Assuming, of course, that one did not neglect to double check them out of a false sense of security conferred by SELinux, or due to allotting too much time to resolving some subtle bug in a vendor-supplied SELinux policy. 😉
Edited 2007-10-22 05:42
Hmm..what’s with the mod’ing down of almost every post I (and you) make anyway?
While it is somewhat flattering in a way that someone is “after you” it’s magnitudes more times pathetic.
Oh, that’s cyclops. He’s been at it for weeks now. I just ignore him. People come along later and mod them back up, so I don’t worry about it. 😉
Come on guys – UNIX and UNIX like systems have always been traditionally harder to use and harder to secure than non UNIX systems. Non UNIX systems seek to appeal to the masses, and you have a conundrum then – ease of use vs security. You cannot have both, it’s one or the other. All those Linux refugees from Windows that want to dumb down Linux, rather than get off their asses and learn are what’s causing these problems imho. Call me elitist, but these Windows refugees have done a lot of damage to GNU/Linux imho.
Dave
I’m unable to reproduce on Fedora 7 — I’ll definitely try to reproduce on a vm tomorrow and let you know if I find the problem.
/etc/cups/printer.conf should have a type of:
cupsd_rw_etc_t
If it doesn’t that could very well be the problem. And if you don’t want SELinux on your machines, simply add selinux=0 to the kernel line of your grub.conf.
No software is free from bugs — if this bothers you, you should file a bug report at bugzilla.redhat.com.
Perhaps it has the world to do with the way you approach the subject and the tone you take. I never personally called you dumb and/or lazy. But honestly, if you’re deploying RHEL5, shouldn’t you at least learn about the security features in your OS a bit more? Don’t you want to learn what the OS is capable of doing?
How so? You haven’t explained how it is a round peg being put into a multiple of square holes? I’m not trying to raise your ire, just quite curious as to why you are so opposed to this tool being run on a regular server or workstation(especially when it can be easily turned off)?
“””
“””
Of course! How could I have missed something so simple and obvious!
“””
“””
Actually, it is better to set it to “Permissive” in /etc/sysconfig/selinux. That way, you can still use it in an advisory fashion, but without all the breakage.
“””
“””
It’s a matter of allocation of resources. SELinux is not the most cost effective expenditure of my time. Perhaps when the stock SELinux policies get better and stabilize. When they are not so buggy. And when better command line tools exist to diagnose and assist in the correction of SELinux-caused problems, it will be more suitable.
“””
“””
I believe in using the right tool for the job. More traditional security policies are safe and effective when used correctly. Most security problems are the result of being lax in the basics, or of making a simple mistake somewhere. How much easier it is to make a simple mistake with an over-engineered, overly-complex beast like SELinux! SELinux is a rampant violator of the KISS principle, a principle which I hold very dear. And (with current policies) it frequently interferes with the normal administration of machines.
Those things make me distrust it. And those things make it a round peg, IMO.
AppArmor sounds interesting, though. I get the impression that it just *might* be worth spending some time studying.
Edit: BTW, I do not object to RH and Fedora including SELinux. What I find objectionable are those ubiquitous SELinux fans who come out of the woodwork to Tsk! Tsk! whenever another admin comes to the quite reasonable conclusion that SELinux is not the right tool for his purposes and disables it.
Edited 2007-10-22 03:00
What I have found from working with it is it requires a lot of knowledge and a learning curve but it is very complex from a administration stand point.
The way I have found to deal with it is by buying a book and having to study how the object model works and how to set it up to work without locking out the users. Time consuming and more than likely a lot of bumps in the road ahead.
The secret to permissions is to grant the least amount to perform the task at hand, you can always add but it is very, very difficult to remove permissions once in place.
Fair enough — however, it makes me wonder how informed that admin is who comes to the conclusion to disable it. I suppose informed enough to know that he has to do a little bit more to get things to work, but I suppose not informed enough to know how to go about those items which would ultimately result in a system with Mandatory Access Controls instead of a user-run discretionary access control only system.
You do make good points with the above and those statements of yours are fair.
Let me ask you this. How many machines do you admin? And what percentage of them are on networks behind a firewall? Those factors make a difference regarding the relative value of time allocated to SELinux firefighting.
While the number of machines I currently admin is only at 10, they are all behind a firewall.
Indeed — those factors can make a difference regarding the value of time for “SELinux firefighting.” However, once you figure out one problem with SELinux, you’ve figured it out for all of your machines. Also, the more time that you spend working with it, the quicker you become at fixing the problems.
Have you looked into setroubleshoot? You can see what it catches at the command line by doing:
sealert -a /var/log/audit/audit.log > analysis
and then reading analysis. This is the same output that the GUI form of sealert gives you, but at the command line. It gives you a description of each SELinux error, suggestions on how to get around it/fix it, and a full synopsis of the avc message.
I also tried to reproduce your issue with a RHEL5 Xen guest of RHEL5. I had SELinux set to enforcing and did:
lpadmin -p printer -v lp0
I then confirmed with lpq -P printer that the printer was indeed there. I rebooted, confirmed again that the printer was there, and then looked at /etc/cups/printer.conf and saw that indeed the printer was there.
What filesystem type is your /etc on? If you’d like to go further on this, I’d be curious to see an ls -Z on your /etc/cups/ directory.