| |||||||||||||
|
| |||||||||||||
SELinuxSELinuxPosted Oct 20, 2009 20:18 UTC (Tue) by njs (subscriber, #40338)In reply to: SELinux by spender Parent article: LPC: Three sessions from the security track I'm not an SELinux user.
I am already familiar with But fyi, if I didn't already know what you were trying to say, I'd never get it from your post. I said SELinux is intended to lock down programs, and you just respond "wrong, wrong, wrong" and bemoan your sad fate where idiots like me keep saying things that... well, are true, actually, SELinux *is* designed for locking down programs. It is, of course, very important that it does not and can not guarantee effectiveness (despite all those fancy formal models), and also doesn't address the most important modern desktop threat models, but you didn't actually *say* that. I think it's absolutely a good thing to open people's eyes to a more nuanced view of security, involving actual discussion of threat models, mitigation versus provably secure, reality-based estimates of exposure, all that good stuff. But your posts seem more interested in showing how terribly ill-used you are than in making the world a better place and frankly, dude, I think grsec's goals are awesome and I still don't care about your personal feelings. Esp. when you're so willing to sacrifice nuance and accuracy (SELinux *has* mitigated attacks, for all its imperfections) on the altar of axe-grinding.
(Log in to post comments)
SELinux Posted Oct 20, 2009 23:58 UTC (Tue) by spender (subscriber, #23067) [Link]
Do you know the definition of the conjunction "can't"?
Do you know the definition of "arbitrary"?
Let's break it down, since you didn't grasp my post apparently:
You said:
You said that what I quoted from you was "true" -- in what world?
If what you said was true, then an attacker *can't* (your emphasis) choose a kernel exploit as his/her arbitrary code to execute within the context of firefox (the recent perf_counter vuln is a perfect example of one that would work flawlessly), allowing the attacker to change UID to 0, disable SELinux, drop a shell, and then delete your home directory. Is that what you're saying? That that's impossible? Asterisks around "can't" suggests emphasis, and in this case, certitude. I would suggest wrapping it in quotes, or not using the word at all.
I'm really not understanding this: you say something explicitly that is absolutely wrong, I quote your exact sentence and point it out, then you not only insult my understanding of the subject, but claim that what you said was true. Please explain this to me, because clearly I'm in need of education.
Either you're not familiar at all with what I'm trying to tell you, or you don't know the answer to my initial two questions.
-Brad
SELinux Posted Oct 20, 2009 23:59 UTC (Tue) by spender (subscriber, #23067) [Link]
Contraction rather ;)
SELinux Posted Oct 21, 2009 4:11 UTC (Wed) by njs (subscriber, #40338) [Link]
Well, okay. Now look at the first half of my sentence, and the surrounding context. I said SELinux is *for* locking down stuff further than it would be otherwise (giving the firefox example as a clarification on what this meant), as part of explaining the difference between it and PolicyKit to someone who was confused on this basic point.
We both know perfectly well that what I described is a design goal for SELinux -- and that's true quite independently of whether this is a useful goal, and whether or not SELinux actually accomplishes it.
Now, absolutely, I was a bit lazy -- I could, maybe should, have gone further and pointed out that SELinux was far from a panacea. Arguably people are so commonly confused about what to expect from "security" code that we have a responsibility not to mislead them further, even by omission. And if you'd called me on that, then I'd have agreed and we'd go on our way, having made the world a slightly better place.
Calling me "wrong, wrong, wrong" and assuming that if I didn't bring up this tangential point then I must be completely ignorant -- that's a little different!
Yes, I really have read your posts here before and understand what you're saying. What I'm trying to say is that 1) I basically *agree* with all the factual/technical content you're trying to get out there; if anything, I'm on your side, but 2) you argue in such grating ways, mixing some excellent points with so much dishonest rhetoric, irrelevant grudges, and derailing of other discussions onto your hobbyhorses, that I'd rather not engage with you myself, and have perfect sympathy for kernel developers who ignore you.
The end result looks almost like a loop where you rant and rave about how no-one listens to you, everyone else goes "uh, maybe he has some points but I'm not sticking around to find out", and then this proves that no-one listens to you and confirms your misunderstood genius cred. If that works for you, great, but leave me out of it. We've all been misunderstood -- heck, Linus slanders some of my work on a pretty regular basis -- but if our goal is to actually accomplish stuff then we just ignore it and do our best make progress anyway with the hand we're dealt. (The irony is that doing this is what *actually* convinces bystanders that we're awesome, in a way that explaining how those idiots don't appreciate our work does not.)
SELinux Posted Oct 21, 2009 6:04 UTC (Wed) by dlang (✭ supporter ✭, #313) [Link]
I am not frequently in agreement with spender, but SELinux has been advertised as being able to block things like deleting home directories (in fact IIRC, when I first heard of it, it was with "here is the root password to a system that's reachable on the Internet, because it's running SELinux you can't hurt it."
SELinux Posted Oct 22, 2009 0:05 UTC (Thu) by nix (subscriber, #2304) [Link]
What happened to that machine? Is it still root-exposed to the net? :)
SELinux Posted Oct 22, 2009 1:44 UTC (Thu) by njs (subscriber, #40338) [Link]
It's here (and has been since 2002):
http://www.coker.com.au/selinux/play.html
And was online as recently as February:
Though I'm getting "no route to host" right now -- perhaps because it is getting warm again in Australia :-) (see last link)
SELinux Posted Oct 21, 2009 13:21 UTC (Wed) by spender (subscriber, #23067) [Link]
What I did was quoted a sentence of what you wrote, which no amount of context could have made true. You were very explicit in what you wrote, and that is what my comment of "wrong, wrong, wrong" was explicitly directed toward. If you had left that part out, I would have had no real objection to your post.
SELinux in general improves security by reducing attack surface.
It's the:
that I take issue with, and will continue to point out when I see it. I wrote a section of our Wiki (http://en.wikibooks.org/wiki/Grsecurity/The_RBAC_System#L...) that puts the information up front (it's the first thing after describing what the RBAC system is) that we plan to update soon with more of a historical lesson of the environment from which access control systems and models originated, how the problem being solved at the time was curbing the problem of careless (specifically, not malicious -- they were considered trusted) administrators.
It was about people control, not program control. Modern day threats like determined/skilled/funded attackers or even modern networking weren't even part of the picture. Any time networking was discussed, it involved private, trusted networks where all machines involved were protected under the same security model. Clearly the Internet is not such a network.
So what you see from people who drink the kool-aid of these old security models and concepts is erroneous extrapolation to a modern environment that these things they hold in such high regard weren't even designed for. It's this kind of misguided illusion that I've been trying to inject doses of reality in for some years now.
As for actually accomplishing stuff, we spend a lot more time doing it than we do talking about it (for instance, I only recently wrote a list of what we developed over the past couple months: http://grsecurity.net/news.php#develup) but that doesn't have anything to do with the original discussion.
-Brad
|
|
||||||||||||
