Re: [patch] CUPS 1.2 SELinux policy changes...

Michael Sweet wrote:
> Our government customers do not support both secure and non-secure
> resources from a single server - it violates the policies they have in
> place.  Assuming that, at some point, they trust selinux enough to
> change those policies and run classified and unclassified processing
> on the same system image, you will need to make extensive changes at
> both the client and server levels in order to securely pass and
> authenticate the document classification data.
> 
> In short, CUPS is a network service and supporting such a
> configuration would require a lot more work than adding some simple
> API hooks which, AFAIK, lack the network scope that is required.

I've been meaning to talk to you about that...  I've been working on
addressing some of that work.  Currently there are three patches against
1.1.23.  The initial one was by Cory Olmo from TCS.  It provided forced
labels based on the SELinux context of the session that submitted the
print job.  I then added some audit hooks to pass information into
Redhat's audit framework.  Finally realizing that we wanted to remove
CUPS' dependency on labeled network I did a quick proof of concept patch
which had CUPS use local unix sockets instead of internet sockets.

The initial unix socket patch was compile time and essentially gutted
the sockaddr_in replacing them with sockaddr_un.  This is less than
ideal so I was working on a new patch which would combine all three
previous compile times patches into one patch that would make its
decisions at runtime.  Using sockaddr_storage and some minimally
invasive logic I was able to get around the need to replicate the
listener_t and http_t data structures.  I did end up adding a config
option of "socket" to my development stream since I wanted to make it
distinct from "listen" or "port".  I had been planning on allowing for
"Classification" to be set to selinux in order to specify to use the
SELinux label as the forced banner.

I've since gotten sidetracked off that work so the runtime patch isn't
finished yet.  I hope to be able to get back to it in a few weeks.  In
the meantime I can send you the patches so you can see first hand the
extent of the damage, and to provide feedback of course ;)

-matt