I'm getting lots of of 'denied' avc for /dev/.udev.tdb from /sbin/udev. I see an entry in file_contexts for '/dev/udev.tbl' (which doesn't seem to exist on my system). Has .udev.tbd replaced udev.tbl? (udev_db in /etc/udev/udev.conf is set to /dev/.udev.tdb).
tom
[udev-029-4, selinux-policy-strict-1.15.7-1] ---------------------------------------------------------------- Jul 19 18:58:54 fedora kernel: audit(1090288734.253:0): avc: denied { read write } for pid=2720 exe=/sbin/udev name=.udev.tdb dev=hda2 ino=2698913 scontext=system_u:system_r:udev_t tcontext=system_u:object_r:device_t tclass=file Jul 19 18:58:54 fedora kernel: audit(1090288734.284:0): avc: denied { read write } for pid=2727 exe=/sbin/udev name=.udev.tdb dev=hda2 ino=2698913 scontext=system_u:system_r:udev_t tcontext=system_u:object_r:device_t tclass=file Jul 19 18:58:54 fedora kernel: audit(1090288734.314:0): avc: denied { read write } for pid=2734 exe=/sbin/udev name=.udev.tdb dev=hda2 ino=2698913 scontext=system_u:system_r:udev_t tcontext=system_u:object_r:device_t tclass=file Jul 19 18:58:54 fedora kernel: audit(1090288734.344:0): avc: denied { read write } for pid=2741 exe=/sbin/udev name=.udev.tdb dev=hda2 ino=2698913 scontext=system_u:system_r:udev_t tcontext=system_u:object_r:device_t tclass=file Jul 19 18:58:54 fedora kernel: audit(1090288734.705:0): avc: denied { read write } for pid=2824 exe=/sbin/udev name=.udev.tdb dev=hda2 ino=2698913 scontext=system_u:system_r:udev_t tcontext=system_u:object_r:device_t tclass=file Jul 19 18:58:54 fedora kernel: audit(1090288734.707:0): avc: denied { read write } for pid=2825 exe=/sbin/udev name=.udev.tdb dev=hda2 ino=2698913 scontext=system_u:system_r:udev_t tcontext=system_u:object_r:device_t tclass=file Jul 19 18:58:54 fedora kernel: audit(1090288734.710:0): avc: denied { read write } for pid=2826 exe=/sbin/udev name=.udev.tdb dev=hda2 ino=2698913 scontext=system_u:system_r:udev_t tcontext=system_u:object_r:device_t tclass=file
On Tue, 20 Jul 2004 13:24, Tom London selinux@comcast.net wrote:
I'm getting lots of of 'denied' avc for /dev/.udev.tdb from /sbin/udev. I see an entry in file_contexts for '/dev/udev.tbl' (which doesn't seem to exist on my system). Has .udev.tbd replaced udev.tbl? (udev_db in /etc/udev/udev.conf is set to /dev/.udev.tdb).
Your analysis sounds reasonable. How do things work if you put the following in udev.fc, run "make install" and then run "restorecon /dev/.udev.tdb"? /dev/.udev.tdb -- system_u:object_r:udev_tbl_t
Yikes.... sorry, but this doesn't look right.... now produces hordes of 'restorecon' avcs....
Jul 20 09:23:46 fedora kernel: audit(1090340592.421:0): avc: denied { read write } for pid=991 exe=/sbin/restorecon path=/dev/.udev.tdb dev=hda2 ino=2698913 scontext=system_u:system_r:restorecon_t tcontext=system_u:object_r:udev_tbl_t tclass=file Jul 20 09:23:47 fedora kernel: audit(1090340592.431:0): avc: denied { read write } for pid=992 exe=/sbin/restorecon path=/dev/.udev.tdb dev=hda2 ino=2698913 scontext=system_u:system_r:restorecon_t tcontext=system_u:object_r:udev_tbl_t tclass=file Jul 20 09:23:47 fedora kernel: audit(1090340600.740:0): avc: denied { unlink } for pid=1297 exe=/sbin/udev name=microcode dev=hda2 ino=2689375 scontext=system_u:system_r:udev_t tcontext=system_u:object_r:device_t tclass=lnk_file Jul 20 09:23:47 fedora kernel: audit(1090340600.759:0): avc: denied { read write } for pid=1309 exe=/sbin/restorecon path=/dev/.udev.tdb dev=hda2 ino=2698913 scontext=system_u:system_r:restorecon_t tcontext=system_u:object_r:udev_tbl_t tclass=file
Russell Coker wrote:
On Tue, 20 Jul 2004 13:24, Tom London selinux@comcast.net wrote:
I'm getting lots of of 'denied' avc for /dev/.udev.tdb from /sbin/udev. I see an entry in file_contexts for '/dev/udev.tbl' (which doesn't seem to exist on my system). Has .udev.tbd replaced udev.tbl? (udev_db in /etc/udev/udev.conf is set to /dev/.udev.tdb).
Your analysis sounds reasonable. How do things work if you put the following in udev.fc, run "make install" and then run "restorecon /dev/.udev.tdb"? /dev/.udev.tdb -- system_u:object_r:udev_tbl_t
On Wed, 21 Jul 2004 02:35, Tom London selinux@comcast.net wrote:
Yikes.... sorry, but this doesn't look right.... now produces hordes of 'restorecon' avcs....
Jul 20 09:23:46 fedora kernel: audit(1090340592.421:0): avc: denied { read write } for pid=991 exe=/sbin/restorecon path=/dev/.udev.tdb dev=hda2 ino=2698913 scontext=system_u:system_r:restorecon_t tcontext=system_u:object_r:udev_tbl_t tclass=file
udev calls restorecon to set the correct type of a device node it has just created.
restorecon has no business in opening /dev/.udev.tdb and I really doubt that it is doing so. I expect that udev is opening /dev/.udev.tdb, not using fcntl(fd, F_SETFD, FD_CLOEXEC) to set the fd to close on execute, and not calling close(fd) before the exec.
Please file a bugzilla report about this. To assist in tracking it down rename /sbin/restorecon to /sbin/restorecon.orig and put the following shell script in place as /sbin/restorecon: #!/bin/sh echo -n params: >> /root/file for n in $*; do echo -n "$n "; done >> /root/file echo "" >> /root/file ls -l /proc/self/fd >> /root/file exec /sbin/restorecon.orig $*
Run the machine in permissive mode while doing this and don't bother about the AVC messages about not being permitted to write to /root/file.
Jul 20 09:23:47 fedora kernel: audit(1090340600.740:0): avc: denied { unlink } for pid=1297 exe=/sbin/udev name=microcode dev=hda2 ino=2689375 scontext=system_u:system_r:udev_t tcontext=system_u:object_r:device_t tclass=lnk_file
allow udev_t device_t:lnk_file create_file_perms; Add the above policy to allow this.
OK, done.
Here are a few entries from the resulting trace of calls to restorecon from a clean reboot with 'enforcing=0'. The first call is the last one in the trace prior to a number of calls from udev:
params:/var/run/sm-client.pid total 4 lrwx------ 1 root root 64 Jul 21 07:28 0 -> /dev/pts/0 l-wx------ 1 root root 64 Jul 21 07:28 1 -> /root/file lrwx------ 1 root root 64 Jul 21 07:28 2 -> /dev/pts/0 lr-x------ 1 root root 64 Jul 21 07:28 3 -> /proc/2423/fd params:/dev/lp0 total 6 lrwx------ 1 root root 64 Jul 21 07:28 0 -> socket:[906] l-wx------ 1 root root 64 Jul 21 07:28 1 -> /root/file l-wx------ 1 root root 64 Jul 21 07:28 2 -> pipe:[914] lrwx------ 1 root root 64 Jul 21 07:28 3 -> socket:[915] lrwx------ 1 root root 64 Jul 21 07:28 4 -> /dev/.udev.tdb lr-x------ 1 root root 64 Jul 21 07:28 5 -> /proc/2446/fd params:/dev/snd/timer total 6 lrwx------ 1 root root 64 Jul 21 07:28 0 -> socket:[906] l-wx------ 1 root root 64 Jul 21 07:28 1 -> /root/file l-wx------ 1 root root 64 Jul 21 07:28 2 -> pipe:[914] lrwx------ 1 root root 64 Jul 21 07:28 3 -> socket:[915] lrwx------ 1 root root 64 Jul 21 07:28 4 -> /dev/.udev.tdb lr-x------ 1 root root 64 Jul 21 07:28 5 -> /proc/2632/fd ...... (many more)
As you suspected, it looks like udev is leaving fd 4 (/dev/.udev.tdb) open across the exec (i.e., has not set FD_CLOEXEC).
I've bugzilla-ed this here: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=128304
Thanks for helping track this down. tom
Russell Coker wrote:
On Wed, 21 Jul 2004 02:35, Tom London selinux@comcast.net wrote:
Yikes.... sorry, but this doesn't look right.... now produces hordes of 'restorecon' avcs....
Jul 20 09:23:46 fedora kernel: audit(1090340592.421:0): avc: denied { read write } for pid=991 exe=/sbin/restorecon path=/dev/.udev.tdb dev=hda2 ino=2698913 scontext=system_u:system_r:restorecon_t tcontext=system_u:object_r:udev_tbl_t tclass=file
udev calls restorecon to set the correct type of a device node it has just created.
restorecon has no business in opening /dev/.udev.tdb and I really doubt that it is doing so. I expect that udev is opening /dev/.udev.tdb, not using fcntl(fd, F_SETFD, FD_CLOEXEC) to set the fd to close on execute, and not calling close(fd) before the exec.
Please file a bugzilla report about this. To assist in tracking it down rename /sbin/restorecon to /sbin/restorecon.orig and put the following shell script in place as /sbin/restorecon: #!/bin/sh echo -n params: >> /root/file for n in $*; do echo -n "$n "; done >> /root/file echo "" >> /root/file ls -l /proc/self/fd >> /root/file exec /sbin/restorecon.orig $*
Run the machine in permissive mode while doing this and don't bother about the AVC messages about not being permitted to write to /root/file.
Jul 20 09:23:47 fedora kernel: audit(1090340600.740:0): avc: denied { unlink } for pid=1297 exe=/sbin/udev name=microcode dev=hda2 ino=2689375 scontext=system_u:system_r:udev_t tcontext=system_u:object_r:device_t tclass=lnk_file
allow udev_t device_t:lnk_file create_file_perms; Add the above policy to allow this.
selinux@lists.fedoraproject.org