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

Michael Sweet mike at easysw.com
Thu Dec 1 07:41:09 PST 2005


Martin Pitt wrote:
> 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.

You may have to stick with 1.1.23 for a while then.  RunAsUser is
fundamentally broken in many ways - the main issue is that you
have the scheduler and filters running as the same user, so while
you eliminate root escalation issues you open up a whole class of
potential corrupt-the-cupsd.conf file situations which lead to root
escalations...  Also, the RunAsUser mode leaves cupsd in a
"crippled" mode (no run-time configuration, no system password
authentication, etc.)

The current SELinux policies included for CUPS provide much better
protection, and we are working with the developers to fix the
remaining CUPS 1.2 issues - domain sockets and some of the new
file locations...

Finally, if we do a command-line option (or just use seteuid()
to run as the user when we are not doing something that requires
root access) you'll effectively get the same level of protection
offered by RunAsUser...

In short, RunAsUser as a configuration directive has to go away.
SELinux and/or a command-line option may be viable replacements,
we'll see.

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

Um, no, the official CUPS 1.1.23 code uses CUPS_DEFAULT_GROUP, see:

     http://svn.easysw.com/public/cups/tags/release-1.1.23/scheduler/conf.c

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

Nope, a "grep nobody *.c" in the 1.1.23 scheduler directory does not
turn up any matches.  There *is* a reference to the nobody group in
the 1.2 code, because in 1.2 Group and SystemGroup must not be the
same!

The 1.1.x behavior of using the same Group and SystemGroup is a
(harmless) bug because we always created an authentication
certificate for CGI programs.  In 1.2, we only do so if we have
authentication data for the request, so it would be possible for
the CGI program to open the root (0) certificate and pose as the
root user without being challenged.  In addition, cupsd checks
if Group and SystemGroup are the same, and reassigns Group to
"nobody" if they are.

In short, security in 1.2 is much, much tighter.

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

There is no way to do this.  The design is simple:

      - The root certificate is certificate #0.
      - All other certificates are generated by cupsd when it
        runs a process; the certificate number is the process
        ID...
      - The certificates only contain a unique one-time key
        string of 128 random bits; the association between the
        key and user is stored in memory only and is thrown
        away whenever the key expires (process goes away or the
        RootCertDuration expires) or cupsd is stopped or restarted.

Currently the root certificate is only readable by the first
listed SystemGroup.  There is an open RFE to add POSIX ACLs to
the file as needed so that all SystemGroup's are able to access
the file as needed.

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

Again, things have changed between 1.1.x and 1.2.  See my explanation
above.

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




More information about the cups-devel mailing list