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

From: Valdis.Kletnieks@private
Date: Wed Oct 27 2004 - 14:11:46 PDT


On Wed, 27 Oct 2004 16:39:48 EDT, Stephen Smalley said:

> So the obvious question is who can create tmp_t:lnk_file in the policy. 
> Answer:  only privileged domains (and only indirectly via file
> attributes that include that type, no direct rules).  Daemon and user
> domains all create their own $1_tmp_t types.  This particular rule is
> likely a legacy of post-install relabels where SELinux has no way of
> knowing what to assign to existing /tmp files.  But even that situation
> no longer applies tmp_t to files under /tmp, per the current
> file_contexts configuration.

Foo.. the test I did:

% cd /tmp
% ln -s /etc/motd foo
% chcon -h user_u:object_r:tmp_t foo
% l -Z foo
lrwxrwxrwx  valdis   valdis   user_u:object_r:tmp_t            foo -> /etc/motd

Unfortunately, the box was in permissive mode at the time, rather than enforcing.

I'm an idiot. :)

> > 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..
> 
> Seems like a straightforward tightening of the existing policy.
> 
> > 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.
> 
> As we provide a per-file link permission, this is straightforward,
> although it may require introducing additional types for suid/sgid
> programs that don't already have a separate domain (not a bad thing
> anyway).
> 
> > 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".
> 
> Seems feasible to limit writes to fifos owned by your domain or a
> trusted domain.  

Let me go ponder, I'll get back to this if/when I've cogitated more.. ;)

What's the consensus - if these tightenings are done, should they just be
done and see what breaks, or should they have an m4 ifdef around them and
an entry in tunables/tunable.tun?






This archive was generated by hypermail 2.1.3 : Wed Oct 27 2004 - 14:12:26 PDT