[cups.general] Q. Proper way to startup cupsd asanon-rootuserasopposed to debian hacks?

[wtautz]

Michael Sweet wrote:

> Klaus Singvogel wrote:
>
>> ...
>> The filter is always RunAsUser, the server instead runs with full
>> administration privileges. If a filter has security issues, then it is
>> annoying, but uncritical, instead, if the scheduler is hit, it is
>> always a critical problem, regardless if running as root or as user.
>
>
> Correct.
>
>> ...
>> I still have problems in understanding, why running all the time with
>> root privileges is more secure, as only for a short moment; and still
>> say, that RunAsUser is more secure, than continues running with admin
>> privileges. We only lose the print system, in case of a vulnerability,
>> but not the whole system.
>
>
> Keep in mind that we view CUPS as "the whole system" when evaluating
> security issues - many of our customers use CUPS in production printing
> environments, and the loss of the spooler is equivalent to the loss of
> the server.
>
>> Keep in mind, what I already told years a few years ago: the scheduler
>> still parses any byte-stream, before he decides whether to accept a
>> connection or not. No restriction or blocking can be done before the
>> byte-stream is evaluated, and this evaluation is done while we run
>> with root privileges now. :-(
>
>
> Unfortunately, there is no way to change privilege levels that provides
> any added security - seteuid(lp) won't prevent a successful attacker
> from regaining root privileges, and we *do* need root privileges
> during the life of cupsd in order to do many things.
>
>> [...]
>>
>>> So, from 2001 through 2002, there were 8 privilege escalation bugs
>>> found out of 43 total CUPS-related CVEs.  If we break them down
>>> by type:
>>>
>>>     Number  Type                   Last Issue Reported
>>>     ------  ---------------------  -------------------
>>>         12  Xpdf issues            2005
>>>          9  Denial of Service      2005
>>>          8  Escalation             2002
>>>          4  MacOS X-specific       2005
>>>          4  Other filter issues    2004
>>>          3  lppasswd               2004
>>>          1  Temp files             2001
>>>          1  Disclosure             2004
>>>          1  Foomatic               2004
>>>
>>> you'll see that Xpdf has the most and all filter issues combined
>>> (12 + 4 + 1 = 17) are a little more than twice the number of
>>> cupsd escalation issues.  Do you really want to argue that tripling
>>> (17 + 8 = 25, or 3.125 times 8) the potential number of privilege
>>> escalation bugs is a good thing?
>>
>>
>> Sorry, but having only one hole is enough to have an open system, the
>> ratio is irrelevant, and there were security problems in the past.
>
>
> If you use RunAsUser, this may be true, otherwise only holes in
> cupsd or the CUPS API bits that cupsd uses can create an open system.
>
>> BTW: You didn't mention that there was no official code release of
>> CUPS during 2005. And new code usually means new bugs (even this is an
>> old joke, there is still a grain of truth in it).
>
>
> Um, CUPS 1.1.23 was released in Jan 2005.  There we no more 1.1.x
> releases because there were no more security issues in 1.1.23 (all
> of the Xpdf issues affected 3.0...)
>
>>> Remember, root != the only privilege escalation path - CUPS manages
>>> all printing, so if you run as an unprivileged user, everything it
>>> manages can be destroyed by someone that doesn't have root access.
>>
>>
>> I disagree. If the scheduler runs a system account, like lp, then only
>> lp can destroy what it manages, no other user is able to destroy lp
>> related stuff (except root). Such system accounts (lp) have usually no
>> shell, no password, etc. They are very restricted. Root instead has
>> a shell, can be used for logins, etc.
>
>
> Printing is everything for our customers, so the server == printing.
>
In short only put cups server on a single host that you can afford to be
compromised :-)