[patch] CUPS 1.2 SELinux policy changes...

Russell Coker russell at coker.com.au
Mon Nov 14 16:14:54 UTC 2005


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.

> > 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.

-- 
http://www.coker.com.au/selinux/   My NSA Security Enhanced Linux packages
http://www.coker.com.au/bonnie++/  Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/    Postal SMTP/POP benchmark
http://www.coker.com.au/~russell/  My home page




More information about the fedora-selinux-list mailing list