ide-cd problems

I'm going to bump this topic a bit, since it's been a while.. There are still some issues with ide-cd's SG_IO, listed from most important as percieved by me to least:

* Read-only access grants you the ability to write/blank media in the drive
* (with above) You can open the device only in read-only mode.

* You can't open the device unless there is media in the drive

* Still seems to be no way to specify scatter gather/dma buffers yourself, though I'm not entirely sure that matters anyway.

Quoted 6 lines · Zinx Verituse

I'm going to bump this topic a bit, since it's been a while.. There are still some issues with ide-cd's SG_IO, listed from most important as percieved by me to least:

* Read-only access grants you the ability to write/blank media in the drive
* (with above) You can open the device only in read-only mode.

That's by design. Search linux-scsi or this list for why that is so.

Quoted 2 lines

* You can't open the device unless there is media in the drive

False, you use O_NONBLOCK.

Signature · 2 lines

-- 
Jens Axboe

Quoted 9 lines · Jens Axboe

Quoted 6 lines · Zinx Verituse

I'm going to bump this topic a bit, since it's been a while.. There are still some issues with ide-cd's SG_IO, listed from most important as percieved by me to least:

* Read-only access grants you the ability to write/blank media in the drive
* (with above) You can open the device only in read-only mode.

That's by design. Search linux-scsi or this list for why that is so.

The only thing I can find on the linux-scsi list is refering to sg devices, which are on a different device node from the non-generic device. This means you can still allow users read access to the disk without allowing them to send random commands to the disk -- this isn't currently possible with the IDE interface, since the device with generic access is the same as the one with the original read/cdrom commands access.

As it is, it's impossible grant users read-only access to an IDE cd-rom without allowing them to do things like replacing the firmware with a malicious/non-working one.

Generic access allowing such things is fine; but only if we can grant non-generic access without granting generic access.

Quoted 19 lines · Zinx Verituse

Quoted 9 lines · Jens Axboe

Quoted 6 lines · Zinx Verituse

I'm going to bump this topic a bit, since it's been a while.. There are still some issues with ide-cd's SG_IO, listed from most important as percieved by me to least:

* Read-only access grants you the ability to write/blank media in the drive
* (with above) You can open the device only in read-only mode.

That's by design. Search linux-scsi or this list for why that is so.

The only thing I can find on the linux-scsi list is refering to sg devices, which are on a different device node from the non-generic device. This means you can still allow users read access to the disk without allowing them to send random commands to the disk -- this isn't currently possible with the IDE interface, since the device with generic access is the same as the one with the original read/cdrom commands access.

Quoted 6 lines

As it is, it's impossible grant users read-only access to an IDE cd-rom without allowing them to do things like replacing the firmware with a malicious/non-working one.

Generic access allowing such things is fine; but only if we can grant non-generic access without granting generic access.

If you want it to work that way, you have the have a pass-through filter in the kernel knowing what commands are out there (including vendor specific ones). That's just too ugly and not really doable or maintainable, sorry.

If you have access to issue ioctls to the device, you have access to send it arbitrary commands - period.

I don't believe command filtering is neccessary, since all of the ide-cd ioctls are still there (ioctls that allow playing, reading, etc) Only the SG_IO ioctl itself would have to be checked (i.e., not each individual command available with SG_IO, just the overall ioctl itself, categorizing all of SG_IO more or less as raw IO. If this isn't doable with the current design, then the ide-cd interface should at least be very conspicuously documented as being extremely insecure as far as "read" access is concerned, as I know I wouldn't expect users to be able to overwrite my drive's firmware simply by granting the read access.

Quoted 10 lines · Zinx Verituse

I don't believe command filtering is neccessary, since all of the ide-cd ioctls are still there (ioctls that allow playing, reading, etc) Only the SG_IO ioctl itself would have to be checked (i.e., not each individual command available with SG_IO, just the overall ioctl itself, categorizing all of SG_IO more or less as raw IO. If this isn't doable with the current design, then the ide-cd interface should at least be very conspicuously documented as being extremely insecure as far as "read" access is concerned, as I know I wouldn't expect users to be able to overwrite my drive's firmware simply by granting the read access.

Remember that it is still possible to write CDs through ide-cd in 2.4.x using some pre-alpha code in cdrecord:

cdrecord dev=ATAPI:1,1,0 image.iso

On Sun, Aug 01 2004, Alexander E. Patrakov wrote:

Quoted 4 lines

Remember that it is still possible to write CDs through ide-cd in 2.4.x using some pre-alpha code in cdrecord:

cdrecord dev=ATAPI:1,1,0 image.iso

Don't ever use that interface, period.

It's not just the cdrecord code
that may be alpha (I doubt it matters, it's easy to use), the interface it uses is not worth the lines of code it occupies.

Quoted 1 line · Jens Axboe

On Sun, Aug 01 2004, Alexander E. Patrakov wrote:

[...]

Quoted 3 lines

Quoted 3 lines

Remember that it is still possible to write CDs through ide-cd in 2.4.x using some pre-alpha code in cdrecord:

Quoted 1 line

Quoted 1 line

cdrecord dev=ATAPI:1,1,0 image.iso

[...]

Quoted 1 line

Don't ever use that interface, period.

Great! So I won't be able to use any of the CD burners I have now.

Quoted 3 lines

It's not just the cdrecord code
that may be alpha (I doubt it matters, it's easy to use), the interface it uses is not worth the lines of code it occupies.

What do you suggest then? ide-scsi is gone, so AFAIK this is the only way to burn CDs right now on 2.6.x

Quoted 15 lines · Alexander E. Patrakov

Quoted 10 lines · Zinx Verituse

I don't believe command filtering is neccessary, since all of the ide-cd ioctls are still there (ioctls that allow playing, reading, etc) Only the SG_IO ioctl itself would have to be checked (i.e., not each individual command available with SG_IO, just the overall ioctl itself, categorizing all of SG_IO more or less as raw IO. If this isn't doable with the current design, then the ide-cd interface should at least be very conspicuously documented as being extremely insecure as far as "read" access is concerned, as I know I wouldn't expect users to be able to overwrite my drive's firmware simply by granting the read access.

Remember that it is still possible to write CDs through ide-cd in 2.4.x using some pre-alpha code in cdrecord:

Quoted 1 line

cdrecord dev=ATAPI:1,1,0 image.iso

(don't trim cc lists on linux-kernel!)

Don't ever use that interface, period. It's not just the cdrecord code that may be alpha (I doubt it matters, it's easy to use), the interface it uses is not worth the lines of code it occupies.

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Quoted 16 lines · Jens Axboe

Quoted 15 lines · Alexander E. Patrakov

Quoted 10 lines · Zinx Verituse

I don't believe command filtering is neccessary, since all of the ide-cd ioctls are still there (ioctls that allow playing, reading, etc) Only the SG_IO ioctl itself would have to be checked (i.e., not each individual command available with SG_IO, just the overall ioctl itself, categorizing all of SG_IO more or less as raw IO. If this isn't doable with the current design, then the ide-cd interface should at least be very conspicuously documented as being extremely insecure as far as "read" access is concerned, as I know I wouldn't expect users to be able to overwrite my drive's firmware simply by granting the read access.

Remember that it is still possible to write CDs through ide-cd in 2.4.x using some pre-alpha code in cdrecord:

Quoted 7 lines

Quoted 1 line

cdrecord dev=ATAPI:1,1,0 image.iso

(don't trim cc lists on linux-kernel!)

Don't ever use that interface, period. It's not just the cdrecord code that may be alpha (I doubt it matters, it's easy to use), the interface it uses is not worth the lines of code it occupies.

Then we have a severe disagreement between the cdrecord code (or at
least the runtime warnings) and the Linux-Kernel IDE folks. specifically, these lines, while running with cdrecord dev=/dev/cdrom

scsidev: '/dev/cdrom'
devname: '/dev/cdrom'
scsibus: -2 target: -2 lun: -2
Warning: Open by 'devname' is unintentional and not supported.

I've attached two logs, one using the ATAPI interface, one using your suggested interface. Frankly, both have rather nasty warnings on them, and one gets to wondering what the cdrecord authors want...

Maybe we should be cc:ing the authors of cdrecord as well?

devname: 'ATAPI'
scsibus: 0 target: 0 lun: 0
Warning: Using ATA Packet interface.
Warning: The related libscg interface code is in pre alpha.
Warning: There may be fatal problems.
SCSI buffer size: 64512

scsidev: '/dev/cdrom'
devname: '/dev/cdrom'
scsibus: -2 target: -2 lun: -2
Warning: Open by 'devname' is unintentional and not supported.

just says that open-by-device name is unintentional, it doesn't give you warnings on the transport.

So in short (and repeating): don't use ATAPI (CDROM_SEND_PACKET), it sucks. Use SG_IO (which means using open-by-device, which works at least as well as the stupid faked ATAPI bus/id/lun crap and has the much better transport). Don't compare apples and oranges.

Jens Axboe <[email protected]> wrote:
[...]

Quoted 3 lines

just says that open-by-device name is unintentional, it doesn't give you warnings on the transport.

Quoted 4 lines

So in short (and repeating): don't use ATAPI (CDROM_SEND_PACKET), it sucks. Use SG_IO (which means using open-by-device, which works at least as well as the stupid faked ATAPI bus/id/lun crap and has the much better transport). Don't compare apples and oranges.

FWIW cdrecord's author prefers dev=ATA:x,y,z, which uses SG_IO *and* gets rid of the open-by-device-warning.

Quoted 3 lines · tabris

Quoted 2 lines · Jens Axboe

Quoted 1 line · Alexander E. Patrakov

Zinx Verituse wrote:

Quoted 8 lines

Quoted 3 lines

Don't ever use that interface, period. It's not just the cdrecord code that may be alpha (I doubt it matters, it's easy to use), the interface it uses is not worth the lines of code it occupies.

Then we have a severe disagreement between the cdrecord code (or
at least the runtime warnings) and the Linux-Kernel IDE folks. specifically, these lines, while running with cdrecord dev=/dev/cdrom

Warning: Open by 'devname' is unintentional and not supported.

just says that open-by-device name is unintentional, it doesn't give you warnings on the transport.

So in short (and repeating): don't use ATAPI (CDROM_SEND_PACKET), it sucks. Use SG_IO (which means using open-by-device, which works at least as well as the stupid faked ATAPI bus/id/lun crap and has the much better transport). Don't compare apples and oranges.

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Quoted 4 lines · Jens Axboe

Quoted 3 lines · tabris

Quoted 2 lines · Jens Axboe

Quoted 1 line · Alexander E. Patrakov

Zinx Verituse wrote:

<snip>

Quoted 8 lines

Quoted 8 lines

Quoted 3 lines

Don't ever use that interface, period. It's not just the cdrecord code that may be alpha (I doubt it matters, it's easy to use), the interface it uses is not worth the lines of code it occupies.

Then we have a severe disagreement between the cdrecord code (or
at least the runtime warnings) and the Linux-Kernel IDE folks. specifically, these lines, while running with cdrecord dev=/dev/cdrom

<snip>

Quoted 9 lines

Warning: Open by 'devname' is unintentional and not supported.

just says that open-by-device name is unintentional, it doesn't give you warnings on the transport.

So in short (and repeating): don't use ATAPI (CDROM_SEND_PACKET), it sucks. Use SG_IO (which means using open-by-device, which works at least as well as the stupid faked ATAPI bus/id/lun crap and has the much better transport). Don't compare apples and oranges.

I'll take your point on the technical merits.

But now I get to wondering what to do about all the old HOWTOs. the cdrecord folks aren't helping.

Maybe instead what should be done is a BIG FAT WARNING in the syslog? that the CDROM_SEND_PACKET interface is deprecated in kernel 2.6? I know that I personally can listen and take your advice, but I worry more about the rest of the users, who either will not hear, or will hear too many conflicting things. Perhaps it won't help, but I'd really like to be able to sell this stuff. And among the necessary things is to be able to have sane warnings, and not have warnings that will scare my customers off!

Yes, this isn't really your (you==Jens) problem, but probably the distro maintainers (cc:d ArkLinux) to put in patches silencing some of these warnings, and/or change the default behaviour of their front-end tools.

I merely hope to find some sanity. Though I have a feeling I'm looking in the wrong places (Free and Open Source).

Remember that it is still possible to write CDs through ide-cd in 2.4.x using some pre-alpha code in cdrecord:

cdrecord dev=ATAPI:1,1,0 image.iso

Quoted 6 lines · Zinx Verituse

I'm going to bump this topic a bit, since it's been a while.. There are still some issues with ide-cd's SG_IO, listed from most important as percieved by me to least:

* Read-only access grants you the ability to write/blank media in the drive
* (with above) You can open the device only in read-only mode.

That's by design. Search linux-scsi or this list for why that is so.

Quoted 27 lines · Jens Axboe

Quoted 19 lines · Zinx Verituse

Quoted 9 lines · Jens Axboe

Quoted 6 lines · Zinx Verituse

I'm going to bump this topic a bit, since it's been a while.. There are still some issues with ide-cd's SG_IO, listed from most important as percieved by me to least:

* Read-only access grants you the ability to write/blank media in the drive
* (with above) You can open the device only in read-only mode.

That's by design. Search linux-scsi or this list for why that is so.

The only thing I can find on the linux-scsi list is refering to sg devices, which are on a different device node from the non-generic device. This means you can still allow users read access to the disk without allowing them to send random commands to the disk -- this isn't currently possible with the IDE interface, since the device with generic access is the same as the one with the original read/cdrom commands access.

Quoted 6 lines

As it is, it's impossible grant users read-only access to an IDE cd-rom without allowing them to do things like replacing the firmware with a malicious/non-working one.

Generic access allowing such things is fine; but only if we can grant non-generic access without granting generic access.

Quoted 7 lines

If you want it to work that way, you have the have a pass-through filter in the kernel knowing what commands are out there (including vendor specific ones). That's just too ugly and not really doable or maintainable, sorry.

If you have access to issue ioctls to the device, you have access to send it arbitrary commands - period.

I don't believe command filtering is neccessary, since all of the ide-cd ioctls are still there (ioctls that allow playing, reading, etc) Only the SG_IO ioctl itself would have to be checked (i.e., not each individual command available with SG_IO, just the overall ioctl itself, categorizing all of SG_IO more or less as raw IO. If this isn't doable with the current design, then the ide-cd interface should at least be very conspicuously documented as being extremely insecure as far as "read" access is concerned, as I know I wouldn't expect users to be able to overwrite my drive's firmware simply by granting the read access.

Quoted 1 line · Jens Axboe

On Sun, Aug 01 2004, Alexander E. Patrakov wrote:

[...]

Quoted 3 lines

Quoted 3 lines

Remember that it is still possible to write CDs through ide-cd in 2.4.x using some pre-alpha code in cdrecord:

cdrecord dev=ATAPI:1,1,0 image.iso

[...]

Quoted 1 line

Don't ever use that interface, period.

Great! So I won't be able to use any of the CD burners I have now.

Quoted 3 lines

It's not just the cdrecord code
that may be alpha (I doubt it matters, it's easy to use), the interface it uses is not worth the lines of code it occupies.

What do you suggest then? ide-scsi is gone, so AFAIK this is the only way to burn CDs right now on 2.6.x

If you want it to work that way, you have the have a pass-through filter in the kernel knowing what commands are out there (including vendor specific ones). That's just too ugly and not really doable or maintainable, sorry.

Quoted 4 lines · Jens Axboe

If you want it to work that way, you have the have a pass-through filter in the kernel knowing what commands are out there (including vendor specific ones). That's just too ugly and not really doable or maintainable, sorry.

I disagree providing you turn it the other way around. The majority of scsi commands have to be protected because you can destroy the drive with some of them or bypass the I/O layers. (Eg using SG_IO to do writes to raw disk to bypass auditing layers)

So you need CAP_SYS_RAWIO for most commands. You can easily build a list of sane commands for a given media type that are harmless and it fits the kernel role of a gatekeeper to do that.

Providing the 'allowed' function is driver level and we also honour read/write properly for that case (so it doesnt bypass block I/O restrictions and fail the least suprise test) then it seems quite doable.

For such I/O you'd then do

	if(capable(CAP_SYS_RAWIO) || driver->allowed(driver, blah, cmdblock))

If the allowed function filters positively "unknown is not allowed" and the default allowed function is simply "no" it works.

We'd end up with a list of allowed commands for all sorts of operations that don't threaten the machine while blocking vendor specific wonders and also cases where users can do stuff like firmware erase.

Quoted 5 lines · Alexander E. Patrakov

Remember that it is still possible to write CDs through ide-cd in 2.4.x using some pre-alpha code in cdrecord:

cdrecord dev=ATAPI:1,1,0 image.iso

But... doesn't that require access to the sg device?

Quoted 4 lines · Jens Axboe

If you want it to work that way, you have the have a pass-through filter in the kernel knowing what commands are out there (including vendor specific ones). That's just too ugly and not really doable or maintainable, sorry.

I disagree providing you turn it the other way around. The majority of scsi commands have to be protected because you can destroy the drive with some of them or bypass the I/O layers. (Eg using SG_IO to do writes to raw disk to bypass auditing layers)

So you need CAP_SYS_RAWIO for most commands. You can easily build a list of sane commands for a given media type that are harmless and it fits the kernel role of a gatekeeper to do that.

Providing the 'allowed' function is driver level and we also honour read/write properly for that case (so it doesnt bypass block I/O restrictions and fail the least suprise test) then it seems quite doable.

For such I/O you'd then do

	if(capable(CAP_SYS_RAWIO) || driver->allowed(driver, blah, cmdblock))

If the allowed function filters positively "unknown is not allowed" and the default allowed function is simply "no" it works.

We'd end up with a list of allowed commands for all sorts of operations that don't threaten the machine while blocking vendor specific wonders and also cases where users can do stuff like firmware erase.

Quoted 8 lines · Jens Axboe

Quoted 6 lines · Zinx Verituse

I'm going to bump this topic a bit, since it's been a while.. There are still some issues with ide-cd's SG_IO, listed from most important as percieved by me to least:

* Read-only access grants you the ability to write/blank media in the drive
* (with above) You can open the device only in read-only mode.

Quoted 1 line

That's by design. Search linux-scsi or this list for why that is so.

So is the only solution to disallow user access to the device? Operationally that is inconvenient in some cases, but every user community has a few ill-intentioned people, and student groups may be somewhat heavy on that. Security is more important than convenience, but both are desirable.

We could go to burning all local reference data on CD-R instead of CD-RW, have a separate CD-R drive, but as noted all of those are undesirable drains on time and money. Clearly having some twit rewite the CD-RW with their own information is even more undesirable, if that wasn't clear ;-)

Quoted 11 lines · Alan Cox

Quoted 4 lines · Jens Axboe

If you want it to work that way, you have the have a pass-through filter in the kernel knowing what commands are out there (including vendor specific ones). That's just too ugly and not really doable or maintainable, sorry.

I disagree providing you turn it the other way around. The majority of scsi commands have to be protected because you can destroy the drive with some of them or bypass the I/O layers. (Eg using SG_IO to do writes to raw disk to bypass auditing layers)

Quoted 3 lines

So you need CAP_SYS_RAWIO for most commands. You can easily build a list of sane commands for a given media type that are harmless and it fits the kernel role of a gatekeeper to do that.

So that's where we vehemently disagree - it fits the kernel role, if you allow it to control policy all of a sudden. And it's not easy, unless you do it per specific device (not just type, make and model).

Quoted 7 lines

Providing the 'allowed' function is driver level and we also honour read/write properly for that case (so it doesnt bypass block I/O restrictions and fail the least suprise test) then it seems quite doable.

For such I/O you'd then do

Quoted 4 lines

	if(capable(CAP_SYS_RAWIO) || driver->allowed(driver, blah, cmdblock))

If the allowed function filters positively "unknown is not allowed" and the default allowed function is simply "no" it works.

Until there's a new valid command for some device, in which case you have to update your kernel?

Quoted 3 lines

We'd end up with a list of allowed commands for all sorts of operations that don't threaten the machine while blocking vendor specific wonders and also cases where users can do stuff like firmware erase.

Sorry, I think this model is totally bogus and I'd absolutely refuse to merge any such beast into the block layer sg code.

Where would the case of firmware download fit? For x86 ATA/ATAPI devices, the vendor usually supplies a dos disk to accomplish this.

Quoted 7 lines

Quoted 3 lines

We'd end up with a list of allowed commands for all sorts of operations that don't threaten the machine while blocking vendor specific wonders and also cases where users can do stuff like firmware erase.

Sorry, I think this model is totally bogus and I'd absolutely refuse to merge any such beast into the block layer sg code.

Well, would something like this patch be acceptable? It just makes SG_IO require write access to the device (cdrecord and cdrdao both open it this way already, so users shouldn't have a problem with it). I probably forgot some stuff, etc. I'm not terribly familiar with the code in question.

Quoted 27 lines · Jens Axboe

Quoted 19 lines · Zinx Verituse

Quoted 9 lines · Jens Axboe

Quoted 6 lines · Zinx Verituse

I'm going to bump this topic a bit, since it's been a while.. There are still some issues with ide-cd's SG_IO, listed from most important as percieved by me to least:

* Read-only access grants you the ability to write/blank media in the drive
* (with above) You can open the device only in read-only mode.

That's by design. Search linux-scsi or this list for why that is so.

The only thing I can find on the linux-scsi list is refering to sg devices, which are on a different device node from the non-generic device. This means you can still allow users read access to the disk without allowing them to send random commands to the disk -- this isn't currently possible with the IDE interface, since the device with generic access is the same as the one with the original read/cdrom commands access.

Quoted 6 lines

As it is, it's impossible grant users read-only access to an IDE cd-rom without allowing them to do things like replacing the firmware with a malicious/non-working one.

Generic access allowing such things is fine; but only if we can grant non-generic access without granting generic access.

Quoted 7 lines

If you want it to work that way, you have the have a pass-through filter in the kernel knowing what commands are out there (including vendor specific ones). That's just too ugly and not really doable or maintainable, sorry.

If you have access to issue ioctls to the device, you have access to send it arbitrary commands - period.

I don't believe command filtering is neccessary, since all of the ide-cd ioctls are still there (ioctls that allow playing, reading, etc) Only the SG_IO ioctl itself would have to be checked (i.e., not each individual command available with SG_IO, just the overall ioctl itself, categorizing all of SG_IO more or less as raw IO. If this isn't doable with the current design, then the ide-cd interface should at least be very conspicuously documented as being extremely insecure as far as "read" access is concerned, as I know I wouldn't expect users to be able to overwrite my drive's firmware simply by granting the read access.

Absolutely not. I've already outlined why in my previous mails I don't want to see anything like this, and this patch is even worse than filtering. Additionally, you risk breaking existing programs.

Quoted 3 lines · Jens Axboe

Absolutely not. I've already outlined why in my previous mails I don't want to see anything like this, and this patch is even worse than filtering. Additionally, you risk breaking existing programs.

Existing broken programs.

Once you do filtering so you don't need CAP_SYS_RAWIO to lob some commands at a device that becomes the place to enforce sensible policies because the filter knows what is "read" and what is "write" so it can do different checks for say "eject" (read) "write" (write) and "erase firmware" (raw I/O)

Quoted 7 lines · Alan Cox

Quoted 4 lines · Jens Axboe

If you want it to work that way, you have the have a pass-through filter in the kernel knowing what commands are out there (including vendor specific ones). That's just too ugly and not really doable or maintainable, sorry.

Quoted 8 lines

I disagree providing you turn it the other way around. The majority of scsi commands have to be protected because you can destroy the drive with some of them or bypass the I/O layers. (Eg using SG_IO to do writes to raw disk to bypass auditing layers)

So you need CAP_SYS_RAWIO for most commands. You can easily build a list of sane commands for a given media type that are harmless and it fits the kernel role of a gatekeeper to do that.

So that's where we vehemently disagree - it fits the kernel role, if you allow it to control policy all of a sudden. And it's not easy, unless you do it per specific device (not just type, make and model).

Quoted 7 lines

Providing the 'allowed' function is driver level and we also honour read/write properly for that case (so it doesnt bypass block I/O restrictions and fail the least suprise test) then it seems quite doable.

For such I/O you'd then do

Quoted 4 lines

	if(capable(CAP_SYS_RAWIO) || driver->allowed(driver, blah, cmdblock))

If the allowed function filters positively "unknown is not allowed" and the default allowed function is simply "no" it works.

Until there's a new valid command for some device, in which case you have to update your kernel?

Quoted 5 lines

We'd end up with a list of allowed commands for all sorts of operations that don't threaten the machine while blocking vendor specific wonders and also cases where users can do stuff like firmware erase.

Sorry, I think this model is totally bogus and I'd absolutely refuse to merge any such beast into the block layer sg code.

Quoted 3 lines · Jens Axboe

Absolutely not. I've already outlined why in my previous mails I don't want to see anything like this, and this patch is even worse than filtering. Additionally, you risk breaking existing programs.

Existing broken programs.

Once you do filtering so you don't need CAP_SYS_RAWIO to lob some commands at a device that becomes the place to enforce sensible policies because the filter knows what is "read" and what is "write" so it can do different checks for say "eject" (read) "write" (write) and "erase firmware" (raw I/O)

Quoted 37 lines · Jens Axboe

Quoted 7 lines · Alan Cox

Quoted 4 lines · Jens Axboe

If you want it to work that way, you have the have a pass-through filter in the kernel knowing what commands are out there (including vendor specific ones). That's just too ugly and not really doable or maintainable, sorry.

Quoted 8 lines

I disagree providing you turn it the other way around. The majority of scsi commands have to be protected because you can destroy the drive with some of them or bypass the I/O layers. (Eg using SG_IO to do writes to raw disk to bypass auditing layers)

So you need CAP_SYS_RAWIO for most commands. You can easily build a list of sane commands for a given media type that are harmless and it fits the kernel role of a gatekeeper to do that.

So that's where we vehemently disagree - it fits the kernel role, if you allow it to control policy all of a sudden. And it's not easy, unless you do it per specific device (not just type, make and model).

Quoted 11 lines

Providing the 'allowed' function is driver level and we also honour read/write properly for that case (so it doesnt bypass block I/O restrictions and fail the least suprise test) then it seems quite doable.

For such I/O you'd then do

	if(capable(CAP_SYS_RAWIO) || driver->allowed(driver, blah, cmdblock))

If the allowed function filters positively "unknown is not allowed" and the default allowed function is simply "no" it works.

Quoted 2 lines

Until there's a new valid command for some device, in which case you have to update your kernel?

As opposed to now when a new command comes along and the driver doesn't generate it until you update your kernel? Reading a CD doesn't take

exotic commands, and given the choice of having users able to send arbitrary commands to the device and not access it at all, I would say "not at all" would be good.

Quoted 3 lines

Quoted 3 lines

We'd end up with a list of allowed commands for all sorts of operations that don't threaten the machine while blocking vendor specific wonders and also cases where users can do stuff like firmware erase.

There was a note on another list titled "Why did this work?" (from memory) where someone accidentally run a firmware update as a normal user and it worked. While this was a benign event, it points out that there is a hole here far beyond my earlier worry that someone would update a CD-RW.

Quoted 2 lines

Quoted 3 lines

Sorry, I think this model is totally bogus and I'd absolutely refuse to merge any such beast into the block layer sg code.

So what is your solution? Or do you believe that allowing users to have unmonitored access to devices is acceptable?

Is this problem only in ide-cd, or does it affect other devices like ZIP, USB, etc, which do or may look like SCSI?

Alan, there will be _no_ filtering.

Quoted 3 lines

exotic commands, and given the choice of having users able to send arbitrary commands to the device and not access it at all, I would say "not at all" would be good.

Then don't make your cdrom device accesable.

Affects all devices that accept SG_IO.

Ok, that is definitely more acceptable. But then it should be done to CDROM_SEND_PACKET as well, and we risk breaking programs doing so (ie cdrecord run by user currently).

Quoted 5 lines · Jens Axboe

Quoted 3 lines

exotic commands, and given the choice of having users able to send arbitrary commands to the device and not access it at all, I would say "not at all" would be good.

Then don't make your cdrom device accesable.

Lets get rid of root, I mean you don't need root, you could just turn your computer off.

What planet are you living on Jens ?

End users have lots of reasons for being able to access /dev/cdrom directly and also often for groups of users to access a disk directly (for example Oracle databases).

That means any security model that isn't based around things beyond basic device access is flawed.

Quoted 1 line

Affects all devices that accept SG_IO.

Then if you refuse to fix SG_IO perhaps all device drivers should remove support for it ?

Quoted 3 lines · Jens Axboe

Ok, that is definitely more acceptable. But then it should be done to CDROM_SEND_PACKET as well, and we risk breaking programs doing so (ie cdrecord run by user currently).

Definitely. Irrespective of any questions like filtering commands having /dev device access allow you to compromise the entire system is not a good model. CAP_SYS_RAWIO is the capability for "can do anything" so seems appropriate here.

Perhaps if you acknowledge that it wont be perfect, then it's becomes more acceptable imo. So you can issue some commands that do write to the drive even as a regular user, but none that permanently alter the state of the drive or its media (to the best of our knowledge). Other commands you let through.

Quoted 5 lines · Jens Axboe

Perhaps if you acknowledge that it wont be perfect, then it's becomes more acceptable imo. So you can issue some commands that do write to the drive even as a regular user, but none that permanently alter the state of the drive or its media (to the best of our knowledge). Other commands you let through.

The code you included is roughly the kind of filtering I mean except that unknown commands must not get through without CAP_SYS_RAWIO. Anything that is doubtful doesn't get through. As to the location you do it there are at least two ways to handle that. One is that you stick the CAP_SYS_RAWIO of the requester in a flag in the request block the other is that you do it at the top layer. Some BSD socket implementations take the former approach and it works very well as the driver can make a final decision but is told the rights attached to the command.

So once its

	switch()
	{
		case READ6:
		case READ10:
				...
			/* Always */
			break;
		case WRITE6:
		case WRITE10:
			...
			/* if write */
		default:
			if(capable(CAP_SYS_RAWIO))
			/* Only administrators get to do arbitary things */

I agree with it.

Quoted 3 lines · Alan Cox

		default:
			if(capable(CAP_SYS_RAWIO))
			/* Only administrators get to do arbitary things */

That's the case I don't agree with, and why I didn't like the idea originally. That suddenly requires a patching of the kernel because of new commands in new devices. Like when dvd readers became common, you can't just require people to update their kernel because a few new commands are needed to drive them from user space.

Quoted 10 lines · Jens Axboe

Quoted 3 lines · Alan Cox

		default:
			if(capable(CAP_SYS_RAWIO))
			/* Only administrators get to do arbitary things */

That's the case I don't agree with, and why I didn't like the idea originally. That suddenly requires a patching of the kernel because of new commands in new devices. Like when dvd readers became common, you can't just require people to update their kernel because a few new commands are needed to drive them from user space.

The problem is that what if one of the new commands is IGNITE_PLATTER? Unknown commands can do anything, are therefore extremely dangerous, and should be restricted.

Quoted 33 lines · Alan Cox

Quoted 5 lines · Jens Axboe

Perhaps if you acknowledge that it wont be perfect, then it's becomes more acceptable imo. So you can issue some commands that do write to the drive even as a regular user, but none that permanently alter the state of the drive or its media (to the best of our knowledge). Other commands you let through.

The code you included is roughly the kind of filtering I mean except that unknown commands must not get through without CAP_SYS_RAWIO. Anything that is doubtful doesn't get through. As to the location you do it there are at least two ways to handle that. One is that you stick the CAP_SYS_RAWIO of the requester in a flag in the request block the other is that you do it at the top layer. Some BSD socket implementations take the former approach and it works very well as the driver can make a final decision but is told the rights attached to the command.

So once its

	switch()
	{
		case READ6:
		case READ10:
				...
			/* Always */
			break;
		case WRITE6:
		case WRITE10:
			...
			/* if write */
		default:
			if(capable(CAP_SYS_RAWIO))
			/* Only administrators get to do arbitary things */

Quoted 1 line

I agree with it.

That's the case I don't agree with, and why I didn't like the idea originally. That suddenly requires a patching of the kernel because of new commands in new devices. Like when dvd readers became common, you can't just require people to update their kernel because a few new commands are needed to drive them from user space.

Quoted 34 lines · Jens Axboe

Quoted 33 lines · Alan Cox

Quoted 5 lines · Jens Axboe

Perhaps if you acknowledge that it wont be perfect, then it's becomes more acceptable imo. So you can issue some commands that do write to the drive even as a regular user, but none that permanently alter the state of the drive or its media (to the best of our knowledge). Other commands you let through.

The code you included is roughly the kind of filtering I mean except that unknown commands must not get through without CAP_SYS_RAWIO. Anything that is doubtful doesn't get through. As to the location you do it there are at least two ways to handle that. One is that you stick the CAP_SYS_RAWIO of the requester in a flag in the request block the other is that you do it at the top layer. Some BSD socket implementations take the former approach and it works very well as the driver can make a final decision but is told the rights attached to the command.

So once its

	switch()
	{
		case READ6:
		case READ10:
				...
			/* Always */
			break;
		case WRITE6:
		case WRITE10:
			...
			/* if write */
		default:
			if(capable(CAP_SYS_RAWIO))
			/* Only administrators get to do arbitary things */

Quoted 7 lines

Quoted 1 line

I agree with it.

That's the case I don't agree with, and why I didn't like the idea originally. That suddenly requires a patching of the kernel because of new commands in new devices. Like when dvd readers became common, you can't just require people to update their kernel because a few new commands are needed to drive them from user space.

This is no different from having to build a new kernel whenever you happen to install a new revision of a videocard, nic, scsi controller, or random other device new enough that its pci_id isn't in pci_ids.h. New features and new devices frequently require new kernels.

Quoted 1 line

Quoted 1 line

Quoted 1 line

Quoted 1 line

"JA" == Jens Axboe <[email protected]> writes:

Quoted 5 lines

That's the case I don't agree with, and why I didn't like the idea originally. That suddenly requires a patching of the kernel because of new commands in new devices. Like when dvd readers became common, you can't just require people to update their kernel because a few new commands are needed to drive them from user space.

The problem is that what if one of the new commands is IGNITE_PLATTER? Unknown commands can do anything, are therefore extremely dangerous, and should be restricted.

But thanks for high lighting why filtering is bad for new devices.

That's the case I don't agree with, and why I didn't like the idea originally. That suddenly requires a patching of the kernel because of new commands in new devices. Like when dvd readers became common, you can't just require people to update their kernel because a few new commands are needed to drive them from user space.

              default:
                      if(capable(CAP_SYS_RAWIO))
                      /* Only administrators get to do arbitary things

Quoted 1 line

Quoted 1 line

Quoted 1 line

Quoted 1 line

Quoted 1 line

"JA" == Jens Axboe <[email protected]> writes:

JA> Like when dvd readers became common, you can't just require people JA> to update their kernel because a few new commands are needed to JA> drive them from user space.

Perhaps I'm being completely dense, but why would the filtering tables have to be compiled into the kernel? Why not load them from user space via a mechanism requiring CAP_SYS_RAWIO?

How many commands are we talking about here? Is the mechanism workable by a simple bitmask, or is something more complex like a state machine required?

Quoted 5 lines · Jens Axboe

That's the case I don't agree with, and why I didn't like the idea originally. That suddenly requires a patching of the kernel because of new commands in new devices. Like when dvd readers became common, you can't just require people to update their kernel because a few new commands are needed to drive them from user space.

I'm stunning we are even having this argument. You are talking about what appes to be a hardware destruction enabling security level bug in the 2.6 kernel and arguing about whether it is a feature or not.

In essence you are saying read access to any raw device node entitles the opener of the file to destroy the attached device (device even not just media). You are arguing that its ok that I can use raw scsi I/O to subvert the read/write permissions too.

In the example code I gave

Quoted 3 lines

              default:
                      if(capable(CAP_SYS_RAWIO))
                      /* Only administrators get to do arbitary things

*/

Quoted 1 line

means there is no need to recompile anything, you just need priviledges to do stuff the kernel doesn't *know* is safe. This is the correct behaviour for people who don't live in cloud cuckoo land.

Quoted 21 lines · Zinx Verituse

Quoted 10 lines · Jens Axboe

Quoted 6 lines · Zinx Verituse

I'm going to bump this topic a bit, since it's been a while.. There are still some issues with ide-cd's SG_IO, listed from most important as percieved by me to least:

* Read-only access grants you the ability to write/blank media in the drive
* (with above) You can open the device only in read-only mode.

That's by design. Search linux-scsi or this list for why that is so.

The only thing I can find on the linux-scsi list is refering to sg devices, which are on a different device node from the non-generic device. This means you can still allow users read access to the disk without allowing them to send random commands to the disk -- this isn't currently possible with the IDE interface, since the device with generic access is the same as the one with the original read/cdrom commands access.

Quoted 6 lines

As it is, it's impossible grant users read-only access to an IDE cd-rom without allowing them to do things like replacing the firmware with a malicious/non-working one.

Generic access allowing such things is fine; but only if we can grant non-generic access without granting generic access.

If you want it to work that way, you have the have a pass-through filter in the kernel knowing what commands are out there (including vendor specific ones). That's just too ugly and not really doable or maintainable, sorry.

If you have access to issue ioctls to the device, you have access to send it arbitrary commands - period.