Playing a cd from the terminal using cdp, or cdplay (non-interactive), results in the following avc in permissive mode (but the cd is allowed to play):
Apr 26 15:09:24 CirithUngol kernel: audit(1083017364.035:0): avc: denied { ioctl } for pid=10129 exe=/usr/bin/cdp path=/dev/hdc dev=hdb8 ino=66203 scontext=user_u:user_r:user_t tcontext=system_u:object_r:fixed_disk_device_t tclass=blk_file
This is not audited in enforcing mode.. but does not work either (program exits with "please chmod 666 /dev/cdrom as root"). /dev/cdrom is symlinked directly to /dev/hdc.
4.0K lrwxrwxrwx 1 0 0 8 Mar 29 17:26 /dev/cdrom -> /dev/hdc 4.0K brw-rw-rw- 1 0 6 22, 0 Feb 23 13:02 /dev/hdc
Is this expected, or desired behavior? Shouldn't a locally logged in user be allowed access to audio cds? (perhaps should be -or is- tunable)
I'm working with policy-sources-1.11.2-13.
Andrew Farris wrote:
Playing a cd from the terminal using cdp, or cdplay (non-interactive), results in the following avc in permissive mode (but the cd is allowed to play):
Apr 26 15:09:24 CirithUngol kernel: audit(1083017364.035:0): avc: denied { ioctl } for pid=10129 exe=/usr/bin/cdp path=/dev/hdc dev=hdb8 ino=66203 scontext=user_u:user_r:user_t tcontext=system_u:object_r:fixed_disk_device_t tclass=blk_file
Please put in a bugzilla. The problem is that /dev/hdc is labeled wrong. It should have a label of removable_disk_device_t. The problem is there is currently no good way of determining what cdrom disk is from a fixed disk, from a policy point of view. We are investigating ideas around using kudzu to relabel the devices.
If you do a chcon -t removable_disk_device_t /dev/hdc does the problem go away?
Dan
This is not audited in enforcing mode.. but does not work either (program exits with "please chmod 666 /dev/cdrom as root"). /dev/cdrom is symlinked directly to /dev/hdc.
4.0K lrwxrwxrwx 1 0 0 8 Mar 29 17:26 /dev/cdrom -> /dev/hdc 4.0K brw-rw-rw- 1 0 6 22, 0 Feb 23 13:02 /dev/hdc
Is this expected, or desired behavior? Shouldn't a locally logged in user be allowed access to audio cds? (perhaps should be -or is- tunable)
I'm working with policy-sources-1.11.2-13.
On Wed, 28 Apr 2004, Daniel J Walsh wrote:
Please put in a bugzilla. The problem is that /dev/hdc is labeled wrong. It should have a label of removable_disk_device_t. The problem is there is currently no good way of determining what cdrom disk is from a fixed disk, from a policy point of view. We are investigating ideas around using kudzu to relabel the devices.
Please do not use that abomination called kudzu to determine policy.
First off, userland tools have no place in determining policy in my opinion, especially not in the case of removable media.
Secondly, I despise kudzu. It is an abomination which get removed forthwith from any system I maintain.
On Wed, 2004-04-28 at 16:42, Thomas Molina wrote:
Please do not use that abomination called kudzu to determine policy.
First off, userland tools have no place in determining policy in my opinion, especially not in the case of removable media.
Secondly, I despise kudzu. It is an abomination which get removed forthwith from any system I maintain.
Oh, come on now, Thomas, please, don't hold back; tell us how you really feel :-).
Seriously, though, I am curious to know what is wrong, here. Aside from the fact that kudzu is for hardware detection and SELinux is not hardware, why is kudzu (in your opinion) is so "evil"?
That question asked, I have to say that I am inclined to think that as long as kudzu is around in a system with SELinux, we are going to have to accept the need for it (kudzu) to work withing that (SELinux) environment. I do not yet agree that there is need for kudzu to alter policies, but I am going to reserve judgment until after further discussion.
On Thu, 29 Apr 2004, Lamont R. Peterson wrote:
On Wed, 2004-04-28 at 16:42, Thomas Molina wrote:
Please do not use that abomination called kudzu to determine policy.
First off, userland tools have no place in determining policy in my opinion, especially not in the case of removable media.
Secondly, I despise kudzu. It is an abomination which get removed forthwith from any system I maintain.
Oh, come on now, Thomas, please, don't hold back; tell us how you really feel :-).
Seriously, though, I am curious to know what is wrong, here. Aside from the fact that kudzu is for hardware detection and SELinux is not hardware, why is kudzu (in your opinion) is so "evil"?
All hyperbole aside, it is a userland tool which has the potential to affect policy with unintended consequences. I have seen it mess up hardware detection enough that I don't don't trust it.
While there is a need for a hardware detection tool for setting up a system, I don't believe it is something which needs to be run as a background daemon as RedHat has it set up. We have hotplug and friends for USB and those parts of the system designed to have components dynamically added and removed.
On Thu, 29 Apr 2004 18:36:41 MDT, "Lamont R. Peterson" lamont@gurulabs.com said:
That question asked, I have to say that I am inclined to think that as long as kudzu is around in a system with SELinux, we are going to have to accept the need for it (kudzu) to work withing that (SELinux) environment. I do not yet agree that there is need for kudzu to alter policies, but I am going to reserve judgment until after further discussion.
I can't convince myself that kudzu must be able to alter policy.
I can convince myself that if kudzu is running in an SELinux environment, and it creates a /dev entry, that it needs some way to make it end up labeled according to the policy in effect.
On the other hand, kudzu under SELinux *does* have a rather heavy taste of "Doctor, it hurts when I do that" "Don't do that then". After all, there is hotplug and friends....
On Wed, 2004-04-28 at 11:57 -0400, Daniel J Walsh wrote:
Andrew Farris wrote:
Playing a cd from the terminal using cdp, or cdplay (non-interactive), results in the following avc in permissive mode (but the cd is allowed to play):
Apr 26 15:09:24 CirithUngol kernel: audit(1083017364.035:0): avc: denied { ioctl } for pid=10129 exe=/usr/bin/cdp path=/dev/hdc dev=hdb8 ino=66203 scontext=user_u:user_r:user_t tcontext=system_u:object_r:fixed_disk_device_t tclass=blk_file
Please put in a bugzilla. The problem is that /dev/hdc is labeled wrong. It should have a label of removable_disk_device_t. The problem is there is currently no good way of determining what cdrom disk is from a fixed disk, from a policy point of view. We are investigating ideas around using kudzu to relabel the devices.
If you do a chcon -t removable_disk_device_t /dev/hdc does the problem go away?
Dan
I'm working with policy-sources-1.11.2-13.
Now working with policy-sources-1.11.2-18 and removable_disk_device_t is not a valid argument to chcon, however removable_device_t is, and when I relabel /dev/hdc such it does allow me to play the cd in enforcing mode, this is the solution. brw-rw-rw-+ root disk system_u:object_r:removable_device_t /dev/hdc
I will add this to bugzilla if not there already today.
On Wed, Apr 28, 2004 at 05:53:16PM -0700, Andrew Farris wrote:
From: Andrew Farris fedora@andrewfarris.com
Andrew Farris wrote:
Playing a cd from the terminal using cdp, or cdplay (non-interactive), results in the following avc in permissive mode (but the cd is allowed to play):
Apr 26 15:09:24 CirithUngol kernel: audit(1083017364.035:0): avc: denied { ioctl } for pid=10129 exe=/usr/bin/cdp path=/dev/hdc dev=hdb8 ino=66203 scontext=user_u:user_r:user_t tcontext=system_u:object_r:fixed_disk_device_t tclass=blk_file
Please put in a bugzilla. The problem is that /dev/hdc is labeled wrong.
this is the solution. brw-rw-rw-+ root disk system_u:object_r:removable_device_t /dev/hdc
I will add this to bugzilla if not there already today.
Should there be some distinctions for removable media eventually i.e "removable-rw-storage" or something reflecting a function.... USBflashstick, Floppy, iPod, tape, CDRW.
Match this with "removable-ro-storage" for things like music CDs, iPod or other content in a "roach motel environment" where stuff might check in but never check out ;-). In the the iPod case policy could enforce read only.
With hotplug hardware I can see disk controlers and other removable devices.
I know I am splitting a hair...
selinux@lists.fedoraproject.org
-
Andrew Farris -
Daniel J Walsh -
Lamont R. Peterson -
Thomas Molina -
Tom Mitchell -
Valdis.Kletnieks＠vt.edu