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
|
