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),
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,
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.
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.
--
Stephen Smalley
National Security Agency