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

[Michael Sweet]

Klaus Singvogel wrote:
> ...
> If we use this knowledge and extrapolate this to the future (what an
> impertinent idea :), then it will be better to RunAsUser, and not
> having administrator priviledges (if there will be another issues in
> the scheduler).

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.

Also, the issue you are referring to was reported in 2002, thus the
CVE number.  Here is a list of the reports of cupsd or CUPS API
privilege escalation bugs:

     CVE-2002-1383 2002-12-19
     CVE-2002-1369 2002-12-19
     CVE-2002-1368 2002-12-19
     CVE-2002-1367 2002-12-19
     CVE-2002-1366 2002-12-19
     CVE-2002-0063 2002-06-25
     CVE-2001-1332 2001-03-??
     CVE-2001-0194 2001-05-07

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?

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.

>>> 	http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2004-0558
>> DoS attack - ALL network services are subject to this, and NONE are
>> immune...
> 
> I stronly disagree. You mix two different forms of DoS and compare
> them as being the same.
> 
> Whereas the first represents the fact that network services aren't
> immune to DoS, if they are attacked by _many_ requests/hosts, the
> later is vulnerable by only a _single_ packet.

which times out after 5 minutes and then the system is back...

Granted, some denial of service vulnerabilities are more serious
than others, but none of them are as critical as a privilege
escalation or complete trashing of your server.

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!

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