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

[Brian Norris]

Hi Michael,

On Tue, Feb 16, 2016 at 03:18:38PM -0800, Michael Sweet wrote:
> > On Feb 16, 2016, at 3:02 PM, Brian Norris <computersforpeace at gmail.com> wrote:
> >> (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.
> 
> That is how we decided to differentiate between backends that should
> run as root vs. those that should run as lp. The advantage is that a)
> there isn't a separate configuration file that can break and b)
> backends that need to run as root probably cannot be used successfully
> as an ordinary user anyways.

Well, we have the couterexample for (b) already. And I'm examining
scenarios under which the executable should remain in a read-only state,
but I may want to reconfigure to run cupsd as (e.g.) root vs. non-root.
So those decisions would need to be done in *.conf, and not based on
file permissions.

But no matter, I can configure my own setup to my heart's content.

> (there *is* precedent for things like the ~/.ssh directory, which must
> not be world-readable,

That's for security of on-disk data (particularly, things like private
keys). That doesn't seem relevant here (the executable data is not
security-sensitive).

> and for other software that installs with restricted permissions to
> prevent execution by ordinary users...)

I'm unfamiliar with this kind of case. But that may just be my
inexperience. I don't understand what guarantee that would provide.
Allowing execution by normal users seems mostly equivalent
(security-wise) to allowing normal users to execute any user-provided
executable. What stops the user from creating a duplicate executable?
The code is open source, after all.

(Now, checking ownership and write-ability seems prudent.)

> >>> 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"?
> 
> Putting a configuration directive in cupsd.conf that allowed backends
> to run as root without being owned by root and with the restricted
> permissions.

I understand restricting ownership and write-permissions, but
read/execute permissions don't seem to have as many security
implications, if write-permissions are restricted.

> (we moved all of those kinds of things to cups-files.conf a year or
> two ago to address a security vulnerability that Google discovered)

I should have said cups-files.conf, not cupsd.conf.

Brian