On Fri, 07.06.13 14:02, Simo Sorce (simo@xxxxxxxxxx) wrote: > > Well, you know, this problem isn't new. Some SELinux AVCs can be set to > > ignored for precisely reasons like this one, because it is common that > > things like these happen: accesses which fail where that is > > expected. You can call me a troll as much as you want, but then please > > call the Selinux folks trolls first. > > The SELinux folks, being the practical bunch they are simply work around > bad programs. That doesn't mean they are trolls. > Also the SeLinux folks have 'context', which is something an audit > system may not have. > Finally the fact SELinux folks are considerate does not mean that > programs need not be fixed to behave better. > > Of course the author can always decide to show the finger and do what he > wants anyway, we live in a free and unpolite world after all. Well, you know this is not about me showing anybody the finger. It's just that I fundamentally believe that the programming practices the audit folks propose are systematically wrong, and lead to worse code. You should not second guess the kernel, and try to bypass the kernel's access checks by doing them in userspace. You cannot win that game, because you simply don't have the same information the kernel has. The kernel is both more restrictive and less restrictive than simple UID checks they way they have been proposed on this thread, so you have the best chance to be wrong with manual userspace UID checks. More restrictive are SELinux checks, less restrictive are additional ACLs that might be on a file. And to mix things up entirely with capabilities everything becomes extra confusing. Then, doing these things in userspace makes these checks non-atomic. If the kernel does these checks, then the access checks and the open() will be atomic. Of course, one can deal with these atomicity problems... or one can just do it properly and leave all this to the kernel... So yeah, by doing these checks in userspace they way you suggest: a) adds more code to userspace b) second guesses the kernel, a game which you cannot win c) creates atomicity problems So, yeah, just trying to open the shm files *is the right thing to do*. And if audit doesn't like that, then audit needs to be fixed, not PA. > > User "simo" creates /dev/shm/1000/ even though 1000 is the UID of user > > "lennart". Lennart can never start PA again, ever. And can't do anything > > about it, because "simo" is in control, and /dev/shm is sticky. > > That could be solved by precreating the directory at login time, like we > do for many other things. There isn't just one way. > Or you could even stop using /dev/shm and we'd have one less problem > entirely :) Login time doesn't suffice. Isn't that trivial to see? "Simo" logs in first, his directory is created. Then he creates also /dev/shm/1000, which is still lennart's UID. Now Lennart logs in, and bam, now it's even worse, he cannot even log in anymore since his directory already exists. So, the only option you have is to create these dirs during boot-up before the first user can log in. But in a world of LDAP that's not really too useful, is it? > The point is that we are simply throwing ideas off the wall as an aid in > finding a way to solve the issue for all. Quite honestly, these problems are well known. World-writable directories with a shared namespace are inherently broken, you can only create randomized files/dirs in them, everything else is necessarily broken. > > It's really disappointing if people as seasoned as you still don't > > understand these shared-namespace issues of world-writable directories. > > Yeah, just like it is disappointing to see that your first reaction is > always to show the finger hard and solid instead of trying to have a > reasonable discussion about the problem. The problem of shared namespace world-writable dirs is hardly new, is it? Anyway, this is not constructive. Let's stop this here. Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
