On Wed, 2004-10-27 at 16:14, 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 };
>
> Courtesy of macros/user_macros.te, it appears. Looks harder to smack
> into submission than it appears, as staff_t has a similar rule.
Full context of that statement is:
# Read the /tmp directory and any /tmp files with the base type.
# Temporary files created at runtime will typically use derived types.
allow $1_t tmp_t:dir r_dir_perms;
allow $1_t tmp_t:{ file lnk_file } r_file_perms;
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.
Now one can legitimately argue about whether or not that rule belongs in
the policy (I'm all for removing it), but it hardly suggests that the
policy is incapable of enforcing your goal.
> 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.
--
Stephen Smalley <sds@private>
National Security Agency
This archive was generated by hypermail 2.1.3 : Wed Oct 27 2004 - 13:43:52 PDT