[cups.development] [RFE] STR #2370: Provide a configure option for running the server as non-root

martin.pitt.canonical martin.pitt at canonical.com
Mon Apr 30 03:04:39 PDT 2007


DO NOT REPLY TO THIS MESSAGE.  INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.

[STR New]

cupsd does a lot of text processing, parsing, conversion etc. and is often
exposed to the network. By default it provides a promising remote-root
attack vector.

It is easily possible to run the backend with reduced privileges, as the
1.1 series allowed with the 'RunAsUser' configuration option. I agree that
it is not appropriate to provide this as a runtime configuration switch;
instead this should be the default mode at least in distributions where
this is possible (this should be true for all distros which provide a
complete OS, as opposed to e. g. Linux From Scratch).

The attached patch provides a configure option --enable-privilege-dropping
which irrevocably drops cupsd's privileges to CUPS_DEFAULT_USER. It has
been in production use and stable Ubuntu releases for over a year now. It
requires that the cupsd user is in the groups appropriate for /dev/lp*
access (i. e. lp, dialout, and scanner in Debian) and has the privilege of
reading /etc/shadow (group 'shadow' in Debian). The latter can be further
reduced (we did that in Ubuntu), but this requires a little more effort. I
am happy to discuss that with you after resolving the basic issue here.

Most changes related to this are #ifdef'ed, so it does not change default
behaviour. The sole exception is this bit:

--- cups-1.2-ubuntu~/scheduler/cert.c 
+++ cups-1.2-ubuntu/scheduler/cert.c
@@ -116,7 +116,7 @@
     * Root certificate...
     */

-    fchmod(fd, 0440);
+    fchmod(fd, 0240);
     fchown(fd, RunUser, SystemGroupIDs[0]);

     cupsdLogMessage(CUPSD_LOG_DEBUG2, "cupsdAddCert: NumSystemGroups=%d",

This changes the permissions of /var/run/cupsd/certs/0 so that cupsd
itself cannot read it any more. Otherwise you will get the funny effect
that the web interface presents cupsd's own certificate to itself and thus
it will never ask for admin authentication. If there is an existing
special case which prevents this behaviour when running as root, then this
can be #if'ed as well, but I wanted to point out the problem in detail.

Thank you!

Martin

Link: http://www.cups.org/str.php?L2370
Version:  -feature
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 09_runasuser.dpatch
Type: application/octet-stream
Size: 5193 bytes
Desc: not available
URL: <https://lists.cups.org/pipermail/cups/attachments/20070430/0ffdb402/attachment.obj>


More information about the cups mailing list