Re: SG_IO and security

From: Bill Davidsen
Date: Mon Aug 16 2004 - 17:01:42 EST


Linus Torvalds wrote:

On Thu, 12 Aug 2004, Jeff Garzik wrote:

Linus Torvalds wrote:

On Thu, 12 Aug 2004, Linus Torvalds wrote:


Hmm.. This still allows the old "junk" commands (SCSI_IOCTL_SEND_COMMAND).


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.

Define raw commands. I certainly don't want non-root users to be able to issue FORMAT UNIT on my hard drive.


Ehh? The same ones you allow to write all over the raw device?

Let's see now:

brw-rw---- 1 root disk 3, 0 Jan 30 2003 /dev/hda

would you put people you don't trust with your disk in the "disk" group?

Right. If you trust somebody enough that you give him write access to the disk, then you might as well trust him enough to do commands on it.

Conversely, if you don't trust him enough to do things like that, you shouldn't give him write access in the first place.

It's a hell of a lot easier to destroy a disk with

dd if=/dev/zero of=/dev/xxx bs=8k

than it is to do it with some special malicious command.

And yes, there's clearly a difference, but in general I'd say it is the _data_ on the disk that is worth something to you. The disk itself? Do you really fundamentally care?

I will offer two cases which is not wildly improbable. User complains the CD burner will {burn faster, burn brand X media, write HD mode} if the firmware is upgraded. User has write to burn CDs, decides to flash the firmware herself, turns CD into paperweight. Or possibly user tries to install CD firmware on a disk drive.

Case two, user is DBA, has write on raw partitions for Oracle, can mangle the whole device, and through some stupidity does.

--
-bill davidsen (davidsen@xxxxxxx)
"The secret to procrastination is to put things off until the
last possible moment - but no longer" -me
-
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/