Bad file access on the rise

[Lennart Poettering]

On Fri, 07.06.13 14:02, Simo Sorce (simo at redhat.com) 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.