Re: [RFC] [PATCH] Replace security fields with hashtable

From: Valdis.Kletnieks@private
Date: Wed Oct 27 2004 - 13:14:17 PDT

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

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