On Wed, 2004-10-27 at 16:14 -0400, Valdis.Kletnieks@private wrote:
> 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 };
That's generated from the full_user_role macro in user_macros.te, line
157. This does seem misguided to me. It would be worth taking this out
and seeing what all breaks.
However - note that most other domains such as daemon domains have their
own derived types for temporary files, e.g. httpd_tmp_t. However, that
doesn't tell us which domains can create files with tmp_t. Looking on
one of my machines, *no* file in /tmp is tmp_t.
I tried to use apol to see which domains can create tmp_t files but it
segfaults on my x86_64 box. Rebuilding it as i386 now to see.
> 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?
I don't think it's interesting personally, because your goals are
expressible in SELinux policy, and also because right now SELinux has
nothing to do with the Linux uid.
> 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"...
With SELinux the domain would also need privileges to read temporary
files created by the attacker.
This archive was generated by hypermail 2.1.3 : Wed Oct 27 2004 - 13:37:23 PDT