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

[Cory Olmo]

Hello Matt,

Comments in line.

On Wed, 03 Aug 2005 12:30:17 -0400
Matt Anderson <mra at hp.com> wrote:

> Hi Chad/Cory,
> 
> Nice work on an initial work up of trusted printing.  I have a few 
> comments and concerns.
> 
> You state early on that you are relying upon trusted networking.  Were 
> you thinking of the IPSec implementation?  Have you gotten word that 
> this code is upstreamable?  At this point I'm concerned that this patch 
> requires another patch that hasn't been accepted.

The patch is actually only dependent on getpeercon() supporting tcp
connections where the current mainline only supports unix domain sockets.
This was an unfortunate evil.  Since all jobs are communicated via network
connections and you can't trust the clients to properly encode the label
into their request there has to be a some method of retrieving the security
context for the connection.  How it is actually done can still be hashed
out but one way or another there will need to be some way of doing so.

> 
> Are there any other assumptions that you have made?  I see the patch 
> only has support for 8.5x11in paper.  Since this is an initial posting 
> thats no big deal, but we should just track it as something to fix up 
> down the road.  Another one is you seem to be backend agnostic at this 
> point.  Are you thinking of requiring only locally connected printers? 
> This is a concern since the way CUPS currently implements banner pages 
> they are a separate IPP print job, so injection attacks are possible.


With regards to the layout of the printers.  The optimal solution is either
have a single machine connected directly to the printer serving as the
print server for a network.  Under this configuration all the clients can
have cups installed but should not be running it as a local print daemon
that forwards the print jobs to the print server.  The other layout is only
locally connected printers.  

As you mentioned the banner pages are treated as seperate print jobs. 
There isn't really a problem of injection attacks and this can be
demonstrated if you have a locally running cups daemon which forwards to
another cups print server.  There is a fair amount of wasted paper but the
labels and banners will end up, as I believe, correctly.  

For example say you have a local cups daemon which forwards to another
print server, which I'll refer to as the network print server, over a Top
Secret connection.  Now you issue a print request to your local daemon
while at Secret.  The local print daemon will label the page and create
banners with the label Secret.  Then it will forward the print job to the
network print server.  When the network print server receives the print
request it did so over a Top Secret connection and thus it creates page
labels and banner pages with the label Top Secret.  The output of the print
job will be a front and back Top Secret banner page around each Secret
banner page and the actual print job.  The actual print job with its Secret
page label will be reduced and have the Top Secret page label placed at the
top and bottom.  

So you would end up with a page with both the Top Secret and Secret page
labels but the Secret labels would have been reduced and placed within the
printable region between the Top Secret page labels.  I may be off but I'm
pretty sure that fits with the requirements set out by the LSPP granted it
would be nice if the excess banner pages could be eliminated.  Since a
single page print job ends up generating something like nine pages of
output when run in this configuration.  But then again it's likely just
better to say that that configuration is not supported. 

> 
> I also noticed that you didn't do anything around capabilities.  Is that 
> something you thought about?  Same with audit.  Thankfully CUPS has 
> LogMessages all over the place, so audit should be fairly easy to add in 
> since we'll be able to borrow from the existing log code.
> 
> Cups currently is designed to ensure the print job happens.  As such it 
> seems that the error paths aren't as fatal as would be required for a 
> trusted implementation.  One area that highlights this is that print 
> jobs are first added to the queue, and then Cups tries to find a 
> username to associate with the job, if it can great, if not it just uses 
> anonymous.  Again, this isn't really something that is required for an 
> initial patch, but something that we need to ensure we don't drop.
> 
> You mentioned also that you removed tiff support because it brought too 
> many things in as a dependency.  While I can understand trying to keep 
> the amount of software required to a minimum, especially in a security 
> target, I'm concerned that this could cause us problems trying to get 
> this upstream.

Tiff support can be added back in without causing any problems or needing
any additional work.  We removed it solely for our convenience and should
of been taken out of the patch before posting it.

> 
> Lastly I noticed you were using the SELinux label as the label being 
> attached to the printout.  Something I had been considering was to add a 
> mapping table so that various SELinux types could be translated by Cups 
> into something more human readable on the output.  Additionally the 
> table could support blocking certain types from being printed at all, 
> although this isn't strictly a requirement of LSPP it seems like 
> something that will make the security enhancements more usable for the 
> customer.

Agreed, part of the LSPP requirements is a means of allowing an admin to
assign the printable labels.  The label translation library we are using
allows the admin to assign the output label that should be used.  So I
didn't spend much time worrying about how to implement another means of
doing it within cups.  The idea you had would work fine and shouldn't be
that difficult to add in.  If you did the translation immediately after
pulling the security context from the connection and then replaced the
appropriate portion of the security context stored in the connection
structure you would be good to go.  You could also potential make a
decision at that point to dump the connection altogether if it was a label
that should not be printed.  There is also the possibility that the
translation layer for libselinux might be able to handle configuring output
labels.  


> 
> Again, nice work on an initial patch.  As you can see I think we have a 
> ways to go, but I'm glad we finally have a place to come together to get 
> this done.

Thanks and agree that there is still work to be done.

> 
> -matt
> 

--------------------- 
Cory Olmo
Secure Systems Engineer

Trusted Computer Solutions
121 West Goose Alley
Urbana, IL 61801

www.TrustedCS.com

V: (217) 384-0028 ext. 13
F: (217) 384-0288