Re: cdrecord and newer Linux kernels
On Wed, Nov 16, 2005 at 12:39:03PM +0900, Horms wrote: In article [EMAIL PROTECTED] you wrote: That does make it rather difficult to have any safe CD/DVD writing software - do you think it's a good idea to have end users run apps as root to burn CDs? I've read too much of the cdrecord source to be happy running that as root! :-) My thought is that it might be better to allow specific commands on specific drives, and let the local admin configure that for themselves... The whole problem is that some IOCTLS are not safe. And there is no definitive list of IOCTLs, so safe ones are added as they are known. And the others are disabled. If you have discovered ioctls which are indeed safe, then they should be added to the whitelist. As for allowing root to have a mechanism to allow users to access arbitary (unsafe) ioctls, that sounds like a can of worms to me. I have CCed the SCSI maintainers for comment. For their reference, your original post and patch, allong with the rest of this thread is at: http://lists.debian.org/debian-kernel/2005/11/msg00748.html Again, I understand why the checks were added to the kernel. Adding access controls to limit the damage that could be caused by non-root users is entirely a good plan! The reason I'm looking into this is that there are some commands that may be dangerous on some devices but on others harmless / useful / required (even); several years of writing SCSI-based storage management software has show me that. :-) Allowing a mechanism for an admin to override the in-kernel policy on a per-device, per-command basis could allow us to safely allow non-root CD/DVD burning, I hope. -- Steve McIntyre, Cambridge, UK.[EMAIL PROTECTED] Google-bait: Debian does NOT ship free CDs. Please do NOT contact the mailing lists asking us to send them to you. signature.asc Description: Digital signature
Re: cdrecord and newer Linux kernels
Steve McIntyre wrote: On Wed, Nov 16, 2005 at 12:39:03PM +0900, Horms wrote: In article [EMAIL PROTECTED] you wrote: That does make it rather difficult to have any safe CD/DVD writing software - do you think it's a good idea to have end users run apps as root to burn CDs? I've read too much of the cdrecord source to be happy running that as root! :-) My thought is that it might be better to allow specific commands on specific drives, and let the local admin configure that for themselves... The whole problem is that some IOCTLS are not safe. And there is no definitive list of IOCTLs, so safe ones are added as they are known. And the others are disabled. If you have discovered ioctls which are indeed safe, then they should be added to the whitelist. As for allowing root to have a mechanism to allow users to access arbitary (unsafe) ioctls, that sounds like a can of worms to me. I have CCed the SCSI maintainers for comment. For their reference, your original post and patch, allong with the rest of this thread is at: http://lists.debian.org/debian-kernel/2005/11/msg00748.html Again, I understand why the checks were added to the kernel. Adding access controls to limit the damage that could be caused by non-root users is entirely a good plan! The reason I'm looking into this is that there are some commands that may be dangerous on some devices but on others harmless / useful / required (even); several years of writing SCSI-based storage management software has show me that. :-) Allowing a mechanism for an admin to override the in-kernel policy on a per-device, per-command basis could allow us to safely allow non-root CD/DVD burning, I hope. Wouldn't per-user, per_device override be sufficient? So if the user has CAP_SYS_RAWIO or owns the device node (and has write permission) then they can do as they please. The only reason for adding per-command IMO would be if a command could cause collateral damage to other devices sharing the same transport. A user needs read permissions on a device node to open it and call an ioctl. If a user can format media via such an ioctl, then at least write permissions should be required on the format operation. I find the root only policy (CAP_SYS_RAWIO) for unknown opcodes in the block SG_IO ioctl a little overbearing. Take CD/DVD burners: most distribution GUIs give that user ownership and read write permissions on that device node. This is to facilitate that GUI user burning CD/DVDs with tools like cdrecord or k3b. It will only take one vendor specific command or a new SCSI command from the emerging MMC-5 draft (for HD and Blue ray DVDs) to break the current scheme. OTOH disk devices typically have root ownership with no permissions granted to the GUI user (which seems reasonable). In larger environments, when there are multiple different GUI users, then it makes sense to give only one user (or root) ownership and write permissions to a specific CD/DVD drive. The SCSI cdb opcode decoding used by linux is also pretty crude as it takes no account of the peripheral device type (e.g. whether the device is a disk or a DVD drive). The current filtering is heavily skewed towards the Multi-Media Command (MMC) set used by CD and DVDs. Since the SCSI Block command (SBC) set used by disks overlaps with the MMC set in many opcodes, this filtering scheme is not as tight as some may think. The st driver (which assumes the streaming command (SSC) set) overcomes this command set overlap, and potential interference with its state machines, by requiring that all block layer SG_IO ioctl access needs CAP_SYS_RAWIO. Sending non-SCSI command sets, or tunnelling them (e.g. ATA via the SCSI ATA PASSTHROUGH commands) to the SG_IO ioctl, creates more filtering headaches. The sg driver has been playing this filtering game for some time. It only permits read-only access to mostly well known SCSI Primary Commands (SPC) with a few exceptions (e.g. READ CAPACITY). The only time the sg driver requires root permissions (CAP_SYS_RAWIO) is an action that may cause collateral damage. The prime example of that is a bus reset. There is a finer tuned SCSI task management function to reset a logical unit and I'm sure the author of cdrecord would like access to that reset for a user who owns the device. [Linux is still fuzzy in the differentiation between a target reset (which would potentially reset all logical units within that target) and a logical unit reset.] For further information about the SG_IO ioctl see: http://www.torque.net/sg/sg_io.html with per-command permissions shown in table 3. My favourite is the START_STOP_UNIT command which is defined both for MMC (e.g. DVD drive) and SBC (e.g. a disk). The block layer SG_IO ioctl allows this command to be sent with only read permissions ( open(,O_RDONLY) ). Now while the stop variant of that command is relatively harmless on a DVD drive (e.g. it will delay the next data access), it is not a good idea to send it to a mounted SCSI
Re: cdrecord and newer Linux kernels
In article [EMAIL PROTECTED] you wrote: [-- text/plain, encoding quoted-printable, charset: us-ascii, 33 lines --] [ Bugger, got the cdrtools-devel address wrong on the first mail. Now fixed. ] On Fri, Nov 11, 2005 at 12:53:00AM +0100, Christoph Hellwig wrote: On Thu, Nov 10, 2005 at 11:47:29PM +, Steve McIntyre wrote: In kernel 2.6.8 and later, SCSI generic commands are verified for safety. This may be a reasonable measure in some respects, but it makes effective non-root CD/DVD burning rather difficult. For best performance cdrecord, growisofs and friends may often need to send SCSI commands to drives that the kernel may neither know about nor understand. And (to add to the pain) these commands are very often vendor- or device-specific, so simply allowing those commands in the kernel will defeat the point of the verification in the first place. The whole point of the verification is to allow safe access to a selected set of raw commands for normal users. root (or rather a process that has CAP_SYS_RAWIO) can send any command. if you need unknown commands just make sure to burn as root, as everything else would be unsafe anyway. That does make it rather difficult to have any safe CD/DVD writing software - do you think it's a good idea to have end users run apps as root to burn CDs? I've read too much of the cdrecord source to be happy running that as root! :-) My thought is that it might be better to allow specific commands on specific drives, and let the local admin configure that for themselves... The whole problem is that some IOCTLS are not safe. And there is no definitive list of IOCTLs, so safe ones are added as they are known. And the others are disabled. If you have discovered ioctls which are indeed safe, then they should be added to the whitelist. As for allowing root to have a mechanism to allow users to access arbitary (unsafe) ioctls, that sounds like a can of worms to me. I have CCed the SCSI maintainers for comment. For their reference, your original post and patch, allong with the rest of this thread is at: http://lists.debian.org/debian-kernel/2005/11/msg00748.html -- Horms -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: cdrecord and newer Linux kernels
On Thu, Nov 10, 2005 at 11:47:29PM +, Steve McIntyre wrote: In kernel 2.6.8 and later, SCSI generic commands are verified for safety. This may be a reasonable measure in some respects, but it makes effective non-root CD/DVD burning rather difficult. For best performance cdrecord, growisofs and friends may often need to send SCSI commands to drives that the kernel may neither know about nor understand. And (to add to the pain) these commands are very often vendor- or device-specific, so simply allowing those commands in the kernel will defeat the point of the verification in the first place. The whole point of the verification is to allow safe access to a selected set of raw commands for normal users. root (or rather a process that has CAP_SYS_RAWIO) can send any command. if you need unknown commands just make sure to burn as root, as everything else would be unsafe anyway. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: cdrecord and newer Linux kernels
[ Bugger, got the cdrtools-devel address wrong on the first mail. Now fixed. ] On Fri, Nov 11, 2005 at 12:53:00AM +0100, Christoph Hellwig wrote: On Thu, Nov 10, 2005 at 11:47:29PM +, Steve McIntyre wrote: In kernel 2.6.8 and later, SCSI generic commands are verified for safety. This may be a reasonable measure in some respects, but it makes effective non-root CD/DVD burning rather difficult. For best performance cdrecord, growisofs and friends may often need to send SCSI commands to drives that the kernel may neither know about nor understand. And (to add to the pain) these commands are very often vendor- or device-specific, so simply allowing those commands in the kernel will defeat the point of the verification in the first place. The whole point of the verification is to allow safe access to a selected set of raw commands for normal users. root (or rather a process that has CAP_SYS_RAWIO) can send any command. if you need unknown commands just make sure to burn as root, as everything else would be unsafe anyway. That does make it rather difficult to have any safe CD/DVD writing software - do you think it's a good idea to have end users run apps as root to burn CDs? I've read too much of the cdrecord source to be happy running that as root! :-) My thought is that it might be better to allow specific commands on specific drives, and let the local admin configure that for themselves... -- Steve McIntyre, Cambridge, UK.[EMAIL PROTECTED] Can't keep my eyes from the circling sky, Tongue-tied twisted, Just an earth-bound misfit, I... signature.asc Description: Digital signature
