On Wed, 27 Oct 2004 14:35:09 EDT, Colin Walters said:
> The point here is that SELinux does allow you to express your end
> security goal. Most domains don't have the privileges to read lnk_file
> except for symlinks created by their own domain.
allow user_t tmp_t:{ file lnk_file } { read getattr lock ioctl };
Courtesy of macros/user_macros.te, it appears. Looks harder to smack
into submission than it appears, as staff_t has a similar rule.
Need to ponder the best way to attack this without ending up with an
unmaintainable mess of patches. Would there be interest in including
a "Openwall-style restrictions" tunable in the base SElinux if one was
created?
Things I'm currently addressing:
1) Don't follow a symlink out of a o+w directory (as pointed out, a special
case of "don't follow an untrusted symlink". Here, the focus is in not
tripping over a surprise left for you by others..
2) Reject hard links to any non-regular file, any suid/sgid file, or
any file you don't have write permission to yourself - here, we're trying
to prevent the surprise from being set up.
3) Reject writes to an "unsafe" FIFO (currently defined as "if it's in a
world-writable dir, it has to be owned by you or the dir owner"). Again,
the threat model is "you write to something other than you intended".
Yes, the *right* thing to do here is smash all the software that still
uses 'mktemp()' - but in the meantime.. ;)
> It's still discretionary, and thus subject to all of the problems of
> discretionary access control. You have no way of knowing whether the
> security goal is being enforced without verifying every directory on the
> system, ensuring it doesn't have ACLs, etc. Also any uid 0 process can
> quite easily subvert the controls.
Not "any uid 0 process" - "any process able to change ownerships/permissions/
contexts" :) Also, the threat model isn't "uid 0 subverts the control", it's
"Joe User tricks a uid 0 process into running a /tmp-race exploit"...
This archive was generated by hypermail 2.1.3 : Wed Oct 27 2004 - 13:16:21 PDT