On Wed, Sep 01, 2004 at 10:29:34AM -0400, Colin Walters was heard to remark: > [ The CC list here is rather nuts, someone needs to trim it...] > > On Tue, 2004-08-31 at 17:44 -0500, Linas Vepstas wrote: > > > Every now and then, I look at SELinux, and I get scared away by its > > complexity. > > It is actually not that complicated, but if you're unfamiliar with > mandatory access control (as I was when I first started learning about > SELinux), it does require understanding some theory before you dive in. Hmm, I thought I understood MAC; I was refering to the large numbers of rules in SELinux. Its not obvious (to me) that there isn't a path through those rules that allows privledge escalation. For example: and correct me if I'm wrong, but its quite possible to write a complex rule set that intentionally leaves 'holes' allowing for priveledge escalation. Thus, by extrapolation, its quite possible to write a set of rules that accidentally do the same. When one is presented with a set of rules, how does one know that they don't have a hole? Answer: one audits the rules. Unfortunately, there are a lot of rules: last time I looked at one of the config files, it was thousands of lines long. Thus, a short, simple audit performed by one person seems out of the question. Now, as to auditing... > it's too complex? I can certainly find plenty of examples of people not > understanding Linux on linux-kernel; does that imply Linux is too > complex? We've had a fair number of "eyeballs" read the linux kernel, and thus base our trust in its security on that. However, the SELinux rules are unlike the kernel in an important way: they are config files. This allows allows some anonymous fedora/debian/gentoo maintainer to do something dumb like "gee, my USB camera doesn't work with udev, but then when I change this selinux rule, it does", and poof, you've lost the security. I'm presuming that this kind of mucking around is far more common than altering lines of source in the kernel that weaken security. But I base my presumption on real life: go to any LUG, hang out with any sysadmin long enough, and you will see them make changes to config files that are dangerous if not outright incorrect. Sysadmins are, as a species, people who work with incomplete knowledge of the systems they administer. > > Compare this to less complex security provided by e.g. the Linux > > VServer project. > VServer isn't solving the same problem as SELinux. Yes, that's right. I did try to point that out ... > That way, if e.g. the bind > daemon running in one of the virtualized servers gets cracked, it > doesn't mean a compromise of the whole virtual server. No... If the bind deamon gets cracked, it doesn't compromise the 'whole'; it only compromises root and anything else running in that context. It does not (in theory) compromise root in the other contexts. In other words, one of the servers could be 0wned by someone truly hostile, while the 'whole' remains (theoretically) safe. > Now, you can use a virtualization technology as a primitive form of > separation by running e.g. your MTA in one virtual server, your name > server in another, etc. But that's rather painful, and is only an > approximation to least privilege. Yes, this is exactly what I'm thinking of. But its not painful, it solves 90% or 100% of the needs of a 'typical' ISP/ASP/web server admin. Yes, this is indeed a blunt tool... see below: > > Another example: Way back in the kernel-2.2 timeframe, I hacked on > > something neat: 'LOMAC': if you came in from a network connection, > > you lost permission to do almost anything, other than to e.g. webserve. > > The system was simple, worked well, the kernel patches were easy to audit, > > you could go home without worrying about priveledge escalation. > > That's also a rather blunt tool; SELinux is much more flexible. What I'm proposing here is that bluntness can be traded for increased assurances and increased ability to audit the code for "correctness". Yes, SELinux is far more flexible; but this is exactly what scares me. I once thought about re-implementing LoMAC as a ruleset atop of SELinux. I'm pretty sure that this is possible, but I started thinking that the complexity of the ruleset may introduce holes that voids the effort. And that thought disturbed me. Along with Lomac's 'bluntness' comes 'zero configurability': its something that could be installed on the proverbial 'Grandma's Linux desktop', and provide additional security without causing pain. With selinux, its not only not zero-conf, but its also not clear (to me) if the rulesets that install with debian/fedora/etc. actually provide any additonal security at all against network breakins. If the rulesets do indeed provide this protection, then there is a perception/marketing problem: people like me "don't get it" from just skimming the selinux web pages. I'd prefer to get all the benefits of SELinux without having to RTFM. --linas
