5:40 p.m.
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)
--
Tom London
3:15 a.m.
On Saturday 10 September 2005 08:40, Tom London <selinux(a)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?
--
http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages
http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/ Postal SMTP/POP benchmark
http://www.coker.com.au/~russell/ My home page
4:51 a.m.
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.
*/
5:17 a.m.
On Monday 12 September 2005 19:51, Tim Waugh <twaugh(a)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.
--
http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages
http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/ Postal SMTP/POP benchmark
http://www.coker.com.au/~russell/ My home page
8:29 a.m.
On 9/12/05, Russell Coker <russell(a)coker.com.au> wrote:
On Monday 12 September 2005 19:51, Tim Waugh <twaugh(a)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
--
Tom London
9:19 a.m.
On Monday 12 September 2005 23:29, Tom London <selinux(a)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.
--
http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages
http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/ Postal SMTP/POP benchmark
http://www.coker.com.au/~russell/ My home page
10:30 a.m.
On 9/12/05, Russell Coker <russell(a)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
--
Tom London
5:26 p.m.
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(a)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.
--
http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages
http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/ Postal SMTP/POP benchmark
http://www.coker.com.au/~russell/ My home page
9:36 a.m.
On 9/12/05, Russell Coker <russell(a)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(a)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
--
Tom London
6800
days inactive
6804
days old
selinux@lists.fedoraproject.org
8 comments
3 participants
participants (3)
-
Russell Coker -
Tim Waugh -
Tom London