Shouldn't restorecond be allowed to relabel anything?

[Göran Uddeborg]

When using the Nvidia proprietary drivers, the files /dev/nvidiaN and
/dev/nvidiactl don't get the right context.  That has been discussed
here and elsewhere previously.  As I've understood it, it has to be
fixed in the proprietary code somewhere.

To work around the problem until there is a proper fix, if ever, I
added

    /dev/nvidia0
    /dev/nvidiactl

to /etc/selinux/restorecond.conf.  But now I get a complaint about
restorecond not being allowed to relabel those files:

    type=AVC msg=audit(1312575006.803:33): avc:  denied  { relabelto } for  pid=905
comm="restorecond" name="nvidiactl" dev=devtmpfs ino=18490
scontext=system_u:system_r:restorecond_t:s0
tcontext=system_u:object_r:xserver_misc_device_t:s0 tclass=chr_file

SEtroubleshoot suggests to audit2allow to make a module to allow
that.  I'll do that, so I can work around this problem too.

But I am a bit suprised by the need.  Why isn't restorcond
(or more properly, restorecond_t) allowed to relabel everything?
Isn't that what it is all about?

I did a "sesearch --allow --perm=relabelto --source=restorecond_t" and
got a very long list of allow rules.  I'm not quite sure how those
look in the source code, if all of them have been individually listed,
of if they use some general attributes.  But obviously it's not
completely wildcarded.

Is this a bug or a feature? :-)

[Daniel J Walsh]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 08/05/2011 04:39 PM, Göran Uddeborg wrote:
>  When using the Nvidia proprietary drivers, the files /dev/nvidiaN
>  and /dev/nvidiactl don't get the right context.  That has been
>  discussed here and elsewhere previously.  As I've understood it, it
>  has to be fixed in the proprietary code somewhere.
>  
>  To work around the problem until there is a proper fix, if ever, I 
>  added
>  
>  /dev/nvidia0 /dev/nvidiactl
>  
>  to /etc/selinux/restorecond.conf.  But now I get a complaint about 
>  restorecond not being allowed to relabel those files:
>  
>  type=AVC msg=audit(1312575006.803:33): avc:  denied  { relabelto }
>  for  pid=905 comm="restorecond" name="nvidiactl" dev=devtmpfs
>  ino=18490 scontext=system_u:system_r:restorecond_t:s0
>  tcontext=system_u:object_r:xserver_misc_device_t:s0 tclass=chr_file
>  
>  SEtroubleshoot suggests to audit2allow to make a module to allow 
>  that.  I'll do that, so I can work around this problem too.
>  
>  But I am a bit suprised by the need.  Why isn't restorcond (or more
>  properly, restorecond_t) allowed to relabel everything? Isn't that
>  what it is all about?
>  
>  I did a "sesearch --allow --perm=relabelto --source=restorecond_t"
>  and got a very long list of allow rules.  I'm not quite sure how
>  those look in the source code, if all of them have been individually
>  listed, of if they use some general attributes.  But obviously it's
>  not completely wildcarded.
>  
>  Is this a bug or a feature? :-)
>  
>  
>  
>  -- selinux mailing list selinux(a)lists.fedoraproject.org 
>  https://admin.fedoraproject.org/mailman/listinfo/selinux 
I would say it is a bug.
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.11 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>
> iEYEARECAAYFAk4/3KwACgkQrlYvE4MpobNZqQCdH/vOj8An02wwJQgQz1b/bRBc
> vKcAoODRnTq94UzX8p6jSwTmysS3Bbvv
> =7q0c
> -----END PGP SIGNATURE-----

[Göran Uddeborg]

Daniel J Walsh:
>  On 08/05/2011 04:39 PM, Göran Uddeborg wrote:
>  > Is this a bug or a feature? :-)
>  I would say it is a bug. 
Then I'll provide a bugzilla so someone can have a look at it. :-)

https://bugzilla.redhat.com/show_bug.cgi?id=729451