Stephen Smalley wrote:
On Sat, 2005-11-12 at 09:44 -0500, Michael Sweet wrote:
I know some people would prefer to hand-edit all files and place printer
state data in 5 different places, however no one has proposed an
alternate location for these files that makes sense WRT to the FHS.
We are absolutely committed to making CUPS easy-to-use, which means
allowing programs (in particular cupsd, which can provide finer-grained
authorization/access control to the configuration data than selinux) to
edit those files. CUPS also updates the printers.conf, classes.conf,
and subscriptions.conf files based on (persistent) state changes.
I'm not overly familiar with the specifics of CUPS or its policy myself,
but it would likely help if:
a) the files that need to be writable by cups would be located in a
separate subdirectory from files that should remain read-only (this
allows us to place a distinct type on that subdirectory and have it
inherited by all files re-created in that subdirectory by default, so
that only that type needs to be writable by cups),
Technically, all of the files in /etc/cups are configuration files
that can be written by cupsd, even the (usually read-only) MIME
files (*.types and *.convs). CUPS provides an interface for
reading and writing configuration files via HTTP, and that interface
allows for such things as remote configuration and mirroring of all
CUPS configuration data...
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.
We do have plans for supporting alternate storage mechanisms in future
(think CUPS 1.4 or later) so that users can put their configuration
data in a database, version-controlled repository, etc., however we'll
still default to the local, writable files *without* a helper app.
c) the helper program in turn supports applying (optional)
filters/checkers to the data so that it can be validated, to prevent it
from being used arbitrarily by a compromised cupsd.
cupsd already validates its input from configuration files...
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.
Right now I'm more concerned with making the CUPS selinux rules
work with CUPS 1.2, and to clear up any issues so that selinux
does its job and doesn't get in the way of CUPS's job... :)
--
______________________________________________________________________
Michael Sweet, Easy Software Products mike at easysw dot com
Internet Printing and Document Software http://www.easysw.com
| 
