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

[Janak Desai]

Stephen Smalley wrote:

> 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.
> 

Good point. I guess I was hung up on the fact that a file with a
label outside the device label range was written to that device.
However, I do remember now, the explanation that Frank gave when I
had similar trouble with CUPS. The subject and object in this
example are top secret, so there is no violation of simple or
*properties. The object is the device and not the file. Got it.

Thanks.

-Janak