Bug 627975 - /dev/{watchdog,hugepages,hugepages/libvirt,hugepages/libvirt/qemu,microcode} have incorrect SELinux labels
/dev/{watchdog,hugepages,hugepages/libvirt,hugepages/libvirt/qemu,microcode} ...
Status: CLOSED EOL
Product: Fedora
Classification: Fedora
Component: systemd (Show other bugs)
19
All Linux
low Severity medium
: ---
: ---
Assigned To: udev-maint
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2010-08-27 10:29 EDT by Tom London
Modified: 2015-01-05 21:39 EST (History)
13 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2015-01-05 21:39:14 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Tom London 2010-08-27 10:29:59 EDT
Description of problem:
I'm noticing this:

[root@tlondon ~]# restorecon -v -R -n /dev
restorecon reset /dev/watchdog context system_u:object_r:device_t:s0->system_u:object_r:watchdog_device_t:s0
restorecon reset /dev/hugepages context system_u:object_r:hugetlbfs_t:s0->system_u:object_r:device_t:s0
restorecon reset /dev/hugepages/libvirt context system_u:object_r:hugetlbfs_t:s0->system_u:object_r:device_t:s0
restorecon reset /dev/hugepages/libvirt/qemu context system_u:object_r:hugetlbfs_t:s0->system_u:object_r:device_t:s0
restorecon reset /dev/cpu/microcode context system_u:object_r:device_t:s0->system_u:object_r:cpu_device_t:s0
[root@tlondon ~]# 

So it appears that these are not being labeled according to the current policy on creation.

Version-Release number of selected component (if applicable):
selinux-policy-3.8.8-21.fc15.noarch
selinux-policy-targeted-3.8.8-21.fc15.noarch
udev-161-1.fc15.x86_64

How reproducible:
Believe every boot

Steps to Reproduce:
1.
2.
3.
  
Actual results:


Expected results:


Additional info:
Comment 1 Daniel Walsh 2010-08-27 10:45:39 EDT
Are these being created by systemd?  dracut?  Why aren't they being labeled correctly by udev?
Comment 2 Harald Hoyer 2010-08-30 05:41:55 EDT
(In reply to comment #1)
> Are these being created by systemd?  dracut?  Why aren't they being labeled
> correctly by udev?

hmm... nothing changed regarding the selinux code.

So, what I can imaging, is that:

- they are present in devtmpfs and not yet managed by udev
- the modules are not yet loaded

what is the output of:

# for i in /dev/{watchdog,hugepages,hugepages/libvirt,hugepages/libvirt/qemu,microcode}; do udevadm info --query=all --name=$i;done
Comment 3 Tom London 2010-08-30 09:19:25 EDT
(In reply to comment #2)
> (In reply to comment #1)
> > Are these being created by systemd?  dracut?  Why aren't they being labeled
> > correctly by udev?
> 
> hmm... nothing changed regarding the selinux code.
> 
> So, what I can imaging, is that:
> 
> - they are present in devtmpfs and not yet managed by udev
> - the modules are not yet loaded
> 
> what is the output of:
> 
> # for i in
> /dev/{watchdog,hugepages,hugepages/libvirt,hugepages/libvirt/qemu,microcode};
> do udevadm info --query=all --name=$i;done

On my system:

[root@tlondon ~]# for i in /dev/{watchdog,hugepages,hugepages/libvirt,hugepages/libvirt/qemu,microcode}; do echo $i; ls -lZ $i; udevadm info --query=all --name=$i;done
/dev/watchdog
crw-------. root root system_u:object_r:device_t:s0    /dev/watchdog
P: /devices/virtual/misc/watchdog
N: watchdog
S: char/10:130
E: UDEV_LOG=3
E: DEVPATH=/devices/virtual/misc/watchdog
E: SUBSYSTEM=misc
E: DEVNAME=/dev/watchdog
E: MAJOR=10
E: MINOR=130
E: DEVLINKS=/dev/char/10:130

/dev/hugepages
drwxr-xr-x. root root system_u:object_r:hugetlbfs_t:s0 libvirt
device node has wrong file type
/dev/hugepages/libvirt
drwxr-xr-x. qemu qemu system_u:object_r:hugetlbfs_t:s0 qemu
device node has wrong file type
/dev/hugepages/libvirt/qemu
device node has wrong file type
/dev/microcode
ls: cannot access /dev/microcode: No such file or directory
device node not found
[root@tlondon ~]#
Comment 4 Harald Hoyer 2010-08-30 09:25:40 EDT
"device node has wrong file type" ? So they are not devices?
Comment 5 Tom London 2010-08-30 09:41:43 EDT
Hmm... "fleeting nodes"?

I also noticed this AVC in this morning's boot:

[root@tlondon ~]# dmesg | grep avctype=1400 audit(1283173495.780:4): avc:  denied  { mmap_zero } for  pid=475 comm="vbetool" scontext=system_u:system_r:vbetool_t:s0-s0:c0.c1023 tcontext=system_u:system_r:vbetool_t:s0-s0:c0.c1023 tclass=memprotect
type=1400 audit(1283173497.707:5): avc:  denied  { read } for  pid=748 comm="alsactl" name="controlC0" dev=devtmpfs ino=11551 scontext=system_u:system_r:alsa_t:s0-s0:c0.c1023 tcontext=system_u:object_r:device_t:s0 tclass=chr_file
[root@tlondon ~]# 

[Ignore the first one....]

Now:
[root@tlondon ~]# ls -li /dev/snd/controlC0
11551 crw-rw----+ 1 root audio 116, 9 Aug 30 06:04 /dev/snd/controlC0
[root@tlondon ~]# 

So this is the "right" node, but the AVC reports the "wrong" label, namely device_t.  But

[root@tlondon ~]# ls -lZ /dev/snd/controlC0
crw-rw----+ root audio system_u:object_r:sound_device_t:s0 /dev/snd/controlC0
[root@tlondon ~]# 

So this is being reported now as sound_device_t.
Comment 6 Tom London 2010-08-31 09:27:09 EDT
Got 2 more (similar?) with this morning's boot:

Aug 31 06:04:48 tlondon kernel: type=1403 audit(1283259864.919:3): policy loaded auid=4294967295 ses=4294967295
Aug 31 06:04:48 tlondon kernel: dracut:
Aug 31 06:04:48 tlondon kernel: type=1400 audit(1283259865.215:4): avc:  denied  { associate } for  pid=383 comm="restorecon" name="pts" dev=devtmpfs ino=6130 scontext=system_u:object_r:devpts_t:s0 tcontext=system_u:object_r:device_t:s0 tclass=filesystem
Aug 31 06:04:48 tlondon kernel: type=1400 audit(1283259865.218:5): avc:  denied  { associate } for  pid=383 comm="restorecon" name="shm" dev=devtmpfs ino=6127 scontext=system_u:object_r:tmpfs_t:s0 tcontext=system_u:object_r:device_t:s0 tclass=filesystem
Aug 31 06:04:48 tlondon kernel: dracut: Switching root

Can't seem to find either of these files... 'find / -inum {6130,6127} -print' returns nothing appropriate:

[root@tlondon tmp]# find / -inum 6130 -print
find: `/home/tbl/.gvfs': Permission denied
/sys/kernel/slab/xfrm_dst_cache/order
[root@tlondon tmp]# 

and

[root@tlondon tmp]# find / -inum 6127 -print
find: `/home/tbl/.gvfs': Permission denied
/sys/kernel/slab/xfrm_dst_cache/slab_size
[root@tlondon tmp]# 

Every few boots I seem to get some similar AVCs.
Comment 7 sangu 2011-04-22 12:30:31 EDT
/dev/nvidia0 and /dev/nvidiactl have incorrect SElinx labels, too.

Is this issue nvidia closed driver bug? or udev bug?

udev-167-4.fc15.x86_64, nvidia closed driver 270.41.0X.

See Also : bug 694918
Comment 8 Fedora Admin XMLRPC Client 2011-10-20 12:08:08 EDT
This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.
Comment 9 Fedora Admin XMLRPC Client 2011-10-20 12:10:10 EDT
This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.
Comment 10 Fedora Admin XMLRPC Client 2011-10-20 12:12:35 EDT
This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.
Comment 11 Fedora Admin XMLRPC Client 2011-10-20 12:17:02 EDT
This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.
Comment 12 Fedora End Of Life 2013-04-03 15:08:33 EDT
This bug appears to have been reported against 'rawhide' during the Fedora 19 development cycle.
Changing version to '19'.

(As we did not run this process for some time, it could affect also pre-Fedora 19 development
cycle bugs. We are very sorry. It will help us with cleanup during Fedora 19 End Of Life. Thank you.)

More information and reason for this action is here:
https://fedoraproject.org/wiki/BugZappers/HouseKeeping/Fedora19
Comment 13 Lennart Poettering 2015-01-05 21:39:14 EST
This appears to be a Fedora 15 bug. If you can reproduce this on a recent, supported Fedora version, please reopen.

Note You need to log in before you can comment on or make changes to this bug.