[cups.bugs] Re: [LOW] STR #1349: RunAsUser support: regressions from 1.1.x, aux groups fix

Martin Pitt martin.pitt at canonical.com
Thu Dec 1 04:52:30 PST 2005


Hi Michael!

Michael Sweet [2005-11-29  9:27 -0500]:
> First, RunAsUser is going away in CUPS 1.2.  We may add new command-line
> option(s) to cupsd to support a similar mode, but the RunAsUser directive
> is being removed for the final 1.2 release. The reasons are numerous, but
> basically the RunAsUser mode exposes more security problems than it
> corrects.

Please do not remove it without a substitute. Running cupsys as root
would be unacceptable for us. Running cupsd as an unprivileged user
with just a few additional privileges (lp and dialout groups, not
more) confines the potential impact of vulnerabilities in cups to a
very small subset of root privileges, so we would like to keep it that
way.

> OK, to address each of your patches:
> 
> 1. This appears to be a problem with the Debian copy of the CUPS
> repository. The official CUPS repo (which is the only source you should be
> using when generating patches, BTW) already uses CUPS_DEFAULT_GROUP.

Ah, sorry for that. The Debian package I based the Ubuntu one on
changes nobody to root, so my patch changes root to
CUPS_DEFAULT_GROUP. However, the official code reads:

------- snip -------
 /*
  * Find the default group (nobody)...
  */

  group = getgrnam("nobody");
  endgrent();

  if (group != NULL)
    Group = group->gr_gid;
------- snip -------

which fails, because 'nobody' is not a group, and it makes no sense to
run cupsys in group 'nogroup' either (this would make 'nogroup' a
privileged group, which is wrong; the Unix permission concept simply
does not have a concept of 'no group', in such cases 'root' should be
used).

Maybe you accidentially looked at the getgrnam() call in the 'Find the
default system group' section? This is already correct.

> 2. The root certificate cannot be generated when we are not running as
> root. The reason is simple: the web interface CGI programs run as the
> unprivileged user and can always read the root certificate, so they will
> never ask for a password.

I do not understand that. The certificate has to be readable by the
system groups anyway (i. e. for users who are in the "printer
administration" group), so it cannot just be readable for root. I did
not find any way to generate other certificates for other system
groups. Maybe there is, but it is not documented very well.

> Basically, this means that in 1.1.x if you used RunAsUser then you
> could do anything from the web interface as if you had administrator
> privileges.

That does not work for our configuration. The web interface asks for
an user/password (of somebody who is in the printer admin group) and
refuses to do anything administrative if login fails.

> 3. initgroups() is not portable. 

Ah, too bad. It is very handy for more finegrained privilege
management than just the crude root/user concept.

> In addition, your patch will crash cupsd if the User does not exist. 

Ok, this could be improved. This was never reported for Ubuntu/Debian
since the package automatically deals with creating/removing the
necessary users and groups.

> Finally, CUPS has never opened up access to multiple groups, only to
> the one listed in cupsd.conf, so changing the default behavior now
> will add potential security issues that we do not want to expose by
> default.

That's reasonable.
	
> It is possible that we could add a configuration directive that
> tells cupsd to use initgroups() or setgroups() with the appropriate
> lookup code, however that will likely not be added in CUPS 1.2.

That would be nice. Maintaining this tiny patch is no effort, I just
wanted to make sure that you are aware of the problem.

Thanks and have a nice day!

Martin
-- 
Martin Pitt        http://www.piware.de
Ubuntu Developer   http://www.ubuntu.com
Debian Developer   http://www.debian.org

In a world without walls and fences, who needs Windows and Gates?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <https://lists.cups.org/pipermail/cups/attachments/20051201/e318741a/attachment.bin>


More information about the cups mailing list