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

[Michael Sweet]

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.

> [...]
>> At least we have some control over cupsd and can audit all of the
>> code that runs as root.  The same can't be said about third-party
>> filters!
> 
> It has been shown, that even an audit doesn't find every issue. But I
> agree, it strengthens the code. CUPS already got a security audit by
> SUSE, but it was before 2002.

SuSE isn't the only one doing audits, and auditing is not a one-
time thing.  Even *we* have started doing periodic audits of our
code (since 2002!) and the result is that we haven't had a new
escalation problem since 2002.

> I still say, complete jailing the whole printing system (the scheduler
> as well as the filters), is IMO more secure than partly running with
> full blown administration privileges and only partly jailed.

*If* cupsd could be jailed but still provide a separate jail for
child processes, this would be true.  Otherwise you just open up
CUPS do a much broader range of attacks than would otherwise be
possible.

-- 
______________________________________________________________________
Michael Sweet, Easy Software Products           mike at easysw dot com
Internet Printing and Publishing Software        http://www.easysw.com