Weekly Edition
Return to the Kernel page
| |||||||||||||
Quotes of the week
I don't think anyone is smart enough to configure Apache with
SELinux. I've installed Apache maybe 20 times in my life, which is
plenty, and I eventually realized it was SELinux and just turned
the damn thing off after an hour of trying to fix it.
-- Dave Aitel
Keep in mind as well that SELinux "complexity" is purely a
reflection of complexity in Linux; SELinux just exposes the
existing interactions and provides a way to control them. The
SELinux mechanism itself is fairly simple.
(Log in to post comments)
Quotes of the week Posted Apr 20, 2006 6:44 UTC (Thu) by loening (guest, #174) [Link] No, SELinux is complex. It's a whole 'nother layer of complexity over the linux system, which is already overly complex to begin with.
And the worst part about it, is that the error reporting of SELinux is attrocious. Through experience, I now know that if anything goes wrong on my system, the first thing to try is to disable SELinux. NVidia drivers don't work? Disable SELinux. VMWare doesn't work? Disable SELinux. Acroread doesn't work? Disable SELinux. Can't figure out how to get anonymous ftp to work? Disable SELinux. Want to be able to write to your www directory with samba? Disable SELinux.
There are right ways to handle all the above situations, but you won't find them in your standard documentation. For instance, neither the vsftpd man page, nor the vsftpd configure file makes any mention that there are any magical SELinux booleans that need to be set to make things happy. Nope, those instructions are in the man page ftpd_selinux. I bet that's the first man page you thought of looking at when vsftpd didn't work.
Here's my current favorite one. On my Fedora 5 box, Apache will seg fault if somebody downloads a file using the Safari browser. That's right, you can crash my web site by using Safari. Pretty cool eh? You know what the fix is? Disable SELinux. I don't even know where to begin debugging that one.
Quotes of the week Posted Apr 20, 2006 8:39 UTC (Thu) by james (subscriber, #1325) [Link] Red Hat Bugzilla would be a good start...
Quotes of the week Posted Apr 20, 2006 12:15 UTC (Thu) by nix (subscriber, #2304) [Link] Sorry, but a security system which is too complex for anyone except distributors with dedicated security hackers to configure (and probably too complex for anyone to configure *safely*; how many bugs are there in that policy again?) is from any practical point of view nearly useless.
Quotes of the week Posted Apr 20, 2006 18:34 UTC (Thu) by smoogen (subscriber, #97) [Link] Wow.. I remember that exact argument about Unix chown/chmod/chgrp and stuff from a bunch of windows guys. DOS doesnt have them, why do we need them?
I remember having to go through a LOT of systems in the mid/late 1990's where almost everything had been chmod'd 666 or 777 because something hadnt worked and that was the fix to get whatever was broken working.
Not saying that selinux isnt too complicated.. but my feeling of deja-vu is strong.
Quotes of the week Posted Apr 22, 2006 22:00 UTC (Sat) by nix (subscriber, #2304) [Link] Indeed this is many people's argument against ACLs.
Complexity is the enemy of security, and having used it for a while I'm fairly sure that SELinux is way over there on the `too complex' axis.
Quotes of the week Posted Apr 20, 2006 20:58 UTC (Thu) by jeskritt (guest, #4092) [Link] I jsut put my boxes in permissive mode. Run them for a couple weeks like that, then dump the /var/log/audit/audit.log through the audit2allow program. This gives you the rules you need for your box to run. then:
1) Add them to your /etc/selinux/targeted/src/policy/domains/misc/local.te
you'll need the policy sources installed
Quotes of the week Posted Apr 21, 2006 9:37 UTC (Fri) by rwmj (subscriber, #5474) [Link] When I need to configure my firewall, I first run my box in "permissive"mode for a few weeks, connected to the internet without a firewall. Then I look at /var/log/messages to see who's been attacking me. Then I simply add those attackers to my firewall and go. It's so easy.
Rich.
Quotes of the week Posted Apr 22, 2006 0:48 UTC (Sat) by erich (subscriber, #7127) [Link] You're getting it wrong.He's monitoring the *correct* behaviour of his system to obtain a whitelist, not monitoring *attackers* to filtert them via a firewall-like *blacklist*.
When you're talking iptables this would be using the LOG target with a rate limit, then adding approriate iptables rules for the good traffic - then setting OUTPUT to DROP by default...
Any whitelist based (read: reject by default, the only reliable approach to system security) system will need to learn what acceptable behaviour is.
However, not all features in all services have already been whitelisted. I guess you might not even want to whitelist all of them (thats why there are tuneables/booleans in SELinux). And every now and then you'll be using a local extension.
For example, my OpenVPN server does update the DNS server and it has a status file, which is then read by munin for statistics.
For obvious reasons, OpenVPN *by default* was not allowed to update my DNS or even write it's state file. Nor was munin allowed to read the status file (which has no common location, this is all my own scriptwork)
Quotes of the week Posted May 14, 2006 5:50 UTC (Sun) by pimlott (guest, #1535) [Link] You missed the joke. (Nicely done, rwmj.) He's not monitoring the *correct* behavior, he's monitoring whatever behavior his system happens to exhibit during the training period. While running in "permissive mode". So for all he knows, he's hacked six ways from Tuesday. And then he makes that behavior law. Brilliant.
He should at least put a notice on his web page: "Please don't attack me for a couple weeks. Thanks."
Quotes of the week Posted Apr 20, 2006 15:52 UTC (Thu) by shahms (subscriber, #8877) [Link] /var/log/audit/audit.log would be a good place to start looking. If the action was denied by SELinux there will almost always be an entry in there. I do agree that the existing documentation is sorely lacking, but the "Disable SELinux" is entirely the wrong approach for a multitude of reasons. It may be appropriate for debugging problems, but is not the right way to do it. If disabling SELinux "fixes" the problem, that just tells you where to start looking. It's like any new subsystem, as a system administrator you have to learn how to start debugging it. Here's a hint: 9 times out of 10, these problems can be solved by changing booleans or fixing file labels, neither of which is any more complex than changing existing configuration settings or making sure files are readable by Apache. Smalley is correct, SELinux itself is not terribly complex, the security models it uses are relatively straightforward, the complexity comes from the comprehensive nature of the policy and the very, very fine-grained permissions it exposes.
Quotes of the week Posted Apr 21, 2006 12:41 UTC (Fri) by erich (subscriber, #7127) [Link] Sorry, but:"Deny by default" is the only way to get security Note that there is an unconfined domain in the so called "targeted" policy, which allows you to basically separate your system into a SELinux enabled part one without SELinux.
Quotes of the week Posted May 24, 2006 2:11 UTC (Wed) by Method (guest, #26150) [Link] I wrote a blog entry on this topic, it was about an experience with a vendor but I think the right answers are there. The vendors must be made aware that people don't want to disable SELinux, only then will they fix their software or document the issues.
http://securityblog.org/brindle/2006/05/21/software-not-w...
Quotes of the week Posted Apr 20, 2006 14:00 UTC (Thu) by jamesm (guest, #2273) [Link] The situation will improve in many cases soon with the introduction of new SELinux tools for detecting, analyzing and reporting problems.
Developers are currently working on a "bug buddy" type scheme, for general users and developers, as well as Eclipse-based tools for application developers.
Getting MAC into a general purpose operating system is extremely difficult, and in fact, has never been done before. The initial task has been to get the code cleanly into upstream and undertake the considerable engineering effort required to integrate SELinux into a community and then enterprise distributions, targeted at the relatively simple case of enhancing the security of a system with internet-facing services.
Over the last year or so, a huge amount of work has been going on in the infrastructure area, with things like modular policy, policy namespaces, reference policy and many other projects now completed which can provide a basis for moving forward on more general usability, desktop integration etc.
So much has been happening, that we've started this web site to try and track all the development in one place:
Systrace Posted Apr 20, 2006 14:43 UTC (Thu) by mheily (guest, #27123) [Link] SELinux is an interesting idea in theory but is not practical for common use. Besides, it was developed by the NSA for use within the U.S. Government to keep information secret even from system administrators; the FAQ states that it "enables a single system to be used by users with differing security authorizations to access multiple kinds of information with differing security requirements without compromising those security requirements."Unless you are in an organization that needs to keep top-secret information away from the 'root' user, SELinux is overkill. Besides, killing off the 'root' user is very uncool and not the UNIX way. Thanks to excellent work by Marius Erikson, Systrace has been updated to work with recent 2.6 and 2.4 kernels under Linux. It has been a standard feature of the OpenBSD and NetBSD kernels for years, but the Linux port was not maintained. I hope the major Linux distributors will take note and start packaging and distributing Systrace again.
Systrace Posted Apr 20, 2006 15:13 UTC (Thu) by jamesm (guest, #2273) [Link] Many (perhaps millions) of people are using SELinux in common use.
SELinux was in fact developed specifically for integration into general use operating systems (although it is also suitable for protecting highly sensitive information). One of the fundamental principles is policy flexibility, allowing SELinux to be deployed in a wide variety of different security scenarios by loading different policies.
For a good basic introduction to the design goals of SELinux and its implementation, see this OLS 2005 presentation:
http://www.nsa.gov/selinux/papers/selsymp2005-abs.cfm
Systrace Posted Apr 20, 2006 15:15 UTC (Thu) by jamesm (guest, #2273) [Link] (actually, it's not an OLS presentation, but SELinux Symposium)
Systrace Posted Apr 20, 2006 15:58 UTC (Thu) by shahms (subscriber, #8877) [Link] That "it was developed by the NSA for use within the U.S. Government to keep information secret even from system administrators" is simply not true. It is stated on the AppArmor FAQ and is just as incorrect there as well (along with a number of other assertions on that page). While MAC security systems in general can do this, with the exception of MLS (Multi-Level Security), most of the security models in SELinux are more focused on integrity than confidentiality.
SELinux is practical for common use. It is, however, new, different, and not particularly well documented at the sys admin level. There are a lot of recent developments making it far easier to use and significantly more modular that should help a lot with the perceived complexity. That perception has far more to do with the necessarily comprehensive nature of the policy and the general lack of familiarity with MAC.
Systrace Posted Apr 20, 2006 19:21 UTC (Thu) by mheily (guest, #27123) [Link]
For the record, I have never used AppArmor or looked at their FAQ; my assertions were based on reading the SELinux FAQ and asking myself 'Who built this, and why would anyone want something like this?'.
SELinux was a research project within the NSA. The defensive mission of the NSA is to "[protect] all classified and sensitive information that is stored or sent through U.S. government equipment". Therefore it is safe to assume that the rationale for SELinux was to enable MLS for sensitive government data; the only way to do MLS correctly on a single system image is to have MAC on all system objects.
When you look at the front page of the SELinux site, the second paragraph supports my hypothesis:
"End systems must be able to enforce the separation of information based on confidentiality and integrity requirements to provide system security. Operating system security mechanisms are the foundation for ensuring such separation. Unfortunately, existing mainstream operating systems lack the critical security feature required for enforcing separation: mandatory access control. As a consequence, application security mechanisms are vulnerable to tampering and bypass, and malicious or flawed applications can easily cause failures in system security."
So it seems that MAC is a means to achieve the end goal of MLS. To most non-government organizations, MLS is unnecessary, so the "pain" of architecting a complete security solution around MAC is not worth the "gain".
I'm not trying to say that SELinux will never become pratical and useful for the 'common admin'; over time, and given the enormous momentum behind it, I'm sure it will become the most successful and commonly deployed MAC system.
All I am saying is that right now we have pretty good cross-platform security mechanisms like chroot(2), privilege revocation, privilege separation, Sudo, and Systrace. Virtualization using Xen is another portable approach. You can also address buffer overflows using stack protection a la ProPolice or GCC's upcoming Mudflaps-based stack protector. Combine all these automated mechanisms with good coding practices, such as using Safestr or a similar string library instead of strncpy(3), and peer review of open and freely available source code, and you get a "layering effect" where flaws in one layer are caught in another layer.
SELinux is a comprehensive, radical approach to system security that has destabilizing effects on the entire software ecosystem. I prefer simpler incremental improvements to security, such as Systrace.
Systrace Posted Apr 20, 2006 19:44 UTC (Thu) by jamesm (guest, #2273) [Link] Your conclusions are incorrect, and I suggest reading the document I linked in reply to your initial comment.
|
|||||||||||||