Recent Features
| |||||||||||||
SELinuxSELinuxPosted Oct 13, 2009 8:25 UTC (Tue) by michaeljt (subscriber, #39183)In reply to: SELinux by kleptog Parent article: LPC: Three sessions from the security track
The basic idea of UNIX permissions is simple, but gets hairy once you start including setid bits, setgid on directories and the sticky bit. It's used for everything from protecting home directories to providing controlled priveledge escalation to stopping people from deleting other people's temp files and ensuring new files are readable by certain groups. However, it does have the advantage that most people understand it, which is not true for SELinux.I have to agree with you there (on both points). Apart from basic usage of setuid I have similar feelings about those "extra bits" to SELinux :)
What makes it mandatory access control is that the owner of the object doesn't get to say what happens, the policy is decided elsewhere.As far as I can see though, in practice it is normally used for restricting things done by the superuser account, which PolicyKit does using "standard" Unix mechanisms - I could imagine a variant on PolicyKit which used a setuid helper instead of a daemon waiting over DBus (not criticising DBus, but it is aimed at doing things from a running desktop, and not at a deeper level in the system, like e.g. (re-)starting DBus itself!), and which starts helper applications as other users than root where appropriate (classical example, passwd: make it owned by user passwd, and have a tool with user permissions get the new password and call a PolicyKit-style helper running as user passwd to actually set it. And there you have your configurable policy (PolicyKit's policy), your roles (the user passwd) and your restrictions (only do what user passwd is allowed to do, namely, change the password file).). Of course, SELinux does do many other things, like competing with PaX by preventing applications from changing their code while running. See my point above :)
(Log in to post comments)
SELinux Posted Oct 20, 2009 9:22 UTC (Tue) by njs (guest, #40338) [Link]
PolicyKit is for allowing controlled privilege escalation -- e.g., letting a user muck with /etc/passwd.
SELinux is for locking down stuff further than it would be otherwise -- e.g., making it so your firefox *can't* delete your home directory, even if someone tricks it into loading a bunch of arbitrary code from the web and executing it. All the complicated stuff is just the messy work of explaining to the computer exactly what you mean by "home directory", "firefox", and "can't delete".
This isn't just a heuristic all-else-being-equal kind of distinction; the way the kernel is written PolicyKit *can't* forbid anything that would otherwise be allowed, and SELinux *can't* allow anything that would otherwise be forbidden.
Sure, sometimes the thing you want to lock down is run by root, because it's some system daemon that (due to limitations in the traditional unix model) has to be run as root -- 'sshd', say, or your example, 'passwd'. Neither of these programs needs to do *everything* root can do, though -- a bug in passwd (or PolicyKit!) should not allow me to load kernel modules or reformat the hard drive... So you want something more fine-grained.
SELinux Posted Oct 20, 2009 12:17 UTC (Tue) by spender (subscriber, #23067) [Link]
"making it so your firefox *can't* delete your home directory, even if someone tricks it into loading a bunch of arbitrary code from the web and executing it."
This is wrong, wrong, wrong. How many times do we have to educate SELinux users on this?
In case you forgot, here's 8 videos for you to watch:
Or take it straight from the horse's mouth:
In the real world, attackers aren't interested in deleting your home directory. They sure are interested in launching kernel exploits though.
-Brad
SELinux Posted Oct 20, 2009 19:48 UTC (Tue) by nix (subscriber, #2304) [Link]
They're not interested in deleting your home directory, but they're
certainly interested in scanning it for what looks like online banking login details. (Unfortunately, SELinux won't work here, and neither will anything short of a security system inside the browser itself: because it's likely that the banking login details must be stored somewhere the browser can access it, because you'll be getting at the online banking site through the browser. Doing absolutely everything through the browser smacks very much of too many eggs in one basket for me.)
SELinux Posted Oct 20, 2009 20:18 UTC (Tue) by njs (guest, #40338) [Link] 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.
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 (guest, #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 (guest, #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
Types of attack Posted Oct 22, 2009 8:49 UTC (Thu) by Cato (subscriber, #7643) [Link]
Ransomware exists on Windows that encrypts a user's data files, then asks for a payment for the key to decrypt this data - see http://en.wikipedia.org/wiki/Ransomware_%28malware%29 - it's been around for 20 years now, and a more recent example from July is here: http://www.sans.org/newsletters/newsbites/newsbites.php?v...
These show that home directories are of interest to malware writers, quite apart from scanning for passwords, financial information, etc. There is no reason why these attacks could not hit Linux, particularly through cross-platform browser/Flash exploits.
Blanket statements on the intentions of attackers aren't very useful - there are many sorts of attackers out there.
|
|||||||||||||
