Re: SG_IO and security

[Alan Cox]

On Iau, 2004-08-12 at 17:45, Linus Torvalds wrote:
> On Thu, 12 Aug 2004, Linus Torvalds wrote:
> > 
> > Hmm.. This still allows the old "junk" commands (SCSI_IOCTL_SEND_COMMAND).

That uses sg_io() so gets caught as well unless I screwed up following
the code paths.

> Btw, I think the _right_ thing to check is the write access of the file 
> descriptor. If you have write access to a block device, you can delete the 
> data, so you might as well be able to do the raw commands. And that would 
> allow things like "disk" groups etc to work and burn CD's.

With the current code I can destroy all your hard disks given read
access to the drive. With checks on writable I can destroy all your hard
disks/cdroms as appropriate with write access.

Destroy here means "dead, defunct, pushing up the daisies, go order
a new one kind of dead".

In essence the interface (and the SCSI/ATA/.. layers below) don't
seperate media and device. This also kicks in for partitioning since
write access to /dev/hda1 giving me SG_IO scsi access doesn't enforce
partitioning.

We end up needing some notion of what commands should be allowed to any
user and what commands should be allowed solely to superusers. That
leads to a second question for you which is one I had an argument about
Jens on.

Do we

a) Have code that essentially says "if read on base device can do ....,
if write can do ... , else capable(...)"

b) ioctls/other command functionality for the stuff users should be
allowed to do. 

Option (a) means parsing command blocks which are pretty regular and
parseable. 

Alan

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/