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

[Janak Desai]

Stephen Smalley wrote:

> On Thu, 2005-09-08 at 10:21 -0400, Janak Desai wrote
> 
>>Yes, true. What I meant to say was, how will login handle
>>single level terminals or multilevel terminals with a range
>>of secret to top secret? How will a user cleared to top secret
>>be prevented from loggin in at unclassified on a terminal
>>marked "secret to top secret"? Does get_ordered_context_list
>>take login terminal into account? Similar situations apply
>>to printing on multilevel print device or backing up to
>>multilevel tape device, right? Maybe I am still stuck on
>>my SecureWare B1 way of thinking.
> 
> 
> get_ordered_context_list/get_default_context doesn't take the terminal
> into account per se, although it does take the context of the calling
> process into account (the fromcon, which defaults to the result of a
> getcon(3) if left NULL).  Hence, you could run different login processes
> with different ranges, although setup might be a pain.
> 
> 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? 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.


> Or you could try to catch it upon the actual relabel (setfilecon)
> operation by login et al, by defining a mlsvalidatetrans constraint that
> prohibits the tty from being relabeled outside of its original range.
> Although I'm not sure how you would then deal with the need to restore
> it upon session close.
> 

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.

-Janak