Messages in this thread | | | Subject | Re: SG_IO and security | From | Alan Cox <> | Date | Thu, 12 Aug 2004 21:16:44 +0100 |
| |
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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |