reconnecting USB p rinter

[Tom London]

Running strict/enforcing, w/USB printer.

Reconnecting printer (after pulling the plug) yields the following:

Sep 25 18:46:47 fedora kernel: audit(1096163207.182:0): avc:  denied 
{ search } for  pid=7592 exe=/usr/sbin/hal_lpadmin name=cups dev=hda2
ino=4474131 scontext=system_u:system_r:hald_t
tcontext=system_u:object_r:cupsd_etc_t tclass=dir
Sep 25 18:46:48 fedora kernel: audit(1096163208.050:0): avc:  denied 
{ read } for  pid=7593 exe=/usr/bin/python name=printconf_tui.py
dev=hda2 ino=4309021 scontext=system_u:system_r:hald_t
tcontext=system_u:object_r:printconf_t tclass=file
Sep 25 18:46:48 fedora kernel: audit(1096163208.050:0): avc:  denied 
{ getattr } for  pid=7593 exe=/usr/bin/python
path=/usr/share/printconf/util/printconf_tui.py dev=hda2 ino=4309021
scontext=system_u:system_r:hald_t
tcontext=system_u:object_r:printconf_t tclass=file
Sep 25 18:46:49 fedora kernel: audit(1096163209.538:0): avc:  denied 
{ read } for  pid=7595 exe=/usr/bin/perl name=urandom dev=tmpfs
ino=965 scontext=system_u:system_r:hald_t
tcontext=system_u:object_r:urandom_device_t tclass=chr_file

Attached patch to cups.te adds allow rules for these.

Please correct/edit/etc.
   tom

[Russell Coker]

On Sun, 26 Sep 2004 12:01, Tom London  wrote:
> Running strict/enforcing, w/USB printer.
>
> Reconnecting printer (after pulling the plug) yields the following:

allow hald_t urandom_device_t:chr_file { read };

The above line should go unconditionally in hald.te not in cups.te.  The 
reason is that hald might access urandom_device_t for many things other than 
printer configuration, and we don't want the other things to suddenly stop 
working if we remove the cups policy.

Also for neat policy I think it's best not to put {} around a single item.

I've attached a diff between the policy in my tree for hal and cups and that 
of the CVS.  Please note that removing the dontaudit from cups.te is 
deliberate, there is a matching allow rule later in the same file.

[Tom London]

Applied, and fixes above mentioned issues.

However, there is another problem here. The second time I 
disconnect the printer, I get a horde of AVCs, all from hald_t
apparently attempting to access 'everything', from apmd_t
through xfs_t (with the kitchen sink in between)....

'ps agxZ' yields:
root:sysadm_r:sysadm_t           4686 pts/2    S      0:00 -bash
system_u:system_r:hald_t         5443 ?        Ss     0:00 cupsd
root:sysadm_r:sysadm_t           5571 pts/2    R+     0:00 ps agxZ

That's not right, is it? Shouldn't cupsd be running in cupsd_t?

It looks like when hald restarts cupsd after the 'first reconnection',
its not transitioning it to cupsd_t.

The following patch adds a 
domain_auto_trans(hald_t, cupsd_exec_t, cupsd_t)
to cups.te

This makes the 'new' cupsd run in cupsd_t. 
This doesn't fix everything, as there are still about 170 AVCs.

Do we need to add a bunch of 'domain_auto_trans' rules for
hald_t (for apmd_t, crond_t, ......)?  dontaudits?

I attach the AVCs from a 'disconnect/reconnect' cycle running
a policy with the hald_t->cupsd_t auto_trans rule.

Help appreciated!
   tom

On Sun, 26 Sep 2004 23:14:37 +1000, Russell Coker  wrote:
> On Sun, 26 Sep 2004 12:01, Tom London  wrote:
> > Running strict/enforcing, w/USB printer.
> >
> > Reconnecting printer (after pulling the plug) yields the following:
>
> allow hald_t urandom_device_t:chr_file { read };
>
> The above line should go unconditionally in hald.te not in cups.te.  The
> reason is that hald might access urandom_device_t for many things other than
> printer configuration, and we don't want the other things to suddenly stop
> working if we remove the cups policy.
>
> Also for neat policy I think it's best not to put {} around a single item.
>
> I've attached a diff between the policy in my tree for hal and cups and that
> of the CVS.  Please note that removing the dontaudit from cups.te is
> deliberate, there is a matching allow rule later in the same file.
>
> --
> 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

[Russell Coker]

On Mon, 27 Sep 2004 04:28, Tom London  wrote:
> That's not right, is it? Shouldn't cupsd be running in cupsd_t?

Correct.
> The following patch adds a
> domain_auto_trans(hald_t, cupsd_exec_t, cupsd_t)
> to cups.te

Good work, I've put that in my tree.

Also we should remove the can_exec_any() from hald.te ASAP, it's a time bomb 
allowing large numbers of undesired programs to run in hald_t.
> This makes the 'new' cupsd run in cupsd_t.
> This doesn't fix everything, as there are still about 170 AVCs.
>
> Do we need to add a bunch of 'domain_auto_trans' rules for
> hald_t (for apmd_t, crond_t, ......)?  dontaudits?

I'll look into that later.