Access to cd device denied for cdp

[Andrew Farris]

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, CPE senior (California Polytechnic State University, SLO)
fedora(a)andrewfarris.com :: lmorgul on irc.freenode.net
"The only thing necessary for the triumph of evil is for good men
to do nothing." (Edmond Burke)

[Daniel J Walsh]

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.
>   
>

[Thomas Molina]

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.

[Lamont R. Peterson]

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.
-- 
Lamont R. Peterson <lamont(a)gurulabs.com&gt;
Senior Instructor
Guru Labs, L.C. http://www.GuruLabs.com/

[Thomas Molina]

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(a)gurulabs.com&gt;  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....

[Andrew Farris]

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.

-- 
Andrew Farris, CPE senior (California Polytechnic State University, SLO)
fedora(a)andrewfarris.com :: lmorgul on irc.freenode.net
"The only thing necessary for the triumph of evil is for good men
to do nothing." (Edmond Burke)

[Tom Mitchell]

On Wed, Apr 28, 2004 at 05:53:16PM -0700, Andrew Farris wrote:
>  From: Andrew Farris <fedora(a)andrewfarris.com&gt;
>  > 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... 


-- 
	T o m  M i t c h e l l 
	/dev/null the ultimate in secure storage.