Re: [RESEND][RFC][PATCH 2/7] implementation of LSM hooks

[Nix <nix@esperi.org.uk>]

On Mon, 24 Apr 2006, Valdis Kletnieks stated:
>> This is not correct, as far as I understand. As the app can only rename
>> in it has access to both the old and the new path.
> 
> People seem to have a blind spot for this sort of thing.  Given *two* processes,
> one of which can be convinced to do a rename, and another that can be convinced
> to write a file, you can subvert everything (quite possibly in opposite order -
> if you can get process A to write /etc/foobar, and process B to rename foobar
> to passwd, you've won).

If those processes are exposed enough that external attackers can talk
to them at all, they should be confined. And anyone who allows confined
processes to write to /etc or create or rename links in /etc at all is
an idiot.

Are we *really* defending against people who write blatantly idiotic
profiles? (What's more, unlike with SELinux, it's guaranteed to be easy
to see that that profile is idiotic, because the policy language is so
simple.)

(Obviously creating or renaming links in /** is every bit as
bad. Don't-write-stupid-profiles rule again.)

(I'm assuming a post-chroot()-absolute-paths world: in the previous
world, as exemplified by the current example profiles, /** is sane *if
and only if* the confined app is always chrooted.)

-- 
`On a scale of 1-10, X's "brokenness rating" is 1.1, but that's only
 because bringing Windows into the picture rescaled "brokenness" by
 a factor of 10.' --- Peter da Silva
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/