Red Hat Bugzilla – Bug 124382
Execution of /usr/bin/lockdev should transition into domain that is allowed to mess with /var/lock
Last modified: 2007-11-30 17:10:43 EST
Currently /usr/sbin/lockdev has an ordinary sbin_t SELinux type. As a
result, lockdev-enabled programs need special permissions to
read/add/remove the lock files in /var/lock. This is IMHO wrong - it
would be much more consistent to transition into a lockdev_t domain on
executing /usr/sbin/lockdev and then allow the lockdev_t, not the
original domain to access /var/lock.
I need more info? What is failing here?
It might be a problem if apps transitioned to lockdev, and you needed
to give lockdev access to all /var/lock files.
Programs that are supposed to give users access to certain serial
devices (including minicom and gphoto2) are compiled against the
liblockdev library that implements locking using a setgid helper
program /usr/sbin/lockdev (that allows arbitrary users to
install/remove locks in the /var/locks directory, possibly with some
appropriate permission checks). Note that the users themselves do not
have write permissions to /var/locks (which is the whole point).
Now enters SELinux. Suddenly users can not touch /var/locks even with
the help of a setgid binary. As a result, minicon, gphoto2 (and other
similar programs, such as efax and kandy once bug 79615 and bug 84143
are fixed) are no longer able to lock the serial devices when ran by
an ordinary user.
Basically, the whole point of the /usr/sbin/lockdev binary is a
limited privilegde elevation and it needs to be supported under
SELinux as well.
Thanks I will look into adding SELinux support to it.
Added fixes to selinux-policy-strict-1.18.2-3
Tested it out with minilog.
Please try it out.