Q. Proper way to startup cupsd as a non-root user asopposed to debian hacks?

[Michael Sweet]

Michael, Does cups allow running as a non-root user? Obviously
I know I could just start it up as a non-root user but that clearly
implies it would have limited capabilities from the start.
Most daemons that run as a non-root user usually start up
as root and then exec a child with lesser priviledges *after*
they checked things like permissions and the like.

Actually, it is a crap shoot whether the daemon will do this
for you, however for CUPS we MUST run as root in order to do
many common things. As I covered in my presentation at the
Linux Printing Summit this year, running as an unprivileged
user is actually *less* secure with CUPS, as you lose the
privilege separation between scheduler and filters which have
a lot less auditing done on them...

The debian boys have hardwired the userid cupsys into
the code. It would be nice if there were a way to do this
in a cleaner way using your original source. Perhaps a compile
time define or perhaps the USER variable could be used to
identify the userid that cupsd should run as? I know
you've deprecated RunAsUser but....

We aren't going to bring back RunAsUser. All of the Linux distros
already provide helper functions for their init scripts to run as
a different user, I suggest you look there if you really want to
cripple your CUPS install. You will also need to update the
/etc/services file on every system that wants to print with the
new port number for the IPP service...

FWIW, the following will not work if you don't run as root:

1. Printing and browsing on port 631 (or any port < 1024)
2. Automatic root authentication via certificates.
3. Proxy authentication support (you'll need to hardcode
usernames and passwords in your device URIs again).
4. Local account authentication via PAM (although I've
heard there is now a workaround for this by adding the
user you run cupsd as to a PAM group)
5. LPD printing support.
6. Legacy client support via /etc/printcap and
/etc/printers.conf. This kills printing from GNOME apps
on Solaris 10, for example.
7. (future) Kerberos support.

You are also leaving yourself open to filter-based attacks because
of the loss of privilege separation.

[wtautz]

Post by Michael Sweet

Michael, Does cups allow running as a non-root user? Obviously
I know I could just start it up as a non-root user but that clearly
implies it would have limited capabilities from the start.
Most daemons that run as a non-root user usually start up
as root and then exec a child with lesser priviledges *after*
they checked things like permissions and the like.

Actually, it is a crap shoot whether the daemon will do this
for you, however for CUPS we MUST run as root in order to do
many common things. As I covered in my presentation at the
Linux Printing Summit this year, running as an unprivileged
user is actually *less* secure with CUPS, as you lose the
privilege separation between scheduler and filters which have
a lot less auditing done on them...

The debian boys have hardwired the userid cupsys into
the code. It would be nice if there were a way to do this
in a cleaner way using your original source. Perhaps a compile
time define or perhaps the USER variable could be used to
identify the userid that cupsd should run as? I know
you've deprecated RunAsUser but....

We aren't going to bring back RunAsUser. All of the Linux distros
already provide helper functions for their init scripts to run as
a different user, I suggest you look there if you really want to
cripple your CUPS install.

Ok. Didn't know that.

Post by Michael Sweet
You will also need to update the
/etc/services file on every system that wants to print with the
new port number for the IPP service...
1. Printing and browsing on port 631 (or any port < 1024)
2. Automatic root authentication via certificates.
3. Proxy authentication support (you'll need to hardcode
usernames and passwords in your device URIs again).
4. Local account authentication via PAM (although I've
heard there is now a workaround for this by adding the
user you run cupsd as to a PAM group)
5. LPD printing support.
6. Legacy client support via /etc/printcap and
/etc/printers.conf. This kills printing from GNOME apps
on Solaris 10, for example.
7. (future) Kerberos support.

Yes. Number 5 is a problem for me. This is why I gave up on ubuntu for
the server. Thanks for
the other info. I guess the real issue is security in general, i.e., we
must have
some process running as root and assuming there aren't any outright bugs
in that process one should use some kind of external tool to provide further
security. Perhaps a chroot?
Or SeLinux?

Post by Michael Sweet
You are also leaving yourself open to filter-based attacks because
of the loss of privilege separation.

[wtautz]

Post by Michael Sweet

Michael, Does cups allow running as a non-root user? Obviously
I know I could just start it up as a non-root user but that clearly
implies it would have limited capabilities from the start.
Most daemons that run as a non-root user usually start up
as root and then exec a child with lesser priviledges *after*
they checked things like permissions and the like.

Actually, it is a crap shoot whether the daemon will do this
for you, however for CUPS we MUST run as root in order to do
many common things. As I covered in my presentation at the
Linux Printing Summit this year, running as an unprivileged
user is actually *less* secure with CUPS, as you lose the
privilege separation between scheduler and filters which have
a lot less auditing done on them...

Are the slides for this presentation available online?

[Kurt Pfeifle]

Post by wtautz

Post by Michael Sweet

Michael, Does cups allow running as a non-root user? Obviously
I know I could just start it up as a non-root user but that clearly
implies it would have limited capabilities from the start.
Most daemons that run as a non-root user usually start up
as root and then exec a child with lesser priviledges *after*
they checked things like permissions and the like.

Actually, it is a crap shoot whether the daemon will do this
for you, however for CUPS we MUST run as root in order to do
many common things. As I covered in my presentation at the
Linux Printing Summit this year, running as an unprivileged
user is actually *less* secure with CUPS, as you lose the
privilege separation between scheduler and filters which have
a lot less auditing done on them...

Are the slides for this presentation available online?

All slides are available here:

http://groups.osdl.org/workgroups/dtl/desktop_architects/desktop_printing

Specifically, Mike's "CUPS 1.2 Overview" one is here:


http://groups.osdl.org/apps/group_public/download.php/2251/print-summit-cups-1.2-overview.pdf

Cheers,
Kurt

[Michael Sweet]

Post by wtautz
...

Post by Michael Sweet
1. Printing and browsing on port 631 (or any port < 1024)
2. Automatic root authentication via certificates.
3. Proxy authentication support (you'll need to hardcode
usernames and passwords in your device URIs again).
4. Local account authentication via PAM (although I've
heard there is now a workaround for this by adding the
user you run cupsd as to a PAM group)
5. LPD printing support.
6. Legacy client support via /etc/printcap and
/etc/printers.conf. This kills printing from GNOME apps
on Solaris 10, for example.
7. (future) Kerberos support.

Yes. Number 5 is a problem for me. This is why I gave up on ubuntu for
the server. Thanks for
the other info. I guess the real issue is security in general, i.e., we
must have
some process running as root and assuming there aren't any outright bugs
in that process one should use some kind of external tool to provide further
security. Perhaps a chroot?
Or SeLinux?

Fedora Core and Red Hat Enterprise Linux already provide a CUPS
policy (for SELinux) that provides additional (sometimes too much! :)
protection/insurance on top of the built-in cupsd security measures
and privilege separation. I believe the current Fedora Core policies
are up-to-date for CUPS 1.2 - not sure about RHEL though...