Weekly Edition
Return to the Kernel page
| |||||||||||||
2.6.8 and CD recording
By far the loudest chorus of complaints about the 2.6.8.1 kernel comes from
users who have found that they can no longer burn CDs. In most cases, the
problem can be worked around by running the recording program from a root
shell (setuid is not sufficient), but
that is an unsatisfying alternative for many. Why, ask inquiring minds,
did CD recording have to break with the new kernel?
It's all a matter of trying to get the permissions right. Burning a CD requires sending a number of special-purpose SCSI commands to the drive, so the operation is performed outside of the regular I/O paths. But once you can send arbitrary commands, you can do more than write CDs. In pushing for changes, Alan Cox put it this way:
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".
Seeing this outcome as undesirable, Linus threw in a patch shortly before releasing 2.6.8. This patch creates an array of known SCSI commands, associating each with "safe for read" and "safe for write" flags. Those flags are tested when a process attempts to execute the given command. If the device has been opened for read access, the set of allowed commands is relatively small: read, request sense, play CD, etc. A process with write access can execute more commands, but not the whole set. Any command not explicitly flagged as safe for the given open mode is restricted to processes with the CAP_SYS_RAWIO capability - root, for all practical purposes. This patch broke CD burning in multiple ways. Users of growisofs were burned (so to speak) because that utility opens the device for read access. That should never have worked, but did until now; fixing that problem will require a patch to the application. Beyond that, however, is the simple fact that numerous SCSI commands needed for CD burning were omitted from the "safe for write" list. These vary from locking the door to "send OPC," "blank", and many others. Enabling CD writing from an unprivileged process with write access to the drive will require adding several commands to the list. Unfortunately, expanding the list in that manner can bring back the original problem. Many commands which are safe to execute in one context can destroy data, firmware, or hardware in other contexts. And it can be very hard for the kernel to tell the difference between the two. There has been talk of expanding the checking framework to better understand the target device's operating modes and, perhaps, giving high- or low-level drivers a say in the decision. Down that road lies complexity, however, and it would be hard to reach a point where the developers could declare victory and call the problem solved. It may well be that, despite other faults in his reasoning on CD recording, Jörg Schilling got it right when he suggested that the most secure mode of operation is to simply restrict device access and run the CD recording application in a setuid mode. (Log in to post comments)
2.6.8 and CD recording Posted Aug 19, 2004 6:11 UTC (Thu) by pascal.martin (guest, #2995) [Link] There is something I don't understand regarding the CAP_SYS_RAWIO capability: does this gives access to all devices? can it be enabled device by device (or device type by device type?--such as CDROM writers).
In the defense industry you are granted access only to the information you need to know. Anything else is not granted, no matter what your clearance level is.
Should not that be the case for capabilities?
2.6.8 and CD recording Posted Aug 19, 2004 13:19 UTC (Thu) by fergal (subscriber, #602) [Link] The thing is that "capability" in the Linux kernel (POSIX capabilities?) does not mean the same thing as "capability" in the general computer science/OS research.
So yes, real capabilities would do what you're talking about and I think there may be SELinux modules which implement this sort of thing but it is not yet standard.
CAP_SYS_RAWIO Posted Aug 20, 2004 23:31 UTC (Fri) by giraffedata (subscriber, #1954) [Link] You have to be able to get a device file open in order to do raw I/O to it with CAP_SYS_RAWIO, but yes, the capability applies equally to all devices for which you can get a device file open. The read/write mode of the open is usually irrelevant.In the traditional Unix security model, instead of having a vast matrix of principle/privilege combinations designed into the kernel, you're expected to build the kind of security you're talking about with setuid programs and daemons on top of the kernel. I like it that way. I used to even like the only-one-capability model (uid 0/not uid 0), but the realities of system bugs have brought me around to liking the slightly more fine-grained capabilities we have now. In case it isn't obvious what kind of security I'm talking about: You don't give an interactive shell CAP_SYS_RAWIO, but rather give a program CAP_SYS_RAWIO and give principles permission to execute the program. The program should exploit the capability only to do very specific things, and might do some further permission checking, maybe based on which device you're accessing. Or, give a daemon process CAP_SYS_RAWIO and send it socket messages. The daemon authenticates you and does your bidding only against devices you are authorized to do raw I/O to.
2.6.8 and CD recording Posted Aug 19, 2004 6:58 UTC (Thu) by evgeny (guest, #774) [Link] Hmm.the problem can be worked around by running the recording program from a root shell (setuid is not sufficient) and then Jörg Schilling got it right when he suggested that the most secure mode of operation is to simply restrict device access and run the CD recording application in a setuid mode. So does setuid help or it doesn't?
2.6.8 and CD recording Posted Aug 19, 2004 8:15 UTC (Thu) by dvrabel (guest, #9500) [Link] cdrecord only uses root priviledges for setting real-time scheduling and locking memory. It drops them after that so it does the burning as a regular user.
2.6.8 and CD recording Posted Aug 24, 2004 11:39 UTC (Tue) by mwilck (guest, #1966) [Link] What about the special commands ("send OPC", "blank", etc.) mentioned in the text? According to the article, these should fail if they are executed with user priviliges.
2.6.8 and CD recording Posted Aug 24, 2004 11:37 UTC (Tue) by mwilck (guest, #1966) [Link] I can't imagine why a root shell should be necessary. Perhaps the burner executable needs to make a setuid() call to set the real uid to the effective uid.
2.6.8 uses SCSI for CD recording? Posted Aug 19, 2004 10:15 UTC (Thu) by sdalley (subscriber, #18550) [Link] > Burning a CD requires sending a number of> special-purpose SCSI commands to the drive, > so the operation is performed outside of the regular I/O paths
I always scratch my head when I read things like this. Most CD/DVD writers are not SCSI devices these days. USB devices, too are not SCSI devices. Yet very often it turns out that in Linux anyway, these devices depend intimately on the kernel SCSI subsystem and end up with /dev/sd sorts of names. In 2.4 this was a convenient hack. Are there any pointers to how this is being tidied up in the brave new wold of 2.6? Or is the scsi subsystem still doubling up as a convenient generic block device service?
2.6.8 uses SCSI for CD recording? Posted Aug 19, 2004 11:02 UTC (Thu) by rjw (guest, #10415) [Link] Most hardware storage devices (Firewire, USB, SATA, PATA) do in fact work in terms of scsi commands (or very minor variations) internally.
We have a SCSI layer. We use it for these SCSI based devices whether they use a SCSI cable standard or not.
As SCSI is so universal, it is becoming pointless to name device nodes like that. So eg IDE cdwriters can just be opened as /dev/hdc or whatever, and scsi commands issued. This is AFAIK possible in 2.6.
I'm sure patches that cleared up device naming in other encapuslated SCSI situations would be accepted ( eg SBP2, libata).
The problem here is that the SCSI standards (and all these encapsulated-SCSI standards) have not really fully encompassed the full range of what the devices are capable of. So its very hard to tell how much damage any particular command can do, as it might do different things
For existing drives, this becomes very similar to the X security question. Graphics cards often have total DMA freedom. So we have a few choices:
c) is what they are doing here. b) is what X does currently, but moving to c) (with quite some pain) . But if the commands are totally arbitrary, maybe userspace setup using a trusted udev/hotplug/hal callout (which informs the kernel of an allowed set of commands) would be the best way of dealing with it. Any extra userspace is always ultra painful to get in the distros though.
2.6.8 uses SCSI for CD recording? Posted Aug 19, 2004 11:41 UTC (Thu) by sdalley (subscriber, #18550) [Link] Ahh, that's a bit clearer. It's logical SCSI, not physical SCSI. Device commands are conveniently defined in terms of logical SCSI operations, even though they don't go near a physical SCSI device driver or device.
That being the case, maybe a new name for this logical layer could be invented.
2.6.8 uses SCSI for CD recording? Posted Aug 19, 2004 15:48 UTC (Thu) by rjw (guest, #10415) [Link] Well, it is actually SCSI commands that are being sent. Not some abstraction around a different command set.
That is because the *device manufacturers* are using SCSI commands.
So it would just be stupid to make up a new name, and pretend that the SCSI commands are something else.
SCSI means two things : a) A set of somewhat related controller / cable / plug standards b) a set of commands for storage ( and a few other ) devices.
b) can be used without a), but a) is very rarely used without b).
It has gone this long without a name split. I don't see why it should be changed now.
Filtering and white-lists Posted Aug 19, 2004 13:13 UTC (Thu) by brugolsky (subscriber, #28) [Link] A practical concern with any type of white-listing is that the list goes out of date and creates upgrade dependencies. If the kernel is going down that path, it would be preferable if there were a mechanism for dynamically updating the list, as with the dynamic PCI id table.
Filtering and white-lists Posted Aug 19, 2004 18:18 UTC (Thu) by bronson (subscriber, #4806) [Link] Erm, given any thought to security? PCI IDs don't really have security implications. Given its scope, SCSI command white listing is absolutely littered with them. I don't think you want to stir dynamic update into that already seething pot...
2.6.8 and CD recording Posted Aug 19, 2004 19:13 UTC (Thu) by X-Nc (guest, #1661) [Link] FWLIW, when this happened to me on FC2 I just started running my burncd script under sudo. But, since I do all this kind of stuff from the command line in an xterm, it's not much help for users of GUI tools (other than for them to change the actual target, prepending sudo onto it).
<USELESS SIDE NOTE>
2.6.8 and CD recording Posted Aug 26, 2004 7:16 UTC (Thu) by pete_s (guest, #24269) [Link] Uhm.. This not only affects CD burning but also CD ripping when using CD-RW drives. At least cdparanoia now only runs with root priviliges using my SCSI burner. Setting it suid root does work, but this is no solution for e.g. "Grip" because any GTK+ application does stop working if suid root ("This process is currently running setuid or setgid. This is not a supported use of GTK+."). Doh.
2.6.8 and CD recording Posted Nov 25, 2004 18:22 UTC (Thu) by D-tune (guest, #26254) [Link] Has anyone noticed that scanning doesn't work for users either?Even though the hotplug scripts are setting the correct device permissions in /proc/bus/usb it only works for root. I do most things from the command line so I can work around it with sudo, but every CD burning or scanning program that accesses the devices needs a separate entry. I guess anything that uses the scsi subsystem is similarly affected - my sudoers file is growing rapidly:(
2.6.8 and CD recording Posted Nov 25, 2004 21:39 UTC (Thu) by D-tune (guest, #26254) [Link] Retract that last post. Forgot to add user to scanner group. Duh!BTW new version of cdrecord (I'm using 2.0+a38-1 from Debian Unstable) allows users to burn CDs if suid root.
2.6.8 and CD recording Posted Dec 8, 2004 10:03 UTC (Wed) by synan (guest, #26522) [Link] Did this thing get fixed already or is it still a problem?
I am using 2.6.8.1 and have some strange problems with my dvd-rw (can burn cds=no, can burn cd/rw=yes =) and have stumblead upon this post. I wouldnt like going to 2.6.9 for now, nvidia is broken there, but am interested if burning works under 2.6.9 or what exactly am i supposed to do to get it working while not being root?
2.6.8 and CD recording Posted Feb 18, 2005 1:10 UTC (Fri) by Greg (guest, #27962) [Link] The same problems exist for 2.6.9 as the rest of the series.
Patches do exist for the NVidia binary driver(6629) that allow it to work properly in linux 2.6.9. I am currently running 2.6.10-ac12 with the NVidia driver.
2.6.8 and CD recording Posted Feb 18, 2005 1:07 UTC (Fri) by Greg (guest, #27962) [Link] Well this is all good, but is anybody developing burning software that uses the ide commands. If I understand correctly, the use of an abstraction layer instead of using actual ide commands is also a major factor in the decision.
|
|||||||||||||