Civilizing SELinux

Posted Nov 26, 2004 5:10 UTC (Fri) by spender (guest, #23067)
In reply to: Civilizing SELinux by Method
Parent article: Civilizing SELinux

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?
If so, how much would RedHat pay for information on an information leaking vulnerability in SELinux for a physical, local user?
I've sold all my Exec-Shield exploits (that still work!), otherwise I'd offer those as well ;\

to post comments

Civilizing SELinux

Posted Nov 26, 2004 5:34 UTC (Fri) by Method (guest, #26150) [Link] (6 responses)

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:
1) Exec-shield has nothing to do with SELinux.
2) Redhat hiding bugs or whatever has nothing to do with SELinux.
3) Fedora's SELinux implementation has nothing to do with SELinux itself.
4) Congratulations on those Exec-shield exploits you sold, I hope you bought something nice with them.

Civilizing SELinux

Posted Nov 26, 2004 5:55 UTC (Fri) by spender (guest, #23067) [Link] (5 responses)

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] (4 responses)

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 (guest, #23067) [Link] (3 responses)

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] (2 responses)

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 (guest, #23067) [Link] (1 responses)

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...