[redhat-lspp] Re: Initial MLS Label Printing Support

[Matt Anderson]

Cory Olmo wrote:
> On Mon, 15 Aug 2005 16:30:52 -0400
> Janak Desai <janak at us.ibm.com> wrote:
> 
> 
>>Linda Knippers wrote:
>>
>>
>>>>>>The security attributes are extracted from the client socket attributes.
>>>>>>Does that mean that a "Top Secret" process printing an Unclassified file
>>>>>>will result in printed output that is labeled "Top Secret"? or are the
>>>>>>attributes of the socket manipulated to match that of the file being
>>>>>>printed?
>>>>>>
>>>>
>>>>
>>>>This is correct currently. The socket attributes aren't manipulated to the
>>>>level of the input. This is the simplest approach. Using the label of the
>>>>file(s) can be complicated when for example you have one job which prints
>>>>two files that are different labels.
>>>
>>>
>>>If you use the attributes of the socket does it meet the "least upper
>>>bound" requirement?  Sounds like its ok to have the label of the
>>>most sensitive file in a multi-file print request.
>>>
>>
>>Yes, that's correct. However, as Chad said, it could be messy to obtain
>>labels of different files and then using the most dominant label. If
>>it is easier to use the process sensitivity label, we should use it since
>>it is the ultimate LUB.
>>
>>-Janak
>>
> 
> 
> Another reason for pulling the security attributes from the socket rather
> than directly from the file is the elimination of reliance and potential
> subversion via clients.  So long as communication with the printer can only
> be performed by the cups server it is possible to insure that all pages get
> properly labeled based on the label of the connection transmitting the job.
> The clients can be anything with the ability to perform ipp communications. 
> 
> Cory

If we go with the idea that lpr is a trusted application then we can
have it stat all the files on the command line and adjust its socket
label accordingly.  lpr would need to be allowed to set its socket's
security attribute, but that doesn't seem that bad.  As for client's
subverting it, the attacker would still need to override their socket's
security attribute, which the security policy shouldn't allow for.

-matt