ide-cd problems

ide-cd problems

[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.
 * 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.

The read-only granting write/blank seems like a pretty serious security issue
to me.  Not being able to open the device without media is merely extremely
annoying (and I suspect fixing it would break a lot of programs).

-- 
Zinx Verituse                                    http://zinx.xmms.org/

Re: ide-cd problems

[Jens Axboe]

On Fri, Jul 30 2004, Zinx Verituse wrote:
> 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.

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

False, you use O_NONBLOCK.

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

That's true, later implementation of block layer SG_IO adds that as
well. It's really a minor thing though, I don't think I've ever seen
anyone use it outside of regression testing scripts.

-- 
Jens Axboe

Re: ide-cd problems

[Zinx Verituse]

On Sat, Jul 31, 2004 at 05:36:10PM +0200, Jens Axboe wrote:
> On Fri, Jul 30 2004, Zinx Verituse wrote:
> > 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.

> 
> >  * You can't open the device unless there is media in the drive
> 
> False, you use O_NONBLOCK.

Thanks, I didn't know about this one -- works great :)


> 
[snip stuff about scatter gather/manual dma]
> 
> -- 
> Jens Axboe

-- 
Zinx Verituse                                    http://zinx.xmms.org/

Re: ide-cd problems

[Jens Axboe]

On Sat, Jul 31 2004, Zinx Verituse wrote:
> On Sat, Jul 31, 2004 at 05:36:10PM +0200, Jens Axboe wrote:
> > On Fri, Jul 30 2004, Zinx Verituse wrote:
> > > 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.

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.

-- 
Jens Axboe

Re: ide-cd problems

[Zinx Verituse]

On Sat, Jul 31, 2004 at 10:00:36PM +0200, Jens Axboe wrote:
> On Sat, Jul 31 2004, Zinx Verituse wrote:
> > On Sat, Jul 31, 2004 at 05:36:10PM +0200, Jens Axboe wrote:
> > > On Fri, Jul 30 2004, Zinx Verituse wrote:
> > > > 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.
> 
> 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.

-- 
Zinx Verituse                                    http://zinx.xmms.org/

Re: ide-cd problems

[Alexander E. Patrakov]

Zinx Verituse wrote:
> 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

-- 
Alexander E. Patrakov

Re: ide-cd problems

[Jens Axboe]

On Sun, Aug 01 2004, Alexander E. Patrakov wrote:
> Zinx Verituse wrote:
> >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

(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.

-- 
Jens Axboe

Re: ide-cd problems

[Horst von Brand]

Jens Axboe <axboe@suse.de> said:
> On Sun, Aug 01 2004, Alexander E. Patrakov wrote:

[...]

> > 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.

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

>                                        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
-- 
Dr. Horst H. von Brand                   User #22616 counter.li.org
Departamento de Informatica                     Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria              +56 32 654239
Casilla 110-V, Valparaiso, Chile                Fax:  +56 32 797513

Re: ide-cd problems

[Jens Axboe]

On Sun, Aug 01 2004, Horst von Brand wrote:
> Jens Axboe <axboe@suse.de> said:
> > On Sun, Aug 01 2004, Alexander E. Patrakov wrote:
> 
> [...]
> 
> > > 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.
> 
> Great! So I won't be able to use any of the CD burners I have now.

Use the SG_IO interface, it should be the default if you just specify
dev=/dev/hdc instead of faking some SCSI like device enumeration for
ATAPI.

> >                                        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 read the above, it was about 2.4 and using ide-cd instead of
ide-scsi there. In 2.6 you have two options outside of ide-scsi: one is
the CDROM_SEND_PACKET (which is what the dev=ATAPI:1,1,0 above used)
which works in both 2.4 and 2.6, but is absolutely crap and not
recommended. The other is the SG_IO method, which is the recommended
approach.

-- 
Jens Axboe

Re: ide-cd problems

[Bill Davidsen]

Horst von Brand wrote:
> Jens Axboe <axboe@suse.de> said:
> 
>>On Sun, Aug 01 2004, Alexander E. Patrakov wrote:
> 
> 
> [...]
> 
> 
>>>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.
> 
> 
> Great! So I won't be able to use any of the CD burners I have now.
> 
> 
>>                                       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

Actually ide-scsi isn't gone, and what you want is ATA: not ATAPI: here. 
But if ATAPI: works for you, it's slow and grotty, but I think it does 
work. I've been using ide-scsi on 2.4 and don't plan to stop while it 
works, but ATAPI: is the one of choice for 2.6, particularly for burning 
audio.

-- 
    -bill davidsen (davidsen@tmr.com)
"The secret to procrastination is to put things off until the
  last possible moment - but no longer"  -me

Re: ide-cd problems

[tabris]

[-- Attachment #1: Type: Text/Plain, Size: 2247 bytes --]

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

On Sunday 01 August 2004 11:57 am, Jens Axboe wrote:
> On Sun, Aug 01 2004, Alexander E. Patrakov wrote:
> > Zinx Verituse wrote:
> > >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
>
> (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?

- --
tabris
- -
Remember, Grasshopper, falling down 1000 stairs begins by tripping over
the first one.
		-- Confusion
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFBDkVf1U5ZaPMbKQcRAukeAJ9y33IURJFheeJ39rtvJXHI6Ii5AwCgihup
Vo50HwMaGJe53L/zPFayGEY=
=udwi
-----END PGP SIGNATURE-----

[-- Attachment #2: cdrecord-ATAPI.log --]
[-- Type: text/x-log, Size: 1395 bytes --]

cdrecord: No write mode specified.
cdrecord: Asuming -tao mode.
cdrecord: Future versions of cdrecord may have different drive dependent defaults.
scsidev: 'ATAPI:0,0,0'
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
Cdrecord-Clone 2.01a27-dvd (i686-pc-linux-gnu) Copyright (C) 1995-2004 Jörg Schilling
Note: This version is an unofficial (modified) version with DVD support
Note: and therefore may have bugs that are not present in the original.
Note: Please send bug reports or support requests to <warly@mandrakesoft.com>.
Note: The author of cdrecord should not be bothered with problems in this version.
TOC Type: 1 = CD-ROM
Using libscg version 'schily-0.8'.
atapi: 1
Device type    : Removable CD-ROM
Version        : 0
Response Format: 2
Capabilities   : 
Vendor_info    : 'TDK     '
Identifikation : 'CDRW241040B     '
Revision       : '57S2'
Device seems to be: Generic mmc CD-RW.
Current: 0x0009
Profile: 0x000A 
Profile: 0x0009 (current)
Profile: 0x0008 
Profile: 0x0002 (current)
Using generic SCSI-3/mmc   CD-R/CD-RW driver (mmc_cdr).
Driver flags   : MMC-3 SWABAUDIO BURNFREE 
Supported modes: TAO PACKET SAO SAO/R96P SAO/R96R RAW/R16 RAW/R96P RAW/R96R
Drive buf size : 1966272 = 1920 KB
FIFO size      : 4194304 = 4096 KB

[-- Attachment #3: cdrecord.log --]
[-- Type: text/x-log, Size: 2375 bytes --]

cdrecord: No write mode specified.
cdrecord: Asuming -tao mode.
cdrecord: Future versions of cdrecord may have different drive dependent defaults.
scsidev: '/dev/cdrom'
devname: '/dev/cdrom'
scsibus: -2 target: -2 lun: -2
Warning: Open by 'devname' is unintentional and not supported.
Linux sg driver version: 3.5.27
cdrecord: Warning: using inofficial libscg transport code version (warly-scsi-linux-sg.c-1.80-mdk '@(#)scsi-linux-sg.c	1.80 04/03/08 Copyright 1997 J. Schilling').
SCSI buffer size: 64512
Cdrecord-Clone 2.01a27-dvd (i686-pc-linux-gnu) Copyright (C) 1995-2004 Jörg Schilling
Note: This version is an unofficial (modified) version with DVD support
Note: and therefore may have bugs that are not present in the original.
Note: Please send bug reports or support requests to <warly@mandrakesoft.com>.
Note: The author of cdrecord should not be bothered with problems in this version.
TOC Type: 1 = CD-ROM
Using libscg version 'schily-0.8'.
atapi: 1
Device type    : Removable CD-ROM
Version        : 0
Response Format: 2
Capabilities   : 
Vendor_info    : 'TDK     '
Identifikation : 'CDRW241040B     '
Revision       : '57S2'
Device seems to be: Generic mmc CD-RW.
Current: 0x0009
Profile: 0x000A 
Profile: 0x0009 (current)
Profile: 0x0008 
Profile: 0x0002 (current)
Using generic SCSI-3/mmc   CD-R/CD-RW driver (mmc_cdr).
Driver flags   : MMC-3 SWABAUDIO BURNFREE 
Supported modes: TAO PACKET SAO SAO/R96P SAO/R96R RAW/R16 RAW/R96P RAW/R96R
Drive buf size : 1966272 = 1920 KB
FIFO size      : 4194304 = 4096 KB
Track 01: data   405 MB        
Total size:      466 MB (46:10.90) = 207818 sectors
Lout start:      466 MB (46:12/68) = 207818 sectors
Current Secsize: 2048
ATIP info from disk:
  Indicated writing power: 4
  Is not unrestricted
  Is not erasable
  Disk sub type: Medium Type A, high Beta category (A+) (3)
  ATIP start of lead in:  -11849 (97:24/01)
  ATIP start of lead out: 359848 (79:59/73)
Disk type:    Long strategy type (Cyanine, AZO or similar)
Manuf. index: 25
Manufacturer: Taiyo Yuden Company Limited
Blocks total: 359848 Blocks current: 359848 Blocks remaining: 152030
Starting to write CD/DVD at speed   8.0 in dummy TAO mode for single session.
Last chance to quit, starting dummy write in 9 seconds.\b\b\b\b\b\b\b\b\b\b\b\b\b   8 seconds.cdrecord: fifo had 64 puts and 0 gets.
cdrecord: fifo was 0 times empty and 1 times full, min fill was 0%.

Re: ide-cd problems

[Jens Axboe]

On Mon, Aug 02 2004, tabris wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> On Sunday 01 August 2004 11:57 am, Jens Axboe wrote:
> > On Sun, Aug 01 2004, Alexander E. Patrakov wrote:
> > > Zinx Verituse wrote:
> > > >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
> >
> > (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.

Kernel and cdrecord disagreement, news at 11.

> 	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?

I appreciate the good intentions, but perhaps you should research a bit
of background on this before going over board here. Don't think it
hasn't been suggested to Joerg before to kill that message.

Look at the errors as well - one is about the transport used:

> 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

The other (for SG_IO)

> 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

Re: ide-cd problems

[Andreas Metzler]

Jens Axboe <axboe@suse.de> wrote:
[...] 
> 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.

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

Re: ide-cd problems

[Jens Axboe]

On Mon, Aug 02 2004, Andreas Metzler wrote:
> Jens Axboe <axboe@suse.de> wrote:
> [...] 
> > 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.
> 
> FWIW cdrecord's author prefers dev=ATA:x,y,z, which uses SG_IO *and* gets
> rid of the open-by-device-warning.

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

Well good for him, that's why he didn't drop that idiotic warning. I
think the x,y,z naming for ATAPI devices is utter stupidity.

-- 
Jens Axboe

Re: ide-cd problems

[tabris]

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

On Monday 02 August 2004 9:56 am, Jens Axboe wrote:
> On Mon, Aug 02 2004, tabris wrote:
> > On Sunday 01 August 2004 11:57 am, Jens Axboe wrote:
> > > On Sun, Aug 01 2004, Alexander E. Patrakov wrote:
> > > > Zinx Verituse wrote:
<snip>
> > > 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>
> 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).

- --
tabris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFBDlHY1U5ZaPMbKQcRAnrhAJwPM+sSRInlRy5kmpqQ+nlwS+1D5QCbBZc6
8NsRqRQqLddQgY8FuCzEvck=
=BhCR
-----END PGP SIGNATURE-----

Re: ide-cd problems

[Jens Axboe]

On Mon, Aug 02 2004, tabris wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> On Monday 02 August 2004 9:56 am, Jens Axboe wrote:
> > On Mon, Aug 02 2004, tabris wrote:
> > > On Sunday 01 August 2004 11:57 am, Jens Axboe wrote:
> > > > On Sun, Aug 01 2004, Alexander E. Patrakov wrote:
> > > > > Zinx Verituse wrote:
> <snip>
> > > > 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>
> > 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!

CDROM_SEND_PACKET isn't anymore deprecated in 2.6 than it is in 2.4.
It's equally silly to use it with cdrecord in either kernel. In hind
sight, adding that interface was a mistake. It was never meant for
anything serious like a cd burning interface. It lacks good error
reporting, and it basically could not do worse when it comes to
performance. So if you are in 2.4, use ide-scsi! If you are in 2.6, use
ide-cd with SG_IO (eg ATA: method from cdrecord). As it was mentioned a
little up in this thread, you can actually use x,y,z naming to adresse
your given devices, if you have some weird urge to do so. This will kill
the open-by-devname warning from cdrecord. Or you can just ignore this
warning, it means absolutely nothing.

> 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.

And we did, SUSE killed that stupid warning :-)

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

Like any other place, free/open source communities have their sane and
insane members.

-- 
Jens Axboe

Re: ide-cd problems

[Bill Davidsen]

Alexander E. Patrakov wrote:

> 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?

-- 
    -bill davidsen (davidsen@tmr.com)
"The secret to procrastination is to put things off until the
  last possible moment - but no longer"  -me

Re: ide-cd problems

[Jens Axboe]

On Mon, Aug 02 2004, Bill Davidsen wrote:
> Alexander E. Patrakov wrote:
> 
> >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?

(don't snip cc lists...)

No, it goes through /dev/hdX or /dev/srX

-- 
Jens Axboe

Re: ide-cd problems

[Zinx Verituse]

On Sat, Jul 31, 2004 at 04:02:57PM -0500, Zinx Verituse wrote:
> On Sat, Jul 31, 2004 at 10:00:36PM +0200, Jens Axboe wrote:
> > On Sat, Jul 31 2004, Zinx Verituse wrote:
> > > On Sat, Jul 31, 2004 at 05:36:10PM +0200, Jens Axboe wrote:
> > > > On Fri, Jul 30 2004, Zinx Verituse wrote:
> > > > > 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.
> > 
> > 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.

I'm replying to this because this message was never addressed, and
instead fell in to Yet Another war on cdrecord's stupid naming scheme.
The two have nothing to do with each other, and this issue (i.e., not
the stupid naming scheme) needs addressed.

-- 
Zinx Verituse                                    http://zinx.xmms.org/

Re: ide-cd problems

[Jens Axboe]

On Sat, Jul 31 2004, Zinx Verituse wrote:
> On Sat, Jul 31, 2004 at 10:00:36PM +0200, Jens Axboe wrote:
> > On Sat, Jul 31 2004, Zinx Verituse wrote:
> > > On Sat, Jul 31, 2004 at 05:36:10PM +0200, Jens Axboe wrote:
> > > > On Fri, Jul 30 2004, Zinx Verituse wrote:
> > > > > 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.
> > 
> > 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.

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).

-- 
Jens Axboe

Re: ide-cd problems

[Alan Cox]

On Iau, 2004-08-05 at 06:40, Jens Axboe wrote:
> 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.

Re: ide-cd problems

[Jens Axboe]

On Thu, Aug 05 2004, Alan Cox wrote:
> On Iau, 2004-08-05 at 06:40, Jens Axboe wrote:
> > 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.

We risk breaking lots of programs, but it might be the best option yes.

-- 
Jens Axboe

Re: ide-cd problems

[Alan Cox]

On Gwe, 2004-08-06 at 07:23, Jens Axboe wrote:
> 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. 

Alan

Re: ide-cd problems

[Jens Axboe]

On Fri, Aug 06 2004, Alan Cox wrote:
> On Gwe, 2004-08-06 at 07:23, Jens Axboe wrote:
> > 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. 

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.

-- 
Jens Axboe

Re: ide-cd problems

[Charles Cazabon]

Jens Axboe <axboe@suse.de> wrote:
> On Fri, Aug 06 2004, Alan Cox wrote:
> > 		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.

Charles
-- 
-----------------------------------------------------------------------
Charles Cazabon                            <linux@discworld.dyndns.org>
GPL'ed software available at:     http://www.qcc.ca/~charlesc/software/
-----------------------------------------------------------------------

Re: ide-cd problems

[Jens Axboe]

On Fri, Aug 06 2004, Charles Cazabon wrote:
> Jens Axboe <axboe@suse.de> wrote:
> > On Fri, Aug 06 2004, Alan Cox wrote:
> > > 		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.

Well yes, that's exactly why there is a discussion. As I have written
before, filtering cannot be perfect exactly because of this. Either you
leave unknown commands unfiltered (and risk a problem with new commands
until you update your kernels), or you add the _policy_ to filter
unknown commands and risk not working with new devices for no good
reason.

And if you really want to try and cover everything, you want to add
filtering tables per _device_. Which is basically impossible to do, and
is completely unmaintainable.

But I've already stated that before.

-- 
Jens Axboe

Re: ide-cd problems

[Alan Cox]

On Gwe, 2004-08-06 at 16:14, Charles Cazabon wrote:
> > 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.

The comands in question already include such gems as "format", "erase
firmware" and the like. So if you've got read access to a 2.6 raw block
device you can reformat your oracle database. 

Alan

Re: ide-cd problems

[dleonard]

On Fri, 6 Aug 2004, Jens Axboe wrote:

> On Fri, Aug 06 2004, Alan Cox wrote:
> > On Gwe, 2004-08-06 at 07:23, Jens Axboe wrote:
> > > 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.
>
> 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.

Allowing specific commands while disallowing unknown commands to standard users is a far better scenario than any other proposals I've heard so far.

--
Douglas Leonard
dleonard@dleonard.net

Re: ide-cd problems

[Jens Axboe]

On Fri, Aug 06 2004, dleonard@dleonard.net wrote:
> On Fri, 6 Aug 2004, Jens Axboe wrote:
> 
> > On Fri, Aug 06 2004, Alan Cox wrote:
> > > On Gwe, 2004-08-06 at 07:23, Jens Axboe wrote:
> > > > 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.
> >
> > 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.

It's completely different, that you say so shows you don't understand
the issue at all. New devices work just fine even if the kernel doesn't
understand the pci id, as long as you can drive it from user space. If
you want a direct comparison, it would be comparable to disallow anyone
to use a pci id you did not know about at kernel compile time. So if you
get a new video card later on, it would not work properly until you got
a new kernel with that id included.

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

-- 
Jens Axboe

Re: ide-cd problems

[Alan Cox]

On Gwe, 2004-08-06 at 23:47, Jens Axboe wrote:
> But thanks for high lighting why filtering is bad for new devices.

Filtering is essential. If you have CAP_SYS_RAWIO set then anything
goes. Root is entitled to reflash his hard disk to report all files
having setuid bits, or to total the media or to password lock it.

End users are not and the only sane kernel behaviour for the "unsure"
case is "-EPERM". If its not the right behaviour we have setuid bits.
If it was the other way around your end user just password locked all
your disks with a password you'll never recover. 


Alan

Re: ide-cd problems

[Alan Cox]

Actually there is a seperate complication here for disks that probably
makes the problem a bit more complex for anything with partitions - that
is that SCSI commands are not per partition and I agree with you that we
don't want to get into filtering on that basis. Probably
that means CAP_SYS_RAWIO for anything not the true "whole device" node.

That leaves commands to one device that affect another "disk"  - eg a
firmware upgrade on a big storage array but those are RAWIO things
anyway

Re: ide-cd problems

[Jason L Tibbitts III]

>>>>> "JA" == Jens Axboe <axboe@suse.de> 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?

 - J<

Re: ide-cd problems

[Jens Axboe]

On Fri, Aug 06 2004, Jason L Tibbitts III wrote:
> >>>>> "JA" == Jens Axboe <axboe@suse.de> 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?

Could be done, it's quite some work though. The complexity isn't as much
due to new commands being added (that doesn't happen very often), that's
only problematic from the policy pov. The problem is defining the
tables, it's definitely not trivial. And I still claim not very doable.

-- 
Jens Axboe

Re: ide-cd problems

[Alan Cox]

On Gwe, 2004-08-06 at 15:32, Jens Axboe wrote:
> 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

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

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.

Alan

Re: ide-cd problems

[Jens Axboe]

On Sat, Aug 07 2004, Alan Cox wrote:
> On Gwe, 2004-08-06 at 15:32, Jens Axboe wrote:
> > 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.

Alan, stop putting words into my mouth. I'm not saying it's a feature.

> 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 essence, yes. I'm arguing that it's not easily doable to
differentiate between destructive and non-destructive commands. And that
doing so requires extensive tables because commands are not the same
across devices.

I'm not saying that I think it's a good thing! Or a feature, for that
matter. I'm just arguing the feasibility of doing it, the maintenance
involved, etc.

> In the example code I gave
> 
> >               default:
> >                       if(capable(CAP_SYS_RAWIO))
> >                       /* Only administrators get to do arbitary things
> */
> > 
> 
> 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.

I'm well aware of the implications. The argument is only whether it's ok
to policy filter unknown commands. I guess with capability elevating the
app until the kernels are modified it would be ok, at least it enables
the apps to work for root.

-- 
Jens Axboe

Re: ide-cd problems

[Alan Cox]

On Sad, 2004-07-31 at 21:00, Jens Axboe wrote:
> 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.

Alan

Re: ide-cd problems

[Jens Axboe]

On Tue, Aug 03 2004, Alan Cox wrote:
> On Sad, 2004-07-31 at 21:00, Jens Axboe wrote:
> > 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.

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).

> 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.

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

> 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.

-- 
Jens Axboe

Re: ide-cd problems

[Zinx Verituse]

[-- Attachment #1: Type: text/plain, Size: 2762 bytes --]

On Tue, Aug 03, 2004 at 07:53:40AM +0200, Jens Axboe wrote:
> On Tue, Aug 03 2004, Alan Cox wrote:
> > On Sad, 2004-07-31 at 21:00, Jens Axboe wrote:
> > > 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.
> 
> 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).
> 

Vendor commands would be tricky (it would probably be best to limit
vendor commands to well-established ones, and just disallow the rest
without CAP_SYS_RAWIO or such), but standard commands wouldn't have a
problem, and those don't get added very often.

> > 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.
> 
> Until there's a new valid command for some device, in which case you
> have to update your kernel?
> 

As standard commands don't get added very often, that's not a huge
problem, but.. see the attached patch.

> > 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.

-- 
Zinx Verituse                                    http://zinx.xmms.org/

[-- Attachment #2: linux-2.6.8-rc2-cdrom-access.diff --]
[-- Type: text/plain, Size: 6673 bytes --]

Only in linux-2.6.8-rc2: .config
diff -ru linux-2.6.8-rc2.orig/drivers/block/paride/pcd.c linux-2.6.8-rc2/drivers/block/paride/pcd.c
--- linux-2.6.8-rc2.orig/drivers/block/paride/pcd.c	2004-08-02 19:58:12.000000000 -0500
+++ linux-2.6.8-rc2/drivers/block/paride/pcd.c	2004-08-02 20:17:37.000000000 -0500
@@ -259,7 +259,7 @@
 				unsigned cmd, unsigned long arg)
 {
 	struct pcd_unit *cd = inode->i_bdev->bd_disk->private_data;
-	return cdrom_ioctl(&cd->info, inode, cmd, arg);
+	return cdrom_ioctl(&cd->info, inode, file, cmd, arg);
 }
 
 static int pcd_block_media_changed(struct gendisk *disk)
diff -ru linux-2.6.8-rc2.orig/drivers/cdrom/cdrom.c linux-2.6.8-rc2/drivers/cdrom/cdrom.c
--- linux-2.6.8-rc2.orig/drivers/cdrom/cdrom.c	2004-08-02 19:58:12.000000000 -0500
+++ linux-2.6.8-rc2/drivers/cdrom/cdrom.c	2004-08-02 20:18:22.000000000 -0500
@@ -2065,15 +2065,18 @@
  * mmc_ioct().
  */
 int cdrom_ioctl(struct cdrom_device_info *cdi, struct inode *ip,
-		unsigned int cmd, unsigned long arg)
+		struct file *file, unsigned int cmd, unsigned long arg)
 {
 	struct cdrom_device_ops *cdo = cdi->ops;
 	int ret;
 
 	/* Try the generic SCSI command ioctl's first.. */
-	ret = scsi_cmd_ioctl(ip->i_bdev->bd_disk, cmd, (void __user *)arg);
-	if (ret != -ENOTTY)
-		return ret;
+	/* But only if the user has write access: open(,O_RDWR | O_NONBLOCK) */
+	if (file->f_mode & FMODE_WRITE) {
+		ret = scsi_cmd_ioctl(ip->i_bdev->bd_disk, cmd, (void __user *)arg);
+		if (ret != -ENOTTY)
+			return ret;
+	}
 
 	/* the first few commands do not deal with audio drive_info, but
 	   only with routines in cdrom device operations. */
diff -ru linux-2.6.8-rc2.orig/drivers/cdrom/cdu31a.c linux-2.6.8-rc2/drivers/cdrom/cdu31a.c
--- linux-2.6.8-rc2.orig/drivers/cdrom/cdu31a.c	2004-06-16 00:19:42.000000000 -0500
+++ linux-2.6.8-rc2/drivers/cdrom/cdu31a.c	2004-08-02 20:19:06.000000000 -0500
@@ -3179,7 +3179,7 @@
 static int scd_block_ioctl(struct inode *inode, struct file *file,
 				unsigned cmd, unsigned long arg)
 {
-	return cdrom_ioctl(&scd_info, inode, cmd, arg);
+	return cdrom_ioctl(&scd_info, inode, file, cmd, arg);
 }
 
 static int scd_block_media_changed(struct gendisk *disk)
diff -ru linux-2.6.8-rc2.orig/drivers/cdrom/cm206.c linux-2.6.8-rc2/drivers/cdrom/cm206.c
--- linux-2.6.8-rc2.orig/drivers/cdrom/cm206.c	2004-06-16 00:20:03.000000000 -0500
+++ linux-2.6.8-rc2/drivers/cdrom/cm206.c	2004-08-02 20:19:21.000000000 -0500
@@ -1363,7 +1363,7 @@
 static int cm206_block_ioctl(struct inode *inode, struct file *file,
 				unsigned cmd, unsigned long arg)
 {
-	return cdrom_ioctl(&cm206_info, inode, cmd, arg);
+	return cdrom_ioctl(&cm206_info, inode, file, cmd, arg);
 }
 
 static int cm206_block_media_changed(struct gendisk *disk)
diff -ru linux-2.6.8-rc2.orig/drivers/cdrom/mcd.c linux-2.6.8-rc2/drivers/cdrom/mcd.c
--- linux-2.6.8-rc2.orig/drivers/cdrom/mcd.c	2004-06-16 00:19:37.000000000 -0500
+++ linux-2.6.8-rc2/drivers/cdrom/mcd.c	2004-08-02 20:18:57.000000000 -0500
@@ -227,7 +227,7 @@
 static int mcd_block_ioctl(struct inode *inode, struct file *file,
 				unsigned cmd, unsigned long arg)
 {
-	return cdrom_ioctl(&mcd_info, inode, cmd, arg);
+	return cdrom_ioctl(&mcd_info, inode, file, cmd, arg);
 }
 
 static int mcd_block_media_changed(struct gendisk *disk)
diff -ru linux-2.6.8-rc2.orig/drivers/cdrom/mcdx.c linux-2.6.8-rc2/drivers/cdrom/mcdx.c
--- linux-2.6.8-rc2.orig/drivers/cdrom/mcdx.c	2004-08-02 19:58:12.000000000 -0500
+++ linux-2.6.8-rc2/drivers/cdrom/mcdx.c	2004-08-02 20:18:46.000000000 -0500
@@ -233,7 +233,7 @@
 				unsigned cmd, unsigned long arg)
 {
 	struct s_drive_stuff *p = inode->i_bdev->bd_disk->private_data;
-	return cdrom_ioctl(&p->info, inode, cmd, arg);
+	return cdrom_ioctl(&p->info, inode, file, cmd, arg);
 }
 
 static int mcdx_block_media_changed(struct gendisk *disk)
diff -ru linux-2.6.8-rc2.orig/drivers/cdrom/sbpcd.c linux-2.6.8-rc2/drivers/cdrom/sbpcd.c
--- linux-2.6.8-rc2.orig/drivers/cdrom/sbpcd.c	2004-06-16 00:18:59.000000000 -0500
+++ linux-2.6.8-rc2/drivers/cdrom/sbpcd.c	2004-08-02 20:18:37.000000000 -0500
@@ -5372,7 +5372,7 @@
 				unsigned cmd, unsigned long arg)
 {
 	struct sbpcd_drive *p = inode->i_bdev->bd_disk->private_data;
-	return cdrom_ioctl(p->sbpcd_infop, inode, cmd, arg);
+	return cdrom_ioctl(p->sbpcd_infop, inode, file, cmd, arg);
 }
 
 static int sbpcd_block_media_changed(struct gendisk *disk)
diff -ru linux-2.6.8-rc2.orig/drivers/cdrom/viocd.c linux-2.6.8-rc2/drivers/cdrom/viocd.c
--- linux-2.6.8-rc2.orig/drivers/cdrom/viocd.c	2004-08-02 19:58:12.000000000 -0500
+++ linux-2.6.8-rc2/drivers/cdrom/viocd.c	2004-08-02 20:19:35.000000000 -0500
@@ -199,7 +199,7 @@
 		unsigned cmd, unsigned long arg)
 {
 	struct disk_info *di = inode->i_bdev->bd_disk->private_data;
-	return cdrom_ioctl(&di->viocd_info, inode, cmd, arg);
+	return cdrom_ioctl(&di->viocd_info, inode, file, cmd, arg);
 }
 
 static int viocd_blk_media_changed(struct gendisk *disk)
diff -ru linux-2.6.8-rc2.orig/drivers/ide/ide-cd.c linux-2.6.8-rc2/drivers/ide/ide-cd.c
--- linux-2.6.8-rc2.orig/drivers/ide/ide-cd.c	2004-08-02 19:58:13.000000000 -0500
+++ linux-2.6.8-rc2/drivers/ide/ide-cd.c	2004-08-02 20:16:59.000000000 -0500
@@ -3394,7 +3394,7 @@
 	int err = generic_ide_ioctl(bdev, cmd, arg);
 	if (err == -EINVAL) {
 		struct cdrom_info *info = drive->driver_data;
-		err = cdrom_ioctl(&info->devinfo, inode, cmd, arg);
+		err = cdrom_ioctl(&info->devinfo, inode, file, cmd, arg);
 	}
 	return err;
 }
diff -ru linux-2.6.8-rc2.orig/drivers/scsi/sr.c linux-2.6.8-rc2/drivers/scsi/sr.c
--- linux-2.6.8-rc2.orig/drivers/scsi/sr.c	2004-08-02 19:58:24.000000000 -0500
+++ linux-2.6.8-rc2/drivers/scsi/sr.c	2004-08-02 20:17:23.000000000 -0500
@@ -504,7 +504,7 @@
                 case SCSI_IOCTL_GET_BUS_NUMBER:
                         return scsi_ioctl(sdev, cmd, (void __user *)arg);
 	}
-	return cdrom_ioctl(&cd->cdi, inode, cmd, arg);
+	return cdrom_ioctl(&cd->cdi, inode, file, cmd, arg);
 }
 
 static int sr_block_media_changed(struct gendisk *disk)
diff -ru linux-2.6.8-rc2.orig/include/linux/cdrom.h linux-2.6.8-rc2/include/linux/cdrom.h
--- linux-2.6.8-rc2.orig/include/linux/cdrom.h	2004-06-16 00:18:52.000000000 -0500
+++ linux-2.6.8-rc2/include/linux/cdrom.h	2004-08-02 20:20:09.000000000 -0500
@@ -985,7 +985,7 @@
 			struct file *fp);
 extern int cdrom_release(struct cdrom_device_info *cdi, struct file *fp);
 extern int cdrom_ioctl(struct cdrom_device_info *cdi, struct inode *ip,
-		unsigned int cmd, unsigned long arg);
+		struct file *file, unsigned int cmd, unsigned long arg);
 extern int cdrom_media_changed(struct cdrom_device_info *);
 
 extern int register_cdrom(struct cdrom_device_info *cdi);

Re: ide-cd problems

[Jens Axboe]

On Tue, Aug 03 2004, Zinx Verituse wrote:
> > > 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.

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.

-- 
Jens Axboe

Re: ide-cd problems

[Alan Cox]

On Mer, 2004-08-04 at 06:01, Jens Axboe wrote:
> 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)

Re: ide-cd problems

[Jens Axboe]

On Thu, Aug 05 2004, Alan Cox wrote:
> On Mer, 2004-08-04 at 06:01, Jens Axboe wrote:
> > 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)

Alan, there will be _no_ filtering.

-- 
Jens Axboe

Re: ide-cd problems

[Alan Cox]

On Iau, 2004-08-05 at 18:46, Jens Axboe wrote:
> Alan, there will be _no_ filtering.

This is a community project. You are not a dictator, you are not some
all powerful all seeing all knowledgable master, and I don't work for
you.

I think you should adjust your attitude. Linus/Andrew based on actual
code and opinions decide that question. My own feeling is that the
desktop realities will dictate filtering to allow some non CAP_SYS_RAWIO
use, that or we'll be adding CD and DVD burning ioctls.

I'm not BTW saying you are wrong, just objecting to your attiude.
Filtering may well turn out to be a stupid idea.

Alan

Re: ide-cd problems

[Bill Davidsen]

Alan Cox wrote:
> On Mer, 2004-08-04 at 06:01, Jens Axboe wrote:
> 
>>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)

Would it be reasonable to have a general list (SCSI-II standard or so) 
and then a list of vendor commands in the driver? I really think that 
legitimate user programs will be using well-defined commands, after all 
that's why there is a standard. So requiring raw access for that may not 
be an issue.

-- 
    -bill davidsen (davidsen@tmr.com)
"The secret to procrastination is to put things off until the
  last possible moment - but no longer"  -me

Re: ide-cd problems

[Bill Davidsen]

Jens Axboe wrote:
> On Tue, Aug 03 2004, Alan Cox wrote:
> 
>>On Sad, 2004-07-31 at 21:00, Jens Axboe wrote:
>>
>>>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.
> 
> 
> 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).
> 
> 
>>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.
> 
> 
> 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.
> 
> 
>>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.
> 
> 
> 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?

-- 
    -bill davidsen (davidsen@tmr.com)
"The secret to procrastination is to put things off until the
  last possible moment - but no longer"  -me

Re: ide-cd problems

[Jens Axboe]

On Thu, Aug 05 2004, Bill Davidsen wrote:
> Jens Axboe wrote:
> >On Tue, Aug 03 2004, Alan Cox wrote:
> >
> >>On Sad, 2004-07-31 at 21:00, Jens Axboe wrote:
> >>
> >>>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.
> >
> >
> >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).
> >
> >
> >>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.
> >
> >
> >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 

Weak example. Lots of commands aren't issued directly by the device
driver, in fact very few are. The driver does not have to be updated to
handle new commands. If you add policy filtering, it does.

> 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.

> >>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.
>
> >
> >
> >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?

If differentiating use of a cdrom implies filtering commands, then
that's not acceptable to me. So they either have access to the device or
they don't.

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

Affects all devices that accept SG_IO.

-- 
Jens Axboe

Re: ide-cd problems

[Alan Cox]

On Iau, 2004-08-05 at 20:35, Jens Axboe wrote:
> > 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.

> Affects all devices that accept SG_IO.

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

Re: ide-cd problems

[Jens Axboe]

On Thu, Aug 05 2004, Alan Cox wrote:
> On Iau, 2004-08-05 at 20:35, Jens Axboe wrote:
> > > 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 ?

I'm living on the planet where filtering is not possible, unless you
want to have oodles of unmaintanable tables for different devices. And
that means that if you don't trust a user with your cdrom currently,
don't give him/her access to it.

> 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).

Yes I know.

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

Then we should require raw io capability, as I've stated I'm fine with
that. I'm not fine with filtering.

> > Affects all devices that accept SG_IO.
> 
> Then if you refuse to fix SG_IO perhaps all device drivers should remove
> support for it ?

Well they can't, it's a block layer property. The only thing the device
sees is a regular struct request.

-- 
Jens Axboe

Re: ide-cd problems

[Doug Maxey]

On Tue, 03 Aug 2004 00:54:31 BST, Alan Cox wrote:
>On Sad, 2004-07-31 at 21:00, Jens Axboe wrote:
>> 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)
>

  Where would the case of firmware download fit?  For x86 ATA/ATAPI
  devices, the vendor usually supplies a dos disk to accomplish this.
  However, that method is absolutely broken a PPC system.  We have to
  use a proprietary driver that was written using vendor specific
  commands.  I assume that all vendors have their own set of
  proprietary commands, specific to the device to be updated.

  Usually one does not need to do firmware updates, but when
  necessary, it is generally a requirement to do it on the system with
  the device, not to remove the device and carry it to a system where
  it can be done.

  If there was an interface to allow wide open operations, including a
  non-interrupt (polling) mode of operation, this would cover a large
  portion of devices.

>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.

  Allowed commands are really on a device specfic basis.  And a RAS
  requirement, for at least those of use that have funny endianess
  hardware.  :)

++doug

Re: ide-cd problems

[Alan Cox]

On Maw, 2004-08-03 at 16:28, Doug Maxey wrote:
>   Where would the case of firmware download fit?  For x86 ATA/ATAPI
>   devices, the vendor usually supplies a dos disk to accomplish this.

We already have CAP_SYS_RAWIO methods for such things so that is ok.
As to the claim that allowed commands vary by device I disagree. At the
"user safe" level the list is somewhat smaller and consistent

Re: ide-cd problems

[Bill Davidsen]

Jens Axboe wrote:
> On Sat, Jul 31 2004, Zinx Verituse wrote:
> 
>>On Sat, Jul 31, 2004 at 05:36:10PM +0200, Jens Axboe wrote:
>>
>>>On Fri, Jul 30 2004, Zinx Verituse wrote:
>>>
>>>>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.
> 
> 
> 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.
> 
Let me try this again... To do the normal "reasonable" things associated 
with raw read, the standard SCSI command set includes commands in the 
read and seek sets which seem to be what is needed. These are standard, 
and I fail to see how allowing them, and only them, could be so 
complicated in the case where only read access is allowed. There is no 
need to allow vendor commands or any kind to permit programs such as 
checks and backups of various kinds to be used.

I think the same is true of write, filtering out anything but the set of 
write commands in the common SCSI command set is fine, and in the rare 
case where it isn't, I'm happy to say that raw write capability is the 
answer.

   read does not imply write
   write does not imply anything but data

firmware reload, low level format, spin in the other direction, all 
would require capability.

If you disagree with the above in some technical way, please clarify. If 
you just are opposing filtration on general principles because you run 
everything as root or don't believe in levels of security, I sure can't 
change your mind if you're willing to disagree with Alan.

-- 
    -bill davidsen (davidsen@tmr.com)
"The secret to procrastination is to put things off until the
  last possible moment - but no longer"  -me

Re: ide-cd problems

[Bill Davidsen]

Jens Axboe wrote:
> On Fri, Jul 30 2004, Zinx Verituse wrote:
> 
>>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.

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 ;-)

-- 
    -bill davidsen (davidsen@tmr.com)
"The secret to procrastination is to put things off until the
  last possible moment - but no longer"  -me

Re: ide-cd problems

[Horst von Brand]

Bill Davidsen <davidsen@tmr.com> said:
> Jens Axboe wrote:
> > On Fri, Jul 30 2004, Zinx Verituse wrote:
> > 
> >>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.

> 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.

Right. It is called "compromise".

> 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 ;-)

OK, what prevents said twit from bringing in their own (doctored) CD-R in
any case?
-- 
Dr. Horst H. von Brand                   User #22616 counter.li.org
Departamento de Informatica                     Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria              +56 32 654239
Casilla 110-V, Valparaiso, Chile                Fax:  +56 32 797513