Running targeted/enforcing, latest rawhide.
If I 'remove' a USB printer (via 'rmmod usblp') and then reboot, printconf-tui tries to create the directory /var/cache/foomatic. This fails with:
type=AVC msg=audit( 1126301390.416:17): avc: denied { create } for pid=3106 comm="printconf-tui" name="foomatic" scontext=system_u:system_r:cupsd_config_t tcontext=system_u:object_r:var_t tclass=dir type=SYSCALL msg=audit( 1126301390.416:17): arch=40000003 syscall=39 success=no exit=-13 a0=9aefe10 a1=1ed a2=778468 a3=b7345a2c items=1 pid=3106 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 comm="printconf-tui" exe="/usr/bin/python" type=CWD msg=audit(1126301390.416:17): cwd="/" type=PATH msg=audit(1126301390.416:17): item=0 name="/var/cache/foomatic" flags=10 inode=2142136 dev=fd:00 mode=040755 ouid=0 ogid=0 rdev=00:00
[This seems 'harmless', since printing appears to work, but ...]
Does this seem correct? tom
--- /tmp/cups.te 2005-09-09 15:38:31.000000000 -0700 +++ ./cups.te 2005-09-09 14:56:26.000000000 -0700 @@ -240,7 +240,7 @@ rw_dir_create_file(cupsd_config_t, cupsd_etc_t) rw_dir_create_file(cupsd_config_t, cupsd_rw_etc_t) file_type_auto_trans(cupsd_config_t, cupsd_etc_t, cupsd_rw_etc_t, file) -file_type_auto_trans(cupsd_config_t, var_t, cupsd_rw_etc_t, file) +file_type_auto_trans(cupsd_config_t, var_t, cupsd_rw_etc_t, { file dir }) allow cupsd_config_t var_t:lnk_file read;
can_network_tcp(cupsd_config_t)
On Saturday 10 September 2005 08:40, Tom London selinux@gmail.com wrote:
Running targeted/enforcing, latest rawhide.
If I 'remove' a USB printer (via 'rmmod usblp') and then reboot, printconf-tui tries to create the directory /var/cache/foomatic. This fails with:
[This seems 'harmless', since printing appears to work, but ...]
If there is no functionality lost through not allowing this then I don't think it's a good idea to allow it.
Why is the directory being created? If the directory in question deserves to exist then should it be created by the package and therefore have no need for the printconf-tui program to create it?
On Mon, Sep 12, 2005 at 06:15:26PM +1000, Russell Coker wrote:
Why is the directory being created? If the directory in question deserves to exist then should it be created by the package and therefore have no need for the printconf-tui program to create it?
It is created to cache some information which otherwise is read from the XML files in /usr/share/foomatic/db. The cache file is to speed up the process.
Even if the directory exists, the file will need to be created.
Tim. */
On Monday 12 September 2005 19:51, Tim Waugh twaugh@redhat.com wrote:
On Mon, Sep 12, 2005 at 06:15:26PM +1000, Russell Coker wrote:
Why is the directory being created? If the directory in question deserves to exist then should it be created by the package and therefore have no need for the printconf-tui program to create it?
It is created to cache some information which otherwise is read from the XML files in /usr/share/foomatic/db. The cache file is to speed up the process.
Even if the directory exists, the file will need to be created.
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=168085
I've submitted the above bugzilla requesting that the package provide this directory. Tom, please review it and make any comments you consider appropriate.
On 9/12/05, Russell Coker russell@coker.com.au wrote:
On Monday 12 September 2005 19:51, Tim Waugh twaugh@redhat.com wrote:
On Mon, Sep 12, 2005 at 06:15:26PM +1000, Russell Coker wrote:
Why is the directory being created? If the directory in question deserves to exist then should it be created by the package and therefore have no need for the printconf-tui program to create it?
It is created to cache some information which otherwise is read from the XML files in /usr/share/foomatic/db. The cache file is to speed up the process.
Even if the directory exists, the file will need to be created.
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=168085
I've submitted the above bugzilla requesting that the package provide this directory. Tom, please review it and make any comments you consider appropriate.
The fix posted there is much better.
Are there more services like this that we should review for directory-create in /var and other places? Will polyinstantiatiation help clean this up?
tom
On Monday 12 September 2005 23:29, Tom London selinux@gmail.com wrote:
It is created to cache some information which otherwise is read from the XML files in /usr/share/foomatic/db. The cache file is to speed up the process.
Even if the directory exists, the file will need to be created.
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=168085
I've submitted the above bugzilla requesting that the package provide this directory. Tom, please review it and make any comments you consider appropriate.
The fix posted there is much better.
Are there more services like this that we should review for directory-create in /var and other places? Will polyinstantiatiation help clean this up?
There are probably other services with the same issues.
PI will not help at all. The absolute last thing I want to see is multiple PI versions of /var which will cause all sorts of problems for communications between daemons (think about /var/log and /var/run, and I'm sure that some daemons mess with other daemons' files under /var/cache).
I don't believe that there is any need for PI for anything other than files and directories created by regular users. That means /tmp and a possibility of home directories for different levels with MLS. I'm sure that someone will disagree however and I am waiting for email debating this point.
On 9/12/05, Russell Coker russell@coker.com.au wrote:
There are probably other services with the same issues.
PI will not help at all. The absolute last thing I want to see is multiple PI versions of /var which will cause all sorts of problems for communications between daemons (think about /var/log and /var/run, and I'm sure that some daemons mess with other daemons' files under /var/cache).
I don't believe that there is any need for PI for anything other than files and directories created by regular users. That means /tmp and a possibility of home directories for different levels with MLS. I'm sure that someone will disagree however and I am waiting for email debating this point.
OK, so the rubric here is that daemon-like services need to have their 'major' directory entries in places like /var created and labeled by their package, not created upon startup. This sounds quite reasonable.
So, the normal 'name space' conflicts will likely be detected during package install.
Do we need to be concerned with possible 'widening' conflicts on such directories (e.g., two packages wanting to 'own' the same directory, one with a 'wider' label)?
tom
Thread taken from fedora-selinux-list to fedora-devel-list for a wider audience. The general concept is that a daemon should never create a directory under /var/cache (or similar non-specific places on the file system) at run-time. If /var/cache/$DAEMON is needed then the package of $DAEMON should provide that directory. This prevents the possible problem of name conflicts and allows more restrictive SE Linux access control (preventing a compromised daemon from performing a trivial DOS attack on other daemons).
On Tuesday 13 September 2005 01:30, Tom London selinux@gmail.com wrote:
OK, so the rubric here is that daemon-like services need to have their 'major' directory entries in places like /var created and labeled by their package, not created upon startup. This sounds quite reasonable.
Yes, that's my idea.
So, the normal 'name space' conflicts will likely be detected during package install.
One of several benefits of it.
Do we need to be concerned with possible 'widening' conflicts on such directories (e.g., two packages wanting to 'own' the same directory, one with a 'wider' label)?
What do you mean "wider"? Do you mean less restrictive permissions? If so then it certainly would be a problem if two packages desired different permissions for a single file system object, whether one is a superset of the other or whether they are disjoint. It is something that we need to be concerned about, but it will hopefully be rare and we can just fix it when it occurs.
Detecting and solving such problems is an advantage of my suggestion. When we have such directories in packages we can easily check for such conflicts. At the moment I suspect that such daemon behavior is not uncommon and don't know in what situations it may potentially bite us.
On 9/12/05, Russell Coker russell@coker.com.au wrote:
Thread taken from fedora-selinux-list to fedora-devel-list for a wider audience. The general concept is that a daemon should never create a directory under /var/cache (or similar non-specific places on the file system) at run-time. If /var/cache/$DAEMON is needed then the package of $DAEMON should provide that directory. This prevents the possible problem of name conflicts and allows more restrictive SE Linux access control (preventing a compromised daemon from performing a trivial DOS attack on other daemons).
On Tuesday 13 September 2005 01:30, Tom London selinux@gmail.com wrote:
OK, so the rubric here is that daemon-like services need to have their 'major' directory entries in places like /var created and labeled by their package, not created upon startup. This sounds quite reasonable.
Yes, that's my idea.
So, the normal 'name space' conflicts will likely be detected during package install.
One of several benefits of it.
Do we need to be concerned with possible 'widening' conflicts on such directories (e.g., two packages wanting to 'own' the same directory, one with a 'wider' label)?
What do you mean "wider"? Do you mean less restrictive permissions? If so then it certainly would be a problem if two packages desired different permissions for a single file system object, whether one is a superset of the other or whether they are disjoint. It is something that we need to be concerned about, but it will hopefully be rare and we can just fix it when it occurs.
Detecting and solving such problems is an advantage of my suggestion. When we have such directories in packages we can easily check for such conflicts. At the moment I suspect that such daemon behavior is not uncommon and don't know in what situations it may potentially bite us.
What I'm concerned about are situations (like, e.g., /usr/lib/mozilla) where two packages (e.g., mozplugger and firefox, on my machine) seem to 'provide' the same directory (at least as reported by 'rpm -qif /usr/lib/mozilla').
In such a case, if 'the first to install' package created the directory with a less restrictive context (or some such), would we have a chance for a problem?
Do we need some way to coordinate/check this?
tom
selinux@lists.fedoraproject.org
-
Russell Coker -
Tim Waugh -
Tom London