[cups] Running CUPS backends (e.g., IPP) as non-root

[Brian Norris]

Hi Michael,

I disabled mailing list delivery, so it'd be nice if I can be kept on
CC.

On Feb 12, 2016, Michael Sweet <msweet at apple.com> wrote:
> > On Feb 11, 2016, at 2:37 PM, Brian Norris <computersforpeace at gmail.com> wrote:
> > 
> > I'm looking at running cupsd as a non-root, sandboxed process on Linux,
> > and I'm stumbling across the problem of the IPP backend
> > (/usr/libexec/cups/backend/ipp) being restricted to only run as root
> > (permissions are 700). I see that some piece of my question has been
> > addressed previously:
> > 
> > https://www.cups.org/pipermail/cups-devel/2012-April/013673.html
> > 
> > But is that still the status quo? It seems like the question of
> > privileges is somewhat orthogonal to the question of "am I running as
> > root." With (e.g.) modern Linux capabilities, it's possible to not be
> > root, yet still be granted sufficient permissions to get privileged
> > ports.
> 
> In the case of the IPP backend, it is not about privileged ports but
> of having access to user credentials as root.

So, if I don't need Kerberos, IPP doesn't actually need to run as root?

> Recent versions of CUPS (since 2.0) support the backend with group
> read/execute

So chmod 750 /usr/libexec/cups/backend/ipp is "supported"? From the
code, it looks like it gracefully degrades when run as a non-root user.

> (just not world read/execute).

Why would world read/execute be relevant? Or, why does the fact that
other users can read/execute the binary have anything to do with what
the program behavior should be? I've never actually seen a program care
what other users can do with its executables.

> > I realize I could hack around this myself in various ways (e.g, 'chmod
> > 755 /usr/libexec/cups/backend/foo'), but I wanted to see if you were
> > considering alternatives to this permissions-based check. For instance,
> > instead of saying "Backends are run either as a non-privileged user or
> > as root if the file permissions do not allow user or group execution"
> > [1], we could instead make this configurable (e.g., in cupsd.conf).
> 
> That itself would open up a security hole;

What is "that"? Doing 'chmod 755 /usr/libexec/cups/backend/foo'? If so,
why is that a hole? Allowing an unrelated user to read and execute some
bits on the system shouldn't compromise the CUPS daemon.

> conceptually it could be in the cups-files.conf file, but that still
> requires local configuration changes.

Right, either way one needs to configure things locally. But it just
seems wrong to tie the behavior of the CUPS server to the permission
bits set on a helper executable.

Brian