[redhat-lspp] dev_allocator, udev and import/export requirements

[Stephen Smalley]

On Thu, 2005-09-08 at 11:49 -0400, Janak Desai wrote:
> Stephen Smalley wrote:
> > Another option would be to amend the mls_compute_sid logic so that it
> > will fail if the process level falls outside of the original tty range.
> > At present, it doesn't take the original tty context into account at
> > all; it just sets the level in the returned context to the process
> > level, so that login et al relabel the tty to the same level as the user
> > session without considering the original level/range on the tty.
> >
> 
> Please bear with me as I am still learning the magic that is the
> security server. So, if I understand correctly, with this change the
> security_compute_relabel from pam_selinux, which is called with the
> target of the tty context, will fail if the process falls outside the
> target (tty) range, right?

Yes.  Under the assumption that you initially label all ttys with their
maximal ranges in file_contexts.

>  If so, that would work. I guess we
> would have to check all the uses of security_compute_relabel but
> that is preferable than complicated setup or the trying to catch it
> at the actual relabel attempt described below.

Unclear.  Running each getty with a particular range has the benefit of
implicitly bounding the allowed user sessions on that tty without
requiring any trust in login/pam.  Also, note that current code in
pam_selinux and openssh-selinux.patch tries to proceed even if the tty
relabel fails, so you would have to change that behavior.  It only
considers a failure to set the exec context as fatal.  

> mls_compute_sid can take care of login and friends, and CUPS currently
> upgrades print data to the process label so checking device access
> against process label should be sufficient. What about backup devices
> and star?  For example, if tape device is marked single level top
> secret, then should a process at top secret be able to write an
> unclassified or secret file to a tape? If no, then I am not sure how
> star can prevent such a thing since a top secret process has write
> access to a top secret tape drive and read access to unclassified
> files.

Why would you want to prevent it?  Doesn't violate simple or *
properties.

-- 
Stephen Smalley
National Security Agency