Not a rhetorical question... http://www.theregister.co.uk/2009/07/17/linux_kernel_exploit/ The point of a multiuser OS, the whole entire point, period, is to provide safe isolation of different user account. So Torvalds' dismissal there disturbs me, but more so because it's accurate. A typical Linux install does not in any way guarantee isolation of user accounts, thanks to kernel holes, setuid binaries, privileged services, etc. That is a really serious problem. What is it about UNIX that makes these problems so prevalent, and what could be done to mitigate them (at least in theory) without breaking POSIX compatibility?
The name Unix (originally Unics) is itself a hack on Multics. The U in UNIX is rumored to stand for uniplexed as opposed to the multiplexed of Multics, further underscoring the designers' rejections of Multics' complexity in favor of a more straightforward and workable approach for smaller computers. Decades ago a MULTICS machines could be physically taken apart while users were logged in, moved part by part to another location and reassembled – all without the users knowing. We live in a world led by imbeciles; the popular modern systems are driven by economic utility to the sellers (proprietary lock in) not technical merit or good engineering principles. Want to know what the future is going to be like? Look in the past;
Hi lolwin(?), thanks for posting. I'm a little skeptical that Linux answers entirely to economic utility, since some of the biggest Linux projects (e.g. Debian) are community based. But UNIX and its clones seem to have stuck with us for some reason; Linux is a UNIX clone, and the vast bulk of server software I've seen is designed for Linux/UNIX and/or Windows NT, not for something with a whole different set of system calls... One gets a strong impression that UNIX's "good enough" design won out by getting there first. I guess what I'm wondering is, if it's possible to implement POSIX API compatibility on top of a sane OS, and make it actually reasonably secure vs. attempts to break out of a user account. Re the past and future of programming, I guess every step forward is greeted by cries from the old guard that it's too complex (as with Von Neumann and the assembler)? Though I feel like there are times when simplicity is desirable. e.g. look at Windows NT ACLs, which are more flexible than UNIX permissions by far, but I've seen them lead to problems in practice because they're hard to manage.
I'm with Linus. No problem there. People get permissions, so ... permissible things happen. There's a difference between design and usage. If you let people do things, things get done. Mrk
Hi everybody, First of all the following is based upon opinion rather than experience or proof. Anyway, how about the direction the BSD's are going ? (FreeBSD, OpenBSD, PC-BSD, etc). I assume that those operating systems are a slightly bit closer to Unix than Linux is ? I am a happy Linux user thus far, but I've taken a bit of interest into PC-BSD (FreeBSD with graphical gui on top). I like how they implement jails and (it seems) rather simple to use/setup a jail to isolate internet facing software. What I'm trying to say is, would a free- open- kind of bsd more like how the future could look like ? will always use linux I think, but seems like the bsd side of things are quite interesting as well. Maybe this is more a remark/question for a new topic. Would be nice to see a comparison between a linux server and a BSD server, just to see how well each would " handle " userspace or privileges, sudo, etc... Anyway, thanks for reading and thanks for your opinions. I love this section of wilders security, always an interesting read.
Actually, the whole point of a multiuser OS is to allow multiple users to work concurrently. That's all. Safety is modern age drama perks. Mrk
Mrkvonic is, in this case, correct. Multiuser exists purely so that multiple terminals could connect to one system, back when terminals were just terminals over a bus. Security is a nice benefit, just like how a virtual address space is not for security, but we get nice isolation from it. That said, setUID binaries have always had this issue .It's not new. That's why you don't allow anyone but root to write to one, etc, and get rid of them whenever you can. This is not exploitable. It's like saying "root can break DAC" - yes, root has that ability.
Re the origins of multiuser - okay, so security wasn't important then, but it is now. If a multiuser OS consistently allows unintended privilege escalation, that's a problem. Re "root can break DAC," there have been OSes which divided up admin privileges securely. e.g. VMS had 16 different sets of added privileges that an executable could be given via the INSTALL command, most of which would not allow further privilege escalation even if the executable could run arbitrary code. Edit: actually, @Hungry Man, have you ever used GrSecurity's RBAC? Because it can divide root into several different roles. Can it divide suid root privileges up the same way, or enforce Linux capabilities better?
Root is split into capabilities already, though it is quite a pain... still trying to get my program to drop caps with prctl(). And caps are kind of stupid since most any single one of them is incredibly powerful/ practically root. It is not so much that this isn't a *solvable* problem, in terms of having more restrictions. It just isn't within the scope of DAC. This is left to be solved by MAC. It's kind of like... you have DAC. But then you have an explicitly created thing that bypasses DAC. So it's now outside of the scope of DAC to protect you from it. So instead of trying to extend DAC for what is honestly something of an edge case these days, just use MAC. As for GRsecurity, it's MAC. I don't think it deals with caps.
Makes sense, but the problem is MAC is pretty much case-by-case. The path-based MAC frameworks are very limited, pretty much only good for containing individual applications. SELinux requires a lot of theoretical knowledge to use effectively, relies on filesystem extended attributes, and has had implementation vulnerabilities itself. Nobody ships GrSecurity or RSBAC/PaX precompiled kernels, though I'm not sure what the reasoning is. What I'm getting at is, on any given day, any given Linux server probably has a local privilege escalation vulnerability somewhere. And this is considered acceptable and expected. And there are now deceased (or nearly so) OSes on which it would have been considered utterly ridiculous. What the heck happened? Edit: also, server uptimes. Linux kernels are updated almost weekly, but the reality for servers is you can have a definitely-vulnerable kernel running for months on end due to uptime needs.
Well, what is the bypass here? You need root to create a setuid binary. If there were one on the system and it were writable, that sounds like a package or distro vulnerability, not an issue with DAC. But otherwise I do not see a vulnerability here. You can search Ubuntu, for example, and if you find a writable setUID binary I'll be surprised, and they'll likely want a report on that. I'm going to need to look at this specific bug, because I think the register may be confused. They're not sayign where the vulnerability is.
