Prev · NextSTR #2935: please support less restricted root backend permissions

Status:4 - Pending
Priority:1 - Request for Enhancement, e.g. asking for a feature
Scope:3 - Applies to all machines and operating systems
Subsystem:Scheduler
Summary:please support less restricted root backend permissions
Version: -feature
Created By:martin.pitt.canonical
Assigned To:mike
Fix Version:Unassigned
Update Notification:

Receive EMails Don't Receive EMails


Trouble Report Files:

Name/Time/Date/Filename/Size
martin.pitt.canonical: 09:30 Sep 06, 2008
 
rootbackends-worldreadable.dpatch (2k)
 
martin.pitt.canonical: 01:00 Sep 07, 2008
 
rootbackends-worldreadable_v2.dpatch (2k)
 
martin.pitt.canonical: 03:06 Nov 17, 2008
 
rootbackends-worldreadable_v3.dpatch (3k)
 

Trouble Report Dialog:

Name/Time/Date/Text
martin.pitt.canonical: 04:39 Sep 06, 2008
 
At the moment, backends which run as root need to be 0700, i. e. not have any privileges for group or others. This is very rigid and e. g. prevents system integrity checkers, bug report scripts, and other tools from verifying the contents of those backends (and also violates the Debian Policy). Distribution packages should not ship binaries which are not world readable, since anyone can just download the package and get it from there.

Would you consider relaxing the check in scheduler/job.c a bit?

     backroot = !(backinfo.st_mode & (S_IRWXG | S_IRWXO));

this could become

    backroot = !(backinfo.st_mode & (S_IXGRP | S_IXOTH));

so that it is possible to install those backends with 744 permissions.

Preferably the backends should installed with 744 mode as well, but if you don't like that, upstream could stay with installing them as 700 (distros can easily adapt the permissions in their build scripts without patching the source).

Thanks for considering,

Martin

 
mike: 11:56 Sep 06, 2008
 
First, this should be an enhancement request, not a bug report.

Second, I don't know whether we will make this change since it has serious security issues. IMHO any integrity checker needs to run as root as well.

 
martin.pitt.canonical: 14:38 Sep 06, 2008
 
I am curious, what are those "serious security issues"? Built binaries from open source software are hardly that secret? (And if you do local s3kr1t modifications, nobody stops you from chmoding them to 700).

Feel free to drop the Makefile part of the patch. The more important issue is to run backends with 744 permisssions as root as well.

 
mike: 20:55 Sep 06, 2008
 
The main security issue is that some system files/directories are restricted to provide necessary security, but a non-root tool will not be able to validate them - you would be missing a fairly significant portion of sensitive system/log files...

Also, it is fairly easy to accidentally install with partial execute permissions, which would lead to accidental running of the backends as root with your patch.

Anyways, don't expect any change (if we do decide to make a change) until CUPS 1.5 at the earliest.

 
martin.pitt.canonical: 01:04 Sep 07, 2008
 
Posted updated patch which also checks for group/other writeability.

> Also, it is fairly easy to accidentally install with partial execute
> permissions, which would lead to accidental running of the backends as
> root with your patch.

But in principle that is the same in the current version as well, just the particularly tested privileges are a bit different (if you install backends with umask 077, you'd get backends installed as root as well). That's why we are using distro packages, or at least "make install" instead of setting up files by hand, right? :-)

 
martin.pitt.canonical: 03:06 Nov 17, 2008
 
Updated patch, missed the identical test in deviced.