Bug 124382 – Execution of /usr/bin/lockdev should transition into domain that is allowed to mess with /var/lock

Bug 124382 - Execution of /usr/bin/lockdev should transition into domain that is allowed to mess with /var/lock

Summary:	Execution of /usr/bin/lockdev should transition into domain that is allowed t...

Status:	CLOSED CURRENTRELEASE

Aliases:	None

Product:	Fedora
Classification:	Fedora
Component:	policy (Show other bugs)
Sub Component:
Version:	rawhide
Hardware:	All Linux

Priority	medium Severity medium
Target Milestone:	---
Target Release:	---
Assigned To:	Daniel Walsh
QA Contact:	Ben Levenson
Docs Contact:

URL:
Whiteboard:
Keywords:	SELinux

Depends On:
Blocks:
	Show dependency tree / graph

Reported:	2004-05-26 00:56 EDT by Aleksey Nogin
Modified:	2007-11-30 17:10 EST (History)
CC List:	3 users (show)

See Also:
Fixed In Version:
Doc Type:	Bug Fix
Doc Text:
Story Points:	---
Clone Of:
Environment:
Last Closed:	2004-11-30 14:04:32 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)
Add an attachment (proposed patch, testcase, etc.)

Groups: None (edit)

Description Aleksey Nogin 2004-05-26 00:56:56 EDT

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.

Comment 1 Daniel Walsh 2004-11-06 01:44:12 EST

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.

Dan

Comment 2 Aleksey Nogin 2004-11-06 02:00:02 EST

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.

Comment 3 Daniel Walsh 2004-11-06 13:41:08 EST

Thanks I will look into adding SELinux support to it.

Dan

Comment 4 Daniel Walsh 2004-11-08 13:46:12 EST

Added fixes to selinux-policy-strict-1.18.2-3

Tested it out with minilog.

Please try it out.

Dan

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