[patch] CUPS 1.2 SELinux policy changes...

[Michael Sweet]

Russell Coker wrote:
> On Tuesday 15 November 2005 03:03, Michael Sweet <mike at easysw.com> wrote:
>>> b) the functionality for modifying those files could be placed in a
>>> separate helper program executed by cupsd, so that we could run that
>>> helper in a separate domain from cupsd and not give the daemon direct
>>> access to rewriting the files,
>> That would seriously impact performance and make the code a lot more
>> complicated.  Given that cupsd owns and writes these files, adding
>> helper apps would have little practical benefit for CUPS 1.2.
> 
> Is writing config files really a performance bottleneck?  I imagine that for 
> the majority of the run time of the daemon there are no changes being made to 
> the configuration.

Since printers.conf, classes.conf, and subscriptions.conf are updated
whenever the configuration or state of a printer, class, or subscription
is updated, it can account for a good amount of time on a busy server
with lots of printers/classes.  We've looked at only writing the files
on a server restart/shutdown, however you run into the possibility that
a server crash will lose all of the configuration changes you've made.
Also, when we add that plug-in interface to support alternate storage
mechanisms we'll also be providing information on the user that made
the change (and the nature of the change) to provide important
auditing information, so we'll need to save every change to preserve
that information anyways...

>>> Also, note that SELinux provides an API for application policy enforcers
>>> to support finer-grained controls over application abstractions, and
>>> this API is already being used by dbusd and nscd (and a patch exists for
>>> X, but isn't yet upstream).  Hence, it might make sense to look into
>>> using that API from cupsd as well (when running on a SELinux-enabled
>>> system, of course, which you can detect at runtime).  That allows you to
>>> then define SELinux policy over those operations in addition to your
>>> existing checks.
>> I'm not sure that really buys us anything - we already have a system
>> in place that can be used on all systems and provides remote access
>> policies above an beyond the UNIX accounts on the system.
> 
> You may (and often will) have multiple programs running with the same Unix UID 
> but different SE Linux security context.  To handle this situation correctly 
> it is often necessary to have SE Linux support in applications.  For example 
> if we have a printer in a public area and a printer in a secure area we want 
> to make sure that documents printed at a high MLS sensitivity level can only 
> go to the printer in the secure area.  Implementing this requires that the 
> CUPS server know about SE Linux access controls.  I believe that code is 
> already being written to implement such functionality.

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.

-- 
______________________________________________________________________
Michael Sweet, Easy Software Products           mike at easysw dot com
Internet Printing and Document Software          http://www.easysw.com