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

[Klaus Singvogel]

Michael Sweet wrote:
[...]
> The problem with RunAsUser is that every filter issue becomes a
> server issue that can bring the entire print server down.  Without
> RunAsUser it is simply an annoyance.

I understand your thinking, but still disagree.

Let me summarize your arguing, to see, if I don't misunderstand.

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.

I agree with the first part, but not with the later. If the scheduler
runs only at startup with root privileges, and drops them after the
necessary resource allocation, then the system seems in my point of
view to be less vulnerable. Running as root and (in case of
vulnerability) executing arbitrary code, means to be open for anyone.
Running as a special user (usually: lp) and executing arbitrary code,
means only gaining access to the devices and print jobs, but nothing
more in the system. This is annoying, but doesn't harm the rest of the
system. Keep in mind, that running as user lp means: lp has no
password, no login shell; root instead has both, and even more: the
bad guys know to hide processes and programs from the rest of the
system, as soon as they are root (usually done by rootkits).

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, 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. :-(

[...]
> 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.

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).

> 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.

[...]
> 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.

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.

Regards,
	Klaus.
-- 
Klaus Singvogel
SUSE LINUX Products GmbH
Maxfeldstr. 5                     E-Mail: Klaus.Singvogel at SuSE.de
90409 Nuernberg                   Phone: +49 (0) 911 740530
Germany                           GnuPG-Key-ID: 1024R/5068792D  1994-06-27