Recent Features
| |||||||||||||
Civilizing SELinuxCivilizing SELinuxPosted Nov 26, 2004 4:17 UTC (Fri) by Method (guest, #26150)In reply to: Civilizing SELinux by spender Parent article: Civilizing SELinux
Congratulations on the context destruction there. The context of the above quote was "The end result is that, even if named falls to a remote code exploit, there is very little that exploit can actually do."
So, a code exploit [in named] would be contained.
You speak as if some other access control system solves kernel exploits and we all know that isn't true, don't we ;)
And on the topic of policies.. I'm sure you believe learning mode produces better policies but that isn't true. Learning mode only tells what an application *tries* to do, not what it *should* do. If you knew anything about SELinux or had ever looked at the current policies you'd see the many cases where a policy writer feels an application is overstepping it's bounds and notes that it runs without the requested access and he puts a 'dontaudit' in the policy to squelch the denial while still preventing the access.
(Log in to post comments)
Civilizing SELinux Posted Nov 26, 2004 4:47 UTC (Fri) by etbe (subscriber, #17516) [Link] One point that should be mentioned when discussing policy generation is the bugs in applications that are discovered when writing policy.
ifdef(`hide_broken_symptoms', `
dontaudit ifconfig_t dhcpc_t:{ packet_socket udp_socket } { read write };
dontaudit ifconfig_t dhcpc_state_t:file { read write };
')dnl end broken symptoms
The above policy from dhcpc.te is to cover the bugs in the dhcpd which
allow inheriting open file handles when inappropriate. The file handles
in question should be explicitely closed before exec or set to
close-on-exec by fcntl. This is only a minor bug and doesn't seem
exploitable so we just put in dontaudit rules, eventually the dhcpd bugs
will be fixed.
Another example was a kernel bug that allowed init to inherit file handles to the initrd. I believe that I was the first person to discover that bug as it showed up in my log files on boot in an obvious manner. It is possible that someone else found the bug first (AFAIK no-one reported it first), that bug was not particularly difficult to find (it showed up in lsof), but it was a lot more obvious when running SE Linux. These are just two examples of how SE Linux policy when written correctly will expose bugs. If the policy was written in a manner of "let's run it once and allow everything it tries to do" then such bugs would be obscured. Finally there are many situations in which programs have to be permitted access that they don't normally request. Every daemon must be granted syslog access even though some daemons do not use syslog when things work well.
Civilizing SELinux Posted Nov 26, 2004 5:10 UTC (Fri) by spender (subscriber, #23067) [Link] Congratulations on your attempt at a rebuttal by "context destruction." Yes, the context of the above quote was what you said. "There is very little that exploit can actually do." The author then lists in the next sentence what that exploit could do IN THE WORST CASE. Nothing in your text refutes this. You're just trying to attack a straw man because you know you're wrong here. Unless you really believe that the worst case, as the author claims, is that dns replies could be modified.
Also, you speak as if some other system isn't implementing things that aim to stop kernel exploits. Apparently your vast security knowledge has overlooked the RANDKSTACK and KERNEXEC features of PaX. Maybe RedHat will rip these off 3 years from now too and take credit for them.
I've looked at the current policies for SELinux in Fedora Core 3, thanks. If you think they'll actually protect a server, you're seriously deluded. Stop drinking the SELinux kool-aid.
Does RedHat buy exploits for their own code?
Civilizing SELinux Posted Nov 26, 2004 5:34 UTC (Fri) by Method (guest, #26150) [Link] I said "access control systems" also.. Nothing keeps someone from running PaX with SELinux as Hardened Gentoo's SELinux implementation does. Those have absolutely nothing to do with mandatory access control (The scope of SELinux is MAC only)
Do you want some sort of prize for successfully integrating someone elses memory protections into grsec.. PaX is in no way reliant on your (or anyone elses) access control systems, in fact we have SELinux permissions to control PaX in Gentoo.
I'm not talking about Fedora Core 3 or it's policies, I see nothing refering to that.
As for the rest of the comment, if you have beef with Redhat and/or Exec-Shield (as you clearly do) take it up with them and not SELinux. SELinux wasn't developed by Redhat, they merely implement it. You have made zero objections to SELinux and only to Fedora's implementation of it (and not really much there)
SELinux also has other uses that you (and other anti-SELinux zealots) seem to be unable to address. SELinux allows strong control on information flow. There exist many environments where information flow restrictions are absolutely necessary and SELinux has the ability to arbitrate that on many more access vectors that grsec, IPC for example. (and this isn't all, I'd rather not fill up this comment with the 53 object classes SELinux covers)
Further, there exist tools *today* to analyze SELinux policies for possible information flow and execution paths, does grsec have those?
All-in-all SELinux is a very professional project with a great community and great collection of tools. I'm sorry you feel the need to FUD it.
For future trolling please note that:
Civilizing SELinux Posted Nov 26, 2004 5:55 UTC (Fri) by spender (subscriber, #23067) [Link] Again, the same old "granularity = security" argument, which is basically the only position SELinux users can have. As we all know, inserting data into message queues (a HUGE attack vector, from all the evidence I've seen on the Internet) is much more important than preventing kernel exploits. Clearly, the best security solution is one that focuses on these WIDELY used attack vectors like using gettimeofday() and semaphores, and ignores things like kernel exploits, keeping X from writing outside of necessary regions in /dev/mem, preventing arbitrary data writes to /etc/shadow, etc.
Nothing keeps someone from running PaX with SELinux indeed, but that doesn't mean SELinux does the things PaX needs to be used in production. SELinux does none of this other than using the PaX MAC hooks. So sure, someone can use PaX with SELinux, and they'll have a system wherein PaX can be easily bypassed, almost as bad as Exec-Shield.
I don't think you understand at all the userbase you're trying to force SELinux upon (I can tell you, they don't even know what IPC stands for, let alone know what its security implications are), and that is why SELinux will never be sucessful, no matter how much hype you continue to generate about it.
Civilizing SELinux Posted Nov 26, 2004 6:30 UTC (Fri) by bluefoxicy (guest, #25366) [Link] SELinux CAN be deployed with PaX, as method said. As I said in an earlier post, we don't need SELinux to end all security holes; we need SELinux (or RSBAC or GRSec or something), PaX, the IBM SSP patch, heavy code auditing (mudflap?), and several other things. We also need administrators who are awake and paying attention, despite the impenetrable fortress they live in; holes are only useful until someone sees them and fixes them, and if you're not looking, neither of those happen. I cannot comment on which MAC system is "best," but I will say that based on the arguments given here, it seems that SELinux and GRSec both have components that eachother do not have. Now I suggest you both stop slapping at eachother and screaming like two geeks from Revenge of the Nerds fighting over a girlfriend and start taking serious looks at what each system is missing. Both of you are claiming the other system is lacking; fix both. We don't stop l33t h4x0rz skr1pt1k1dd13z by standing around seeing who can urinate the longest off the side of a building.
Civilizing SELinux Posted Nov 26, 2004 7:06 UTC (Fri) by spender (subscriber, #23067) [Link] Apparently you didn't grasp the content of my post, as noted by your comment: "SELinux CAN be deployed with PaX." If hearing it from me that slapping PaX onto an SELinux machine does not constitute production usage of PaX, ask the PaX team. They'll tell you the same thing. But of course, you know better than I do. But if that's your belief, please do continue using PaX and SELinux together (since Method is such an expert on all things security-related and is such close friends with the PaX team), and enjoy your false sense of security.
Civilizing SELinux Posted Nov 26, 2004 7:26 UTC (Fri) by bluefoxicy (guest, #25366) [Link] How about:
PaX & SELinux & whatever from GRSecurity is useful & Forkbomb Protector & IBM Stack Smash Protector & Stateful Firewalling (netfilter) & Packet filter firewalling (netfilter) & Dan's Guardian & ClamAV (after adding heuristics) & snort-inline & DigSig & UML & Discressionary Netfilter (non-existant hack that could be done using iptables, sudo, and some scripts)
SE isn't everything. PaX isn't everything. GR isn't everything. Firewalls aren't everything. Stack smash protection isn't everything. You need to combine everything to get everything.
Again, I won't say either of you is right; I'm just concerned that this argument is a poor way to convey your points, and that you are dwelling on defending your egos far too much more than you are on discerning what's wrong on each side and fixing those.
Civilizing SELinux Posted Nov 26, 2004 7:56 UTC (Fri) by spender (subscriber, #23067) [Link] Nope. You missed the point again. I'm not talking about having a complete security system. I'm saying that there are things that are discussed in the PaX documents that someone implementing PaX in production environments must handle. PaX itself does not handle these things because they may be implemented differently by different integrators. SELinux does not implement any of these things. The only thing PaX-related that SELinux implements is the MAC hook, which is more of a useful feature than a necessary component of the PaX model.
All this bragging about "information flow graphs" is ridiculous. The assumption involved (that at no point was a kernel exploit used) in such graphs is one that no security-conscious person can hold. These graphs are a guarantee of nothing (despite claims we've seen to the contrary already). Ask yourself what's more probable: that someone owns the system by finding some app on the system that uses message queues, then sends some specific data to it that causes a system compromise...eventually...somehow, or that the attacker owns the system by using a kernel exploit and bypassing SELinux completely? I don't know what world Method lives in (though I surmise it's an idiot's ivory tower) or what kind of attackers exist in this world, but any real world experience should certainly give one pause when one hears this kind of propoganda from SELinux proponents.
Civilizing SELinux Posted Nov 26, 2004 16:51 UTC (Fri) by bluefoxicy (guest, #25366) [Link] I'm not missing the point. I'm saying that we need to focus on more important things, like correcting these issues. I'm fairly sure Method is only concerned with GR vs SE in the context of the ACL, and is irritated by your trying to justify your own MAC system's shortcomings with (valid) points about the extra restrictions GR brings along.
Perhaps reimplement the GR protections around SELinux and try to get them into mainline?
Civilizing SELinux Posted Nov 26, 2004 19:55 UTC (Fri) by riel (subscriber, #3142) [Link] I've sold all my Exec-Shield exploits (that still work!), otherwise I'd offer those as well ;\Selling exploits for money?! That kind of attitude worries me...
|
|||||||||||||