Diamond Rio 500 and other device nodes

Diamond Rio 500 and other device nodes

[Russell Coker]

What do you think is the correct type for the device node for the "Diamond Rio 
500" (/dev/usb/rio500)?

It's a portable MP3 player and storage device with a USB interface, so I think 
that removable_device_t is appropriate, in concept it's similar to a floppy 
disk drive.

Also I've used scanner_device_t for USB digital cameras, I think of a camera 
as a portable scanner.  ;)  But I guess a case could be made for considering 
digital cameras to be removable storage.


I have been considering whether I should merge the v4l_device_t device nodes 
with those for scanners.  However I think that although the concept is the 
same the likely use is different.  Having one program to use v4l to control a 
security system while another program acts as a scanner server is likely, 
while it's likely that a program which is authorised for accessing a scanner 
will also be authorised for digital cameras.

-- 
http://www.coker.com.au/selinux/   My NSA Security Enhanced Linux packages
http://www.coker.com.au/bonnie++/  Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/    Postal SMTP/POP benchmark
http://www.coker.com.au/~russell/  My home page


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: Diamond Rio 500 and other device nodes

[Diyab]

Russell Coker wrote:

> What do you think is the correct type for the device node for the "Diamond Rio 
> 500" (/dev/usb/rio500)?
> 
> It's a portable MP3 player and storage device with a USB interface, so I think 
> that removable_device_t is appropriate, in concept it's similar to a floppy 
> disk drive.
> 
> Also I've used scanner_device_t for USB digital cameras, I think of a camera 
> as a portable scanner.  ;)  But I guess a case could be made for considering 
> digital cameras to be removable storage.
> 
> 
> I have been considering whether I should merge the v4l_device_t device nodes 
> with those for scanners.  However I think that although the concept is the 
> same the likely use is different.  Having one program to use v4l to control a 
> security system while another program acts as a scanner server is likely, 
> while it's likely that a program which is authorised for accessing a scanner 
> will also be authorised for digital cameras.
> 

Just curious, but how will the files on the device be labeled once the 
device is mounted?  For example if I plug in my digital camera and mount 
it so that I can copy the pictures from it am I going to have access to 
read the files?  Will I even be able to mount it as a normal user?  Is 
this going to be a problem since we can't label the device filesystem?

Timothy,

-- 
I put instant coffee in a microwave and almost went back in time.
		-- Steven Wright


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: Diamond Rio 500 and other device nodes

[Russell Coker]

On Thu, 30 Oct 2003 14:58, Diyab wrote:
> Russell Coker wrote:
> > What do you think is the correct type for the device node for the
> > "Diamond Rio 500" (/dev/usb/rio500)?
> >
> > It's a portable MP3 player and storage device with a USB interface, so I
> > think that removable_device_t is appropriate, in concept it's similar to
> > a floppy disk drive.
>
> Just curious, but how will the files on the device be labeled once the
> device is mounted?  For example if I plug in my digital camera and mount
> it so that I can copy the pictures from it am I going to have access to
> read the files?  Will I even be able to mount it as a normal user?  Is
> this going to be a problem since we can't label the device filesystem?

I don't anticipate any need for things to operate differently to floppy disks.

Device nodes for floppy disks don't change type when they are mounted.

However there is a more important issue, we can't allow anyone other than an 
administrator to mount a ext3 file system from a floppy disk or other 
removable media.  If we do then it would be trivial to create a file system 
with a file of type newrole_exec_t and take over the system.

Steve, any ideas on how to solve this?

-- 
http://www.coker.com.au/selinux/   My NSA Security Enhanced Linux packages
http://www.coker.com.au/bonnie++/  Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/    Postal SMTP/POP benchmark
http://www.coker.com.au/~russell/  My home page


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: Diamond Rio 500 and other device nodes

[Stephen Smalley]

On Thu, 2003-10-30 at 09:33, Russell Coker wrote:
> However there is a more important issue, we can't allow anyone other than an 
> administrator to mount a ext3 file system from a floppy disk or other 
> removable media.  If we do then it would be trivial to create a file system 
> with a file of type newrole_exec_t and take over the system.
> 
> Steve, any ideas on how to solve this?

Just to clarify, subverting newrole isn't fatal to security, as newrole
can only change to roles for which you are authorized in the policy, and
that is enforced by the kernel.  newrole is _not_ like su.

To answer your question, at the suggestion of James Morris, we
overloaded the nosuid mount option back in July to also prohibit domain
transitions on programs in the filesystem.  Hence, if you mount with
nosuid, it won't matter whether any programs on the filesystem are
labeled with an entrypoint type.

However, that isn't a full solution to the general problem, as you
really want to be able to constrain the set of security contexts that
can exist on files in a given filesystem.  Likely requires changes to
mount(8) as well as the kernel and new mount options to support such
functionality.  Simplest implementation is to just allow a single
context to be applied to an entire filesystem via a mount option,
similar to the existing uid= and gid= options.

-- 
Stephen Smalley <sds@epoch.ncsc.mil>
National Security Agency


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: Diamond Rio 500 and other device nodes

[Russell Coker]

On Fri, 31 Oct 2003 03:02, Stephen Smalley wrote:
> On Thu, 2003-10-30 at 09:33, Russell Coker wrote:
> > However there is a more important issue, we can't allow anyone other than
> > an administrator to mount a ext3 file system from a floppy disk or other
> > removable media.  If we do then it would be trivial to create a file
> > system with a file of type newrole_exec_t and take over the system.
> >
> > Steve, any ideas on how to solve this?
>
> Just to clarify, subverting newrole isn't fatal to security, as newrole
> can only change to roles for which you are authorized in the policy, and
> that is enforced by the kernel.  newrole is _not_ like su.

True.

However currently newrole has permissions to read /etc/shadow...

I can probably change this now as with the latest PAM changes newrole should 
only need auth_chkpwd not auth.

> To answer your question, at the suggestion of James Morris, we
> overloaded the nosuid mount option back in July to also prohibit domain
> transitions on programs in the filesystem.  Hence, if you mount with
> nosuid, it won't matter whether any programs on the filesystem are
> labeled with an entrypoint type.

Great.  This just leaves the issue of symlink race-condition attacks to try 
and trick sysadm_t into running a file that you label as bin_t, so I guess 
that noexec is needed for full protection.  But the modified nosuid should 
cover 99% of the problems.

> However, that isn't a full solution to the general problem, as you
> really want to be able to constrain the set of security contexts that
> can exist on files in a given filesystem.  Likely requires changes to
> mount(8) as well as the kernel and new mount options to support such
> functionality.  Simplest implementation is to just allow a single
> context to be applied to an entire filesystem via a mount option,
> similar to the existing uid= and gid= options.

This would solve some of the issues we discussed recently regarding /boot...

-- 
http://www.coker.com.au/selinux/   My NSA Security Enhanced Linux packages
http://www.coker.com.au/bonnie++/  Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/    Postal SMTP/POP benchmark
http://www.coker.com.au/~russell/  My home page


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.