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

[Janak Desai]

Steve Grubb wrote:

> On Wednesday 07 September 2005 17:34, Janak Desai wrote:
> 
>>I have been looking at udev and TCS dev_allocator and I have some
>>questions.
> 
> 
> Me too. What is the real need for this utility? Does it play nicely with 
> lockdev? How does it differ from just doing a chcon on the device?
> 
> 
>>Are there patches to CUPS, login, star, etc that enforce the sensitivity
>>label ranges stored in the dev_allocator.conf file?
> 
> 
> This should be the responsibility of the OS to compare labels
> 

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.


> 
>>LSPP requires that the TOE contain a mechanism by which an
>>admin can assign security attributes to devices (single level
>>or a range in case of multi-level).
> 
> 
> chcon does this for example. The audit system should be configured to hook 
> setxattr for the devices of the machine to generate audit records. No 
> userspace utility should have to do that.
> 
> 
>>These attributes are then used in the enforcement of MAC policy when
>>users/programs use these devices. I am trying to get a handle on what we
>>have to patch in order to satisfy LSPP import/export requirements with
>>respect to terminals, printers and removable devices.
> 
> 
> I'm wondering if we have to patch anything. How does this utility differ from 
> chcon + audit setup to get setxattr events? Allowing write to unlabeled or 
> read from unlabeled device could be enforced by policy. this way it has to be 
> chcon'd in order to be accessible. A boolean could override that. Changing 
> the boolean should be an auditable event.
> 

Yes, chcon + audit will take care of the requirement of manual state change. I
wasn't sure of device labels would be enforced for single and multilevel
devices.

> -Steve
> 
> --
> redhat-lspp mailing list
> redhat-lspp at redhat.com
> https://www.redhat.com/mailman/listinfo/redhat-lspp
> 
>