Messages in this thread | | | Subject | Re: PATCH: cdrecord: avoiding scsi device numbering for ide devices | From | Christer Weinigel <> | Date | 22 Aug 2004 19:18:57 +0200 |
| |
Joerg Schilling <schilling@fokus.fraunhofer.de> writes: > But in order to rip an audio CD, you need to use e.g. MODE SELECT. > If you start to distinct safe SCSI commands from possibly unsafe ones, then > MODE SELECT could not be in the list of safe ones.
Yes, I'm quite aware of that.
So a filter would have to be smarter than just checking the command codes. There would have to be a special case for the mode page commands which filters on accessible mode pages.
Are there any other commands that would need filtering at a finer grain than the command level?
Additionally, another thing that is really needed is to match the different variants of hdr->dxfer_direction against the direction of the commands, otherwise one could ask for a REQUEST_SENSE but with a direction of SG_DXFER_TO_DEV. This isn't a security problem in the sense that it can destroy the drive itself, but it might hang the IDE state machine in the kernel, motherboard or drive.
> > Not really, if I have write permisson to a CD burner, being able to > > burn a coaster by issuing strange commands is something I expect. > > Being able to destroy the firmware of the drive is not something I > > expect a normal user to be able to do. > > At SCSI level, there is no real difference.
SG_IO does not have to work at the SCSI level, it can filter the commands at a higher level.
> A powerful CD/DVD recording program needs to sometimes issue "secret" > and vendor unique SCSI commands in order to give nice features. > > On a Plextor drive, you need to be able to issue a vendor unique SCSI command > to know the recommended write speed for a specific medium. A SCSI command > from same list of vendor unique commands allows you to tell the drive to read > any medium at 52x. This could destroy the medium _and_ the drive. > > As you see: you cannot have the needed knowledge inside the kernel.
So guess why I suggested that the kernel should contain the mechanics to filter commands (and yes, I was aware of the mode page problems but didn't want to make a long mail even longer), and that the list of commands would be uploaded to the kernel from userspace. It was at the end of the mail you replied to...
That way an application, such as cdrecord, could keep a list of safe commands for each device and use the appropriate list for each kind of device. If the device is a tape, allow access to the mode page that can control BPI and compression settings. If it's a cdrom, allow access to the mode page with CDDA settings.
Of course, if it isn't possible to do this at a mode page level, maybe the access controls would have to be at the level of individual bits in a mode page, then it gets trickier. It might, or might not be feasible to implement such a filte. I don't know which is true or which is not, I'm just trying to look at ways of solving the problem.
> > 2. A Linux system should have as few suid root binaries as possible. > > If you like this completely, you would need to implement something RBAC and > getppriv(2)(setpiriv(2) on Solaris. If you have this, you have zero suid > root binaries on a 'Trusted OS' and one suid binary (/usr/bin/pfexec) on a non > Trusted system.
Which is not all that different from suid binaries. Instead of trusting an application, you're trusting a user or a role. This isn't much different from giving "trusted" users access to /dev/scd0.
> > As you said, since the old kernel behaviour is a gaping security hole, > > Linus had no other choice than to add a CAP_SYS_RAWIO check to the > > SG_IO call. This fulfills goal 1. Unfortunately it breaks just about > > Not true: a simple check like in my scg driver: > > /* > * Must have read/write access to /dev/scgxx > * to send commands over SCSI Bus. > */ > if ((flag&(FREAD|FWRITE)) != (FREAD|FWRITE)) > return (EACCES); > > was sudfficient.
No. Sure, you can redefine read access to a SCSI device to mean "may only use normal read" and write access to "may use read, write and send raw SCSI commands", but that is a rather bad fit to how read/write normally are used.
What do you do if you want to allow users with read access to read a SCSI tape (and to be able select the BPI)? With your suggestion, the user will need write access too, but I may just want to give the user read access.
> BTW: 'mt' should not need to send SCSI comands. THis shoul dbe handled via > specilized ioctls.
So why can't cdrecord use specialized ioctls then?
> With checking for ((flag&(FREAD|FWRITE)) != (FREAD|FWRITE)) less applications > would break.
cdrecord probably wouldn't break. Other applications that open /dev/scd0 as readonly would break. cdrecord isn't the only application in the world you know.
The Linux philosophy is "do it right". And when Linus has been changing interfaces he has said that he prefers something to break noisily (not compile) rather than to get compile fixes that leave the bugs still in there.
/Christer
-- "Just how much can I get away with and still go to heaven?"
Freelance consultant specializing in device driver programming for Linux Christer Weinigel <christer@weinigel.se> http://www.weinigel.se - 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/
| |