Root

Troels Arvin troels at arvin.dk
Thu Jul 29 14:38:20 PDT 2004


On Thu, 29 Jul 2004 10:01:36 -0400, Michael Sweet wrote:

>> I want to run cupsd as a non-root user to minimize the impact if a 
>> security hole is found in Cups.
> 
> First, RTFM.

Oops, sorry. I must have missed that when I read the administrator manual
some years ago.

>      1. All filters and backends have write access to the
>         configuration files in /etc/cups, spool files in
>         /var/spool/cups, and log files in /var/log/cups,

I don't quite get this. Is your point, that even if cups is run as a
non-root user, then the filters/backends might still be broken if a
potential hole is exploited?

>      2. The LPD backend is unable to reserve a priviledged port,
>         which disables printing to some LPD printers and print
>         servers,
>      3. You have to provide write access for the "lp" user and/or
>         "sys" group to all parallel, USB, serial, and SCSI devices
>         that you use.  This may open additional security holes.

I could live with that.

>      4. The scheduler (cupsd) cannot be restarted without killing
>         the process and starting it again if you listen on a
>         priviledged port like the default port 631; this means that
>         SIGHUP and remote updates of cupsd.conf will not work,
>         resulting in more down time when you make configuration
>         changes.

OK. I sometimes use a dirty trick for situations like this: Bind the
daemon to an unprivilidged port outside the dynamically allocated port
areas (could be port 2000 as an example) and then use iptables to forward
trafic from the well known (priviliged) port.

> In the future, we hope to leverage the selinux stuff to provide
> the best of both worlds: don't run as root, but still be able
> to change to other users (perhaps "lpfilter" and "lpbackend")
> and reserve priviledged ports so that you don't lose the
> functionality and don't open yourself up to additional exploits
> when using "RunAsUser" or its successor.

Sounds interesting. Until then: Have you looked into the "capability"
system?
http://www.linuxsecurity.com/resource_files/server_security/linux-privs/linux-privs-2.html

(I believe that BIND uses those, for example.)

-- 
Greetings from Troels Arvin, Copenhagen, Denmark





More information about the cups mailing list