2.6.8.1 Mis-detect CRDW as CDROM

2.6.8.1 Mis-detect CRDW as CDROM

[John Wendel]

K3B detects my Lite-on LTR-52327S CDRW as a CDROM when run with 2.6.8.1. 
Booting back into 2.6.7 corrects the problem. I've attached the (totally 
uninteresting parts of) dmesg.  Any clues  appreciated.

Linux version 2.6.7-1.494.2.2 (bhcompile@tweety.build.redhat.com) (gcc 
version 3.3.3 20040412 (Red Hat Linux 3.3.3-7)) #1 Tue Aug 3 09:39:58 
EDT 2004
ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
hdc: LITE-ON LTR-52327S, ATAPI CD/DVD-ROM drive
ide1 at 0x170-0x177,0x376 on irq 15
hdc: ATAPI 52X CD-ROM CD-R/RW drive, 2048kB Cache, UDMA(33)
Uniform CD-ROM driver Revision: 3.20

Linux version 2.6.8.1 (jwendel@xxxxxxxxx) (gcc version 3.3.3 20040412 
(Red Hat Linux 3.3.3-7)) #1 Sun Aug 15 10:50:07 PDT 2004
ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
hdc: LITE-ON LTR-52327S, ATAPI CD/DVD-ROM drive
ide1 at 0x170-0x177,0x376 on irq 15
hdc: ATAPI 52X CD-ROM CD-R/RW drive, 2048kB Cache, UDMA(33)
Uniform CD-ROM driver Revision: 3.20

Re: 2.6.8.1 Mis-detect CRDW as CDROM

[Alan Cox]

On Sul, 2004-08-15 at 22:43, John Wendel wrote:
> K3B detects my Lite-on LTR-52327S CDRW as a CDROM when run with 2.6.8.1. 
> Booting back into 2.6.7 corrects the problem. I've attached the (totally 
> uninteresting parts of) dmesg.  Any clues  appreciated.

The kernel really has no understanding of the difference here, and
the two dmesg files are identical so what makes you make that claim

Re: 2.6.8.1 Mis-detect CRDW as CDROM

[John Wendel]

Alan Cox wrote:

>On Sul, 2004-08-15 at 22:43, John Wendel wrote:
>  
>
>>K3B detects my Lite-on LTR-52327S CDRW as a CDROM when run with 2.6.8.1. 
>>Booting back into 2.6.7 corrects the problem. I've attached the (totally 
>>uninteresting parts of) dmesg.  Any clues  appreciated.
>>    
>>
>
>The kernel really has no understanding of the difference here, and
>the two dmesg files are identical so what makes you make that claim
>
>
>  
>
What claim? I'm not claiming anything, just trying to report a problem. 
I don't have the slightest idea what might be causing this problem, but 
the problem is real. I can see that the dmesg files are identical which 
is why I said they were "totally uninteresting".  Since the new kernel 
is the only variable in this situation, I thought it reasonable to 
request help from you kernel gods.  Sorry, I'll now crawl back under my 
rock.

John Wendel

Re: 2.6.8.1 Mis-detect CRDW as CDROM

[Alan Cox]

On Llu, 2004-08-16 at 00:24, John Wendel wrote:
> >>K3B detects my Lite-on LTR-52327S CDRW as a CDROM when run with 2.6.8.1. 
> >>Booting back into 2.6.7 corrects the problem. I've attached the (totally 
> >>uninteresting parts of) dmesg.  Any clues  appreciated.
> What claim? I'm not claiming anything, just trying to report a problem. 
> I don't have the slightest idea what might be causing this problem, but 

Ah gotcha - I missed the "K3B" in the report so I was confused what was
deciding it wasn't a CDRW. Are you running it as root. 2.6.8 tightened
the security of some of the commands. That in part will need adjustment
but may mean K3B needs to run as root to burn CD's on 2.6.8

Alan

Re: 2.6.8.1 Mis-detect CRDW as CDROM

[Marc Ballarin]

On Sun, 15 Aug 2004 14:43:53 -0700
John Wendel <jwendel10@comcast.net> wrote:

> K3B detects my Lite-on LTR-52327S CDRW as a CDROM when run with 2.6.8.1.
> 
> Booting back into 2.6.7 corrects the problem. I've attached the (totally
> 
> uninteresting parts of) dmesg.  Any clues  appreciated.
> ...

Due to the newly added command filtering, you now need to run cdrecord as
root. Since cdrecord will drop root privileges before accessing the drive,
setuid root won't help.

This means you will have to run cdrecord *and* k3b as root!

IMHO it is more secure to simply disable filtering, and run the software as non-root.

This patch restores the behaviour of previous kernels, security issues included:

--- linux-2.6.8/drivers/block/scsi_ioctl.c~	2004-08-16 14:16:57.000000000 +0200
+++ linux-2.6.8/drivers/block/scsi_ioctl.c	2004-08-16 14:36:22.562908552 +0200
@@ -196 +196 @@
-	if (verify_command(file, cmd))
+/*	if (verify_command(file, cmd))
@@ -198 +198 @@
-
+*/

Re: 2.6.8.1 Mis-detect CRDW as CDROM

[Alan Cox]

On Llu, 2004-08-16 at 13:38, Marc Ballarin wrote:
> Due to the newly added command filtering, you now need to run cdrecord as
> root. Since cdrecord will drop root privileges before accessing the drive,
> setuid root won't help

cdrecord should be fine. k3b is issuing something not on the filter
list.

> This patch restores the behaviour of previous kernels, security issues included:

Like allowing any user to erase your drive firmware. What you could do
which is much more useful is printk the command byte that gets refused
and see if you can pin down what commands are being blocked that
are needed by K3B 

Alan

Re: 2.6.8.1 Mis-detect CRDW as CDROM

[Frank Steiner]

Hi,

Alan Cox wrote:

 >>This patch restores the behaviour of previous kernels, security issues included:
 >
 >
 > Like allowing any user to erase your drive firmware. What you could do
 > which is much more useful is printk the command byte that gets refused
 > and see if you can pin down what commands are being blocked that
 > are needed by K3B

growisofs from the dvd+rw tools doesn't work either with 2.6.8, not even
with suid bit set. So it seems that the 2.6.8.1 kernel keeps normal users
from writing CDs except when setting cdrecord suid, which I read on this
list would imply "some security bugs" (I don't know if that is true or not...)

But is that really the intention with 2.6.8.1 to give all programs for cd/dvd
writing the suid bit to allow users writing cds/dvds? (while even with
that at least k3b and growisofs fail at the moment)

At least this is a major change which I guess will make almost everyone
trying this kernel run into problems with cd writing :-(

cu,
Frank

-- 
Dipl.-Inform. Frank Steiner   Web:  http://www.bio.ifi.lmu.de/~steiner/
Lehrstuhl f. Bioinformatik    Mail: http://www.bio.ifi.lmu.de/~steiner/m/
LMU, Amalienstr. 17           Phone: +49 89 2180-4049
80333 Muenchen, Germany       Fax:   +49 89 2180-99-4049

Re: 2.6.8.1 Mis-detect CRDW as CDROM

[Kronos]

Alan Cox <alan@lxorguk.ukuu.org.uk> ha scritto:
> On Llu, 2004-08-16 at 13:38, Marc Ballarin wrote:
>> Due to the newly added command filtering, you now need to run cdrecord as
>> root. Since cdrecord will drop root privileges before accessing the drive,
>> setuid root won't help
> 
> cdrecord should be fine. k3b is issuing something not on the filter
> list.

cdrecord (from debian) does not work.

>> This patch restores the behaviour of previous kernels, security issues included:
> 
> Like allowing any user to erase your drive firmware. What you could do
> which is much more useful is printk the command byte that gets refused
> and see if you can pin down what commands are being blocked that
> are needed by K3B 

kronos:~$ cdrecord --version
Cdrecord-Clone 2.01a34 (i686-pc-linux-gnu) Copyright (C) 1995-2004 Jörg Schilling
NOTE: this version of cdrecord is an inofficial (modified) release of cdrecord
      and thus may have bugs that are not present in the original version.
      Please send bug reports and support requests to <cdrtools@packages.debian.org>.
      The original author should not be bothered with problems of this version.

This is mkisofs ... | cdrecord dev=/dev/hdd -tao - (as non-root user, I
have write access to the device):

verify_command: failed cmd 0x46
verify_command: failed cmd 0x46
verify_command: failed cmd 0x55
verify_command: failed cmd 0x55
verify_command: failed cmd 0x55
verify_command: failed cmd 0x55
verify_command: failed cmd 0x55
verify_command: failed cmd 0x55
verify_command: failed cmd 0x55
verify_command: failed cmd 0x55
verify_command: failed cmd 0x55
verify_command: failed cmd 0x55
verify_command: failed cmd 0x5c

This is cdrecord dev=/dev/hdd blank=fast:

verify_command: failed cmd 0x46
verify_command: failed cmd 0x46
verify_command: failed cmd 0x55
verify_command: failed cmd 0x55
verify_command: failed cmd 0x55
verify_command: failed cmd 0x55
verify_command: failed cmd 0x55
verify_command: failed cmd 0x55
verify_command: failed cmd 0x55
verify_command: failed cmd 0x55
verify_command: failed cmd 0x55
verify_command: failed cmd 0x55
verify_command: failed cmd 0x5c
verify_command: failed cmd 0x1e
verify_command: failed cmd 0x1
verify_command: failed cmd 0x55
verify_command: failed cmd 0x55
verify_command: failed cmd 0x55
verify_command: failed cmd 0x35
verify_command: failed cmd 0x55
verify_command: failed cmd 0x1e

0x55 is MODE_SELECT_10 (not listed in verify_command)
0x01 is REZERO_UNIT (not listed in verify_command)
0x1e is ALLOW_MEDIUM_REMOVAL (not listed in verify_command)
0x35 is SYNCHRONIZE_CACHE (not listed in verify_command)

I can't find 0x46 in scsi/scsi.h... but from cdrecord sources
(cdrecord/scsi_mmc.c):

/*
 * Get feature codes
 */
EXPORT int
get_configuration(scgp, bp, cnt, st_feature, rt)
        SCSI    *scgp;
        caddr_t bp;
        int     cnt;
        int     st_feature;
        int     rt;
{
        register struct scg_cmd *scmd = scgp->scmd;

        fillbytes((caddr_t)scmd, sizeof (*scmd), '\0');
        scmd->addr = bp;
        scmd->size = cnt;
        scmd->flags = SCG_RECV_DATA|SCG_DISRE_ENA;
        scmd->cdb_len = SC_G1_CDBLEN;
        scmd->sense_len = CCS_SENSE_LEN;
  --->  scmd->cdb.g1_cdb.cmd = 0x46; <--- 
        scmd->cdb.g1_cdb.lun = scg_lun(scgp);
        if (rt & 1)
                scmd->cdb.g1_cdb.reladr  = 1;
        if (rt & 2)
                scmd->cdb.g1_cdb.res  =  1;

        i_to_2_byte(scmd->cdb.g1_cdb.addr, st_feature);
        g1_cdblen(&scmd->cdb.g1_cdb, cnt);

        scgp->cmdname = "get_configuration";
        
        return (scg_cmd(scgp));
}

Luca
-- 
Home: http://kronoz.cjb.net
You and me baby ain't nothin' but mammals
So let's do it like they do on the Discovery Channel

Re: 2.6.8.1 Mis-detect CRDW as CDROM

[Marc Ballarin]

On Mon, 16 Aug 2004 14:03:06 +0100
Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:

> On Llu, 2004-08-16 at 13:38, Marc Ballarin wrote:
> > Due to the newly added command filtering, you now need to run cdrecord as
> > root. Since cdrecord will drop root privileges before accessing the drive,
> > setuid root won't help
> 
> cdrecord should be fine. k3b is issuing something not on the filter
> list.
> 
> > This patch restores the behaviour of previous kernels, security issues included:
> 
> Like allowing any user to erase your drive firmware. What you could do
> which is much more useful is printk the command byte that gets refused
> and see if you can pin down what commands are being blocked that
> are needed by K3B 
> 
> Alan
> 

cdrecord 2.01a28 wants:
when doing dev=/dev/dvd -atip:
OR
dev=/dev/cdrom blank=fast

0x46 0x55 0x1e 0x1 0x35

when trying to write:
0x46 0x55

dvd+rw-mediainfo wants:
0x46

k3b wants:
0x46 0x55 0xac

Those are all command I've seen so far:
0x1 REWIND
0x1e PREVENT ALLOW MEDIUM REMOVAL
0x35 SYNCHRONIZE_CACHE
0x46 ?
0x55 MODE SELECT(10)
0xac ERASE(12)

Here is the patch I've been using:

--- linux-2.6.8/drivers/block/scsi_ioctl.c.orig	2004-08-16 19:48:15.083524248 +0200
+++ linux-2.6.8/drivers/block/scsi_ioctl.c	2004-08-16 19:09:19.000000000 +0200
@@ -174,0 +175,2 @@
+	else	
+		printk(KERN_WARNING "FILTERED: %x \n", cmd[0]);

Re: 2.6.8.1 Mis-detect CRDW as CDROM

[Marc Ballarin]

Here are the additional commands I permit right now. It allows me to blank
a CDRW and record in TAO mode. k3b needs MODE_SELECT_10  even
for read-only access.



		safe_for_read(GPCMD_GET_CONFIGURATION),
		safe_for_read(GPCMD_GET_PERFORMANCE),
		safe_for_read(MODE_SELECT_10),

		safe_for_write(ALLOW_MEDIUM_REMOVAL),
		safe_for_write(REZERO_UNIT),
		safe_for_write(SYNCHRONIZE_CACHE),
		safe_for_write(GPCMD_SET_SPEED),
		safe_for_write(GPCMD_SEND_OPC),
		safe_for_write(GPCMD_BLANK),
		safe_for_write(GPCMD_CLOSE_TRACK),
		safe_for_write(0x5c), //whatever this might be

Shouldn't most GPCMD_* commands be safe for reading or writing, at least
for CD devices?
Are commands like MODE_SELECT_10 really safe for read?

Regards

Re: 2.6.8.1 Mis-detect CRDW as CDROM

[Kai Makisara]

On Mon, 16 Aug 2004, Marc Ballarin wrote:

> Here are the additional commands I permit right now. It allows me to blank
> a CDRW and record in TAO mode. k3b needs MODE_SELECT_10  even
> for read-only access.
> 
> 
> 
> 		safe_for_read(GPCMD_GET_CONFIGURATION),
> 		safe_for_read(GPCMD_GET_PERFORMANCE),
> 		safe_for_read(MODE_SELECT_10),
> 
> 		safe_for_write(ALLOW_MEDIUM_REMOVAL),
> 		safe_for_write(REZERO_UNIT),
> 		safe_for_write(SYNCHRONIZE_CACHE),
> 		safe_for_write(GPCMD_SET_SPEED),
> 		safe_for_write(GPCMD_SEND_OPC),
> 		safe_for_write(GPCMD_BLANK),
> 		safe_for_write(GPCMD_CLOSE_TRACK),
> 		safe_for_write(0x5c), //whatever this might be

                Read Buffer Capacity
> 
> Shouldn't most GPCMD_* commands be safe for reading or writing, at least
> for CD devices?
> Are commands like MODE_SELECT_10 really safe for read?
> 
Mode Select is not safe enough even for write (i.e., CAP_RAWIO must be 
required). Is it really necessary for Mode Select to succeed or do the 
applications just try to do something and fail gracefully?

-- 
Kai

Re: 2.6.8.1 Mis-detect CRDW as CDROM

[Marc Ballarin]

List of SCSI commands in cdrecord and k3b. Completeness and corectness are
not guaranteed and not even likely. Not all commands are actually used,
some are only for older hardware.

MODE_SELECT_* is not needed by cdrecord and fails gracefully as Kai
Makisara suspected. k3b seems broken, as it doesn't recognize devices as
writers if MODE_SELECT_10 fails (even when opening the device read-only).

Commands prepended by "->" are (probably) not mentioned in kernel include
files.

Now all that is left to do is determining which commands are safe and
fixing apps that only open devices read-only ;-)

0x00	TEST_UNIT_READY
0x01	REZERO_UNIT
0x03	REQUEST_SENSE
0x04	FORMAT_UNIT	k3b: declared, but not used
0x08	READ_6
0x0A	WRITE_6
0x0B	SEEK_6
-> 0x0D	/* qic02 Sysgen SC4000 */
0x12	INQUIRY / GPCMD_INQUIRY
0x15	MODE_SELECT
0x1A	MODE_SENSE
0x1B	GPCMD_START_STOP_UNIT
0x1E	GPCMD_PREVENT_ALLOW_MEDIUM_REMOVAL
0x23	GPCMD_READ_FORMAT_CAPACITIES
0x25	GPCMD_READ_CDVD_CAPACITY
0x28	GPCMD_READ_10
0x2A	GPCMD_WRITE_10
0x2B	GPCMD_SEEK
-> 0x2C	ERASE? k3b: declared, but not used
0x2E	GPCMD_WRITE_AND_VERIFY_10
0x2F	GPCMD_VERIFY_10
0x35	GPCMD_FLUSH_CACHE
0x3B	WRITE_BUFFER
0x3C	READ_BUFFER
0x42	GPCMD_READ_SUBCHANNEL
0x43	GPCMD_READ_TOC_PMA_ATIP
0x44	GPCMD_READ_HEADER
0x45	GPCMD_PLAY_AUDIO_10
0x46	GPCMD_GET_CONFIGURATION
0x47	GPCMD_PLAY_AUDIO_MSF
0x4A	GPCMD_GET_EVENT_STATUS_NOTIFICATION
0x4B	GPCMD_PAUSE_RESUME
0x4E	GPCMD_STOP_PLAY_SCAN
0x51	GPCMD_READ_DISC_INFO
0x52	GPCMD_READ_TRACK_RZONE_INFO
0x53	GPCMD_RESERVE_RZONE_TRACK
0x54	GPCMD_SEND_OPC
0x55	GPCMD_MODE_SELECT_10	k3b: needed even in read-only mode. Probably a bug.
0x58	GPCMD_REPAIR_RZONE_TRACK
-> 0x59	/* Read master cue */
0x5A	GPCMD_MODE_SENSE_10
0x5B	GPCMD_CLOSE_TRACK
-> 0x5C	/* Read buffer cap */
-> 0x5D	/* Send CUE sheet */	This is needed for DAO mode
0xA1	GPCMD_BLANK
0xA3	GPCMD_SEND_KEY
0xA4	GPCMD_REPORT_KEY
0xA5	MOVE_MEDIUM
0xA6	GPCMD_LOAD_UNLOAD
0xA7	GPCMD_SET_READ_AHEAD
0xA8	READ_12
0xAA	WRITE_12
0xAC	GPCMD_GET_PERFORMANCE
0xAD	GPCMD_READ_DVD_STRUCTURE
-> 0xB3	SC_SET_LIMITS
0xB6	GPCMD_SET_STREAMING
0xB9	GPCMD_READ_CD_MSF
0xBA	GPCMD_SCAN
0xBB	GPCMD_SET_SPEED
0xBD	GPCMD_MECHANISM_STATUS
0xBE	GPCMD_READ_CD
-> 0xBF
-> 0xC1
-> 0xC2	SC_SET_SUBCODE
-> 0xC3
-> 0xC4	SC_READ_PMA
-> 0xC5
-> 0xC6
-> 0xC7	SC_READ_DISK_INFO
-> 0xCE
-> 0xCF
-> 0xD4		/* Read audio command */
-> 0xD8		/* read audio command */
-> 0xDF
-> 0xE0	SC_BUFFER_INQUIRY
-> 0xE1	SC_WRITE_PMA
-> 0xE2
-> 0xE3	SC_FREEZE
-> 0xE4	SC_CLEAR_SUBCODE
-> 0xE5
-> 0xE6	SC_NEXT_WR_ADDRESS
-> 0xE7
-> 0xE9
-> 0xEB
-> 0xEC	SC_OPC_EXECUTE
-> 0xED
-> 0xEE	/* Read session info */
-> 0xEF	SC_READ_PEAK_BUF_CAP
-> 0xF0
-> 0xF1
-> 0xF2
-> 0xF3
-> 0xF5
-> 0xF6
-> 0xF8

Re: 2.6.8.1 Mis-detect CRDW as CDROM

[Frank Steiner]

Marc Ballarin wrote:
> List of SCSI commands in cdrecord and k3b. Completeness and corectness are
> not guaranteed and not even likely. Not all commands are actually used,
> some are only for older hardware.
> 
> MODE_SELECT_* is not needed by cdrecord and fails gracefully as Kai
> Makisara suspected. k3b seems broken, as it doesn't recognize devices as
> writers if MODE_SELECT_10 fails (even when opening the device read-only).
> 
> Commands prepended by "->" are (probably) not mentioned in kernel include
> files.
> 
> Now all that is left to do is determining which commands are safe and
> fixing apps that only open devices read-only ;-)

So what's the target in this process? Should users finally be able to
write cds again without or only with suid bit set? It would be good to
know if I should try to set all cd writing applications suid or just
have to wait for some patches coming up that would allow users to
write cds without suid again...

If the programs must be set suid, is that safe? In the past I was
always told that setting e.g. cdrecord suid was a possible security issue.
But I really don't understand enough of the new security model in the
kernel to judge if that's right or wrong...

Can someone enlighten me? :-)

cu,
Frank
-- 
Dipl.-Inform. Frank Steiner   Web:  http://www.bio.ifi.lmu.de/~steiner/
Lehrstuhl f. Bioinformatik    Mail: http://www.bio.ifi.lmu.de/~steiner/m/
LMU, Amalienstr. 17           Phone: +49 89 2180-4049
80333 Muenchen, Germany       Fax:   +49 89 2180-99-4049

Re: 2.6.8.1 Mis-detect CRDW as CDROM

[Andreas Messer]

Frank Steiner wrote:

> So what's the target in this process? Should users finally be able to
> write cds again without or only with suid bit set? It would be good to
> know if I should try to set all cd writing applications suid or just
> have to wait for some patches coming up that would allow users to
> write cds without suid again...

I have now reviewed my changes to allow users-cdrecording using 
the mmc4-spec 
  http://www.t10.org/ftp/t10/drafts/mmc4/mmc4r03a.pdf
Someone should check, if i set the permissions the right way. I have not used 
the infomation Marc Ballarin, as i think the spec is more recent than the 
programms. Perhaps there have some commands for old recorders to be added, 
but i'm not sure if so much people use such old recorders.
My changes also include some things for reading and playing cds. The rest of 
the commands mentioned in the mmc4-spec is already defined in the basic 
commands.

>
> If the programs must be set suid, is that safe? In the past I was
> always told that setting e.g. cdrecord suid was a possible security issue.
> But I really don't understand enough of the new security model in the
> kernel to judge if that's right or wrong...

I don't think setting an application suid is the right way. If the rules are 
changed the right way, rights for accessing devices may be set up clearer - 
eg one usergroup may use the recorder for recording and another not. If 
setting cdrecord siud root, this won't work.

>
> Can someone enlighten me? :-)
>
> cu,
> Frank

Here are my suggested changes:

-- linux-2.6.8.1/drivers/block/scsi_ioctl.c	2004-08-16 21:44:53.000000000 
+0200
+++ linux/drivers/block/scsi_ioctl.c	2004-08-17 13:04:04.000000000 +0200
@@ -156,6 +156,53 @@
 		safe_for_write(WRITE_16),
 		safe_for_write(WRITE_BUFFER),
 		safe_for_write(WRITE_LONG),
+
+
+		/* Some additional defs for recording/reading CDs */
+
+		/* 0x01 REZERO_UNIT used by k3b, but also work without */
+               
+		/* read-mode */
+		safe_for_read(GPCMD_GET_CONFIGURATION),
+		safe_for_read(GPCMD_GET_EVENT_STATUS_NOTIFICATION),
+		safe_for_read(GPCMD_GET_PERFORMANCE),
+		safe_for_read(GPCMD_MECHANISM_STATUS),
+
+		/* should this allowed for read ? */
+		safe_for_read(GPCMD_LOAD_UNLOAD),
+		safe_for_read(GPCMD_SET_SPEED),
+		safe_for_read(GPCMD_PAUSE_RESUME),   /* playing audio cd */
+		safe_for_read(SEEK_10),              /* playing audio cd */
+		safe_for_read(GPCMD_SET_READ_AHEAD),
+		safe_for_read(GPCMD_SET_STREAMING),
+		safe_for_read(GPCMD_STOP_PLAY_SCAN), /* playing audio cd */
+
+		/* k3b wont work without read - maybe bug in k3b, but 
+		   MODE_SELECT_10 seems not to be destructive */
+		safe_for_read(GPCMD_MODE_SELECT_10), 
+
+		/* write-mode */
+		safe_for_write(GPCMD_BLANK), 
+		safe_for_write(GPCMD_CLOSE_TRACK),
+		safe_for_write(0x2c),        /* ERASE_10 */ 
+		safe_for_write(GPCMD_FORMAT_UNIT),
+		safe_for_write(GPCMD_PREVENT_ALLOW_MEDIUM_REMOVAL),
+		safe_for_write(0x5c),        /* READ_BUFFER_CAPACITY */
+		safe_for_write(GPCMD_READ_FORMAT_CAPACITIES),
+		safe_for_write(GPCMD_REPAIR_RZONE_TRACK),
+		safe_for_write(GPCMD_RESERVE_RZONE_TRACK),
+		safe_for_write(0x5d),        /* SEND_CUE_SHEET */
+		safe_for_write(0xbf),        /* SEND_DVD_STRUCTURE */
+		safe_for_write(GPCMD_SEND_KEY),
+		safe_for_write(GPCMD_SEND_OPC),
+		safe_for_write(SYNCHRONIZE_CACHE),
+		safe_for_write(VERIFY),
+
+		/* Disabled, may change firmware 
+		   safe_for_write(0x3b),  WRITE_BUFFER */
+		/* Disabled due useless without WRITE_BUFFER 
+		   safe_for_write(0x3c),  READ_BUFFER */
+
 	};
 	unsigned char type = cmd_type[cmd[0]];
 
@@ -173,6 +220,14 @@
 	if (capable(CAP_SYS_RAWIO))
 		return 0;
 
+        /* Added for debugging*/
+       
+	if(file->f_mode & FMODE_WRITE)
+	  printk(KERN_WARNING "SCSI-CMD Filter: 0x%x not allowed with 
write-mode\n",cmd[0]);
+	else
+	  printk(KERN_WARNING "SCSI-CMD Filter: 0x%x not allowed with 
read-mode\n",cmd[0]);
+
+
 	/* Otherwise fail it with an "Operation not permitted" */
 	return -EPERM;
 }


regards
Andreas
-- 
gnuPG keyid: 0xE94F63B7 fingerprint: D189 D5E3 FF4B 7E24 E49D 7638 07C5 924C 
E94F 63B7

[PATCH] 2.6.8.1 Mis-detect CRDW as CDROM

[Andreas Messer]

Hello again,

as i get informed, that the kmail emailclient has not made
what i want, i decided to use mutt for next time. I will
include the patch again to make it readable. I have also
changed the thing with MODE_SELECT_10 to write mode 
because Christer Weinig figured out, that this CMD may
be insecure in connection with harddisks.
The changes to cdrom.h made by Marc Ballarin have not yet 
been included.
But i think, that the security model should made more 
precise - deciding only upon the commands does not give
the effekt of much improved security.

Here ist the patch.

--- linux-2.6.8.1/drivers/block/scsi_ioctl.c	2004-08-16 21:44:53.000000000 +0200
+++ linux/drivers/block/scsi_ioctl.c	2004-08-17 17:41:54.000000000 +0200
@@ -156,6 +156,54 @@
 		safe_for_write(WRITE_16),
 		safe_for_write(WRITE_BUFFER),
 		safe_for_write(WRITE_LONG),
+
+
+		/* Some additional defs for recording/reading CDs */
+
+		/* 0x01 REZERO_UNIT used by k3b, but also work without */
+               
+		/* read-mode */
+		safe_for_read(GPCMD_GET_CONFIGURATION),
+		safe_for_read(GPCMD_GET_EVENT_STATUS_NOTIFICATION),
+		safe_for_read(GPCMD_GET_PERFORMANCE),
+		safe_for_read(GPCMD_MECHANISM_STATUS),
+
+		/* should this allowed for read ? */
+		safe_for_read(GPCMD_LOAD_UNLOAD),
+		safe_for_read(GPCMD_SET_SPEED),
+		safe_for_read(GPCMD_PAUSE_RESUME),   /* playing audio cd */
+		safe_for_read(SEEK_10),              /* playing audio cd */
+		safe_for_read(GPCMD_SET_READ_AHEAD),
+		safe_for_read(GPCMD_SET_STREAMING),
+		safe_for_read(GPCMD_STOP_PLAY_SCAN), /* playing audio cd */
+
+		/* k3b wont work without read - maybe bug in k3b, but 
+		   MODE_SELECT_10 seems to destroy data in conjunction
+                   with harddisk */
+		safe_for_write(GPCMD_MODE_SELECT_10), 
+
+		/* write-mode */
+		safe_for_write(GPCMD_BLANK), 
+		safe_for_write(GPCMD_CLOSE_TRACK),
+		safe_for_write(0x2c),        /* ERASE_10 */ 
+		safe_for_write(GPCMD_FORMAT_UNIT),
+		safe_for_write(GPCMD_PREVENT_ALLOW_MEDIUM_REMOVAL),
+		safe_for_write(0x5c),        /* READ_BUFFER_CAPACITY */
+		safe_for_write(GPCMD_READ_FORMAT_CAPACITIES),
+		safe_for_write(GPCMD_REPAIR_RZONE_TRACK),
+		safe_for_write(GPCMD_RESERVE_RZONE_TRACK),
+		safe_for_write(0x5d),        /* SEND_CUE_SHEET */
+		safe_for_write(0xbf),        /* SEND_DVD_STRUCTURE */
+		safe_for_write(GPCMD_SEND_KEY),
+		safe_for_write(GPCMD_SEND_OPC),
+		safe_for_write(SYNCHRONIZE_CACHE),
+		safe_for_write(VERIFY),
+
+		/* Disabled, may change firmware 
+		   safe_for_write(0x3b),  WRITE_BUFFER */
+		/* Disabled due useless without WRITE_BUFFER 
+		   safe_for_write(0x3c),  READ_BUFFER */
+
 	};
 	unsigned char type = cmd_type[cmd[0]];
 
@@ -173,6 +221,14 @@
 	if (capable(CAP_SYS_RAWIO))
 		return 0;
 
+        /* Added for debugging*/
+       
+	if(file->f_mode & FMODE_WRITE)
+	  printk(KERN_WARNING "SCSI-CMD Filter: 0x%x not allowed with write-mode\n",cmd[0]);
+	else
+	  printk(KERN_WARNING "SCSI-CMD Filter: 0x%x not allowed with read-mode\n",cmd[0]);
+
+
 	/* Otherwise fail it with an "Operation not permitted" */
 	return -EPERM;
 }

[RFC] list of SCSI commands

[Marc Ballarin]

Hi,
I think the filtering mechanism needs to be refined before we can do
useful patches. I think it will be necessary to base filtering on
scsi_type from struct sg_scsi_id (in sg.h and scsi.h). Otherwise it will
be impossible to get functionality and safety for all devices.

I have compiled a long list of various SCSI commands and tried to
categorize them. This list is focused on mmc devices (CD-RW, DVD+R).
Many commands that are only relevant for discs are not included.

=UNCLEAR=
MODE SELECT should be safe for mmc devices (sometimes even required).
However, it often is *not* safe for other devices. This is a case,
were filtering needs to honor device types.
0x15	MODE_SELECT
0x55	MODE_SELECT_10
0x01	REZERO_UNIT

Here is a conflict between different device types. MOVE_MEDIUM for
changers; PLAY_AUDIO_12 for mmc. Are both cases safe for read?
0xA5	MOVE_MEDIUM

If I understand correctly, those commands can be used to initate
transfers between two devices. If so, read/write access to a single
device could be used to read/write all devices on the same bus.
0x18	COPY
0x39	COMPARE

I haven't found further information on the following commands. Some are
probably vendor specific. Annotations are from cdrecord.
-> 0x0D	/* qic02 Sysgen SC4000 */
-> 0x59	/* Read master cue */
-> 0xB3	GPMCD_SET_LIMITS_12
-> 0xC1
-> 0xC2	SC_SET_SUBCODE
-> 0xC3
-> 0xC4	SC_READ_PMA
-> 0xC5
-> 0xC6
-> 0xC7	SC_READ_DISK_INFO
-> 0xCE
-> 0xCF
-> 0xD4		/* Read audio command */
-> 0xD8		/* read audio command */
-> 0xDF
-> 0xE0	SC_BUFFER_INQUIRY
-> 0xE1	SC_WRITE_PMA
-> 0xE2
-> 0xE3	SC_FREEZE
-> 0xE4	SC_CLEAR_SUBCODE
-> 0xE5
-> 0xE6	SC_NEXT_WR_ADDRESS
-> 0xE7
-> 0xE9
-> 0xEB
-> 0xEC	SC_OPC_EXECUTE
-> 0xED
-> 0xEE	/* Read session info */
-> 0xEF	SC_READ_PEAK_BUF_CAP
-> 0xF0
-> 0xF1
-> 0xF2
-> 0xF3
-> 0xF5
-> 0xF6
-> 0xF8

=READ=
0x00	TEST_UNIT_READY
0x03	REQUEST_SENSE
0x08	READ_6
0x0B	SEEK_6
0x12	INQUIRY
0x1A	MODE_SENSE
0x23	GPCMD_READ_FORMAT_CAPACITIES
0x25	GPCMD_READ_CDVD_CAPACITY
0x28	READ_10
0x2B	SEEK_10
0x2F	GPCMD_VERIFY_10
0x3C	READ_BUFFER
0x42	GPCMD_READ_SUBCHANNEL
0x43	GPCMD_READ_TOC_PMA_ATIP
0x44	GPCMD_READ_HEADER	//not found in spec, _sounds_ safe
0x45	GPCMD_PLAY_AUDIO_10
0x46	GPCMD_GET_CONFIGURATION
0x47	GPCMD_PLAY_AUDIO_MSF
0x4A	GPCMD_GET_EVENT_STATUS_NOTIFICATION
0x4B	GPCMD_PAUSE_RESUME
0x4E	GPCMD_STOP_PLAY_SCAN
0x51	GPCMD_READ_DISC_INFO
0x52	GPCMD_READ_TRACK_RZONE_INFO
0x5A	MODE_SENSE_10
-> 0x5C	GPCMD_READ_BUFFER_CAPACITY
0x88	READ_16
0xA3	GPCMD_SEND_KEY
0xA4	GPCMD_REPORT_KEY
0xA6	GPCMD_LOAD_UNLOAD
0xA7	GPCMD_SET_READ_AHEAD
0xA8	READ_12
0xAC	GPCMD_GET_PERFORMANCE
0xAD	GPCMD_READ_DVD_STRUCTURE
0xB6	GPCMD_SET_STREAMING
0xB9	GPCMD_READ_CD_MSF
0xBA	GPCMD_SCAN
0xBB	GPCMD_SET_SPEED
0xBD	GPCMD_MECHANISM_STATUS
0xBE	GPCMD_READ_CD

=WRITE=
0x04	FORMAT_UNIT	// is this safe for disks?
0x0A	WRITE_6
0x2A	WRITE_10
0x2E	GPCMD_WRITE_AND_VERIFY_10
0x35	GPCMD_FLUSH_CACHE
0xAA	WRITE_12
0x8a	WRITE_16
0xA1	GPCMD_BLANK
0x53	GPCMD_RESERVE_RZONE_TRACK
0x54	GPCMD_SEND_OPC
0x58	GPCMD_REPAIR_RZONE_TRACK
0x5B	GPCMD_CLOSE_TRACK
0x1E	GPCMD_PREVENT_ALLOW_MEDIUM_REMOVAL
-> 0x5D	GPCMD_SEND_CUE
-> 0x2C	GPCMD_ERASE
-> 0xBF	GPCMD_SEND_DVD_STRUCTURE	

=RAWIO=
Some modes of WRITE_BUFFER are safe even for read, others
overwrite firmware. Misdesign.
0x3B	WRITE_BUFFER

0x07	REASSIGN_BLOCKS
0x16	RESERVE
0x17	RELEASE

Re: [RFC] list of SCSI commands

[Andreas Messer]

Hello,

On Tue, Aug 17, 2004 at 07:27:48PM +0200, Marc Ballarin wrote:
> Hi,
> I think the filtering mechanism needs to be refined before we can do
> useful patches. I think it will be necessary to base filtering on
> scsi_type from struct sg_scsi_id (in sg.h and scsi.h). Otherwise it will
> be impossible to get functionality and safety for all devices.

Yes, but some people want to use 2.6.8.1 instead of 2.6.7 (NFS security 
problem) and i only want to provide a short patch to get the old behavior.
Like You, i think  there should be device-class depend accesscontrol-lists. 
But this will need more performance. As there are not that many device 
classes, i would suggest to make one verify-function per device class and 
put a pointer in the file-struct, which will point to the suggested function

> 
> I have compiled a long list of various SCSI commands and tried to
> categorize them. This list is focused on mmc devices (CD-RW, DVD+R).
> Many commands that are only relevant for discs are not included.
> 
> =UNCLEAR=
> MODE SELECT should be safe for mmc devices (sometimes even required).
> However, it often is *not* safe for other devices. This is a case,
> were filtering needs to honor device types.
> 0x15	MODE_SELECT
> 0x55	MODE_SELECT_10
> 0x01	REZERO_UNIT

Yes, this is really a problem.

> I haven't found further information on the following commands. Some are
> probably vendor specific. Annotations are from cdrecord.

Hmm, perhaps i should compare them against the mmc4-spec? They might do 
nothing with mmc-drives?

> =WRITE=
> 0x04	FORMAT_UNIT	// is this safe for disks?

No, according to sbc2-spec it will format the entire harddisc.

> =RAWIO=
> Some modes of WRITE_BUFFER are safe even for read, others
> overwrite firmware. Misdesign.
> 0x3B	WRITE_BUFFER

According to spc3-spec (mentioned in sbc2) it will only used 
to check performance of the device or programm the firmware


-- 
gnuPG keyid: 0xE94F63B7 
fingerprint: D189 D5E3 FF4B 7E24 E49D 7638 07C5 924C E94F 63B7

Re: [PATCH] 2.6.8.1 Mis-detect CRDW as CDROM

[Martin Schlemmer]

[-- Attachment #1.1: Type: text/plain, Size: 1128 bytes --]

On Tue, 2004-08-17 at 17:59, Andreas Messer wrote:
> Hello again,
> 
> as i get informed, that the kmail emailclient has not made
> what i want, i decided to use mutt for next time. I will
> include the patch again to make it readable. I have also
> changed the thing with MODE_SELECT_10 to write mode 
> because Christer Weinig figured out, that this CMD may
> be insecure in connection with harddisks.
> The changes to cdrom.h made by Marc Ballarin have not yet 
> been included.
> But i think, that the security model should made more 
> precise - deciding only upon the commands does not give
> the effekt of much improved security.
> 
> Here ist the patch.
> 

I am probably missing something, but cant something like attached
work ?  I am definately not sure about the mode passed to the second
verify_command in sg_scsi_ioctl ... (Note I have never really hacked
anywhere near the scsi layer, or done userspace scsi coding, so be
nice =)

Patch is based on vanilla 2.6.8.1, with the bits from Andreas' last
patch, with MODE_SELECT_10 changed to read again.


Thanks,

-- 
Martin Schlemmer

[-- Attachment #1.2: SG-allow-users-cdrecording.patch --]
[-- Type: text/x-patch, Size: 4124 bytes --]

--- 1/drivers/block/scsi_ioctl.c	2004-08-17 21:36:57.680789648 +0200
+++ 2/drivers/block/scsi_ioctl.c	2004-08-17 21:35:54.000000000 +0200
@@ -110,7 +110,7 @@
 #define safe_for_read(cmd)	[cmd] = CMD_READ_SAFE
 #define safe_for_write(cmd)	[cmd] = CMD_WRITE_SAFE
 
-static int verify_command(struct file *file, unsigned char *cmd)
+static int verify_command(struct file *file, unsigned char *cmd, int mode)
 {
 	static const unsigned char cmd_type[256] = {
 
@@ -156,23 +156,90 @@
 		safe_for_write(WRITE_16),
 		safe_for_write(WRITE_BUFFER),
 		safe_for_write(WRITE_LONG),
+
+
+		/* Some additional defs for recording/reading CDs */
+
+		/* 0x01 REZERO_UNIT used by k3b, but also work without */
+               
+		/* read-mode */
+		safe_for_read(GPCMD_GET_CONFIGURATION),
+		safe_for_read(GPCMD_GET_EVENT_STATUS_NOTIFICATION),
+		safe_for_read(GPCMD_GET_PERFORMANCE),
+		safe_for_read(GPCMD_MECHANISM_STATUS),
+
+		/* should this allowed for read ? */
+		safe_for_read(GPCMD_LOAD_UNLOAD),
+		safe_for_read(GPCMD_SET_SPEED),
+		safe_for_read(GPCMD_PAUSE_RESUME),   /* playing audio cd */
+		safe_for_read(SEEK_10),              /* playing audio cd */
+		safe_for_read(GPCMD_SET_READ_AHEAD),
+		safe_for_read(GPCMD_SET_STREAMING),
+		safe_for_read(GPCMD_STOP_PLAY_SCAN), /* playing audio cd */
+
+		/* k3b wont work without read - maybe bug in k3b */ 
+		safe_for_read(GPCMD_MODE_SELECT_10), 
+
+		/* write-mode */
+		safe_for_write(GPCMD_BLANK), 
+		safe_for_write(GPCMD_CLOSE_TRACK),
+		safe_for_write(0x2c),        /* ERASE_10 */ 
+		safe_for_write(GPCMD_FORMAT_UNIT),
+		safe_for_write(GPCMD_PREVENT_ALLOW_MEDIUM_REMOVAL),
+		safe_for_write(0x5c),        /* READ_BUFFER_CAPACITY */
+		safe_for_write(GPCMD_READ_FORMAT_CAPACITIES),
+		safe_for_write(GPCMD_REPAIR_RZONE_TRACK),
+		safe_for_write(GPCMD_RESERVE_RZONE_TRACK),
+		safe_for_write(0x5d),        /* SEND_CUE_SHEET */
+		safe_for_write(0xbf),        /* SEND_DVD_STRUCTURE */
+		safe_for_write(GPCMD_SEND_KEY),
+		safe_for_write(GPCMD_SEND_OPC),
+		safe_for_write(SYNCHRONIZE_CACHE),
+		safe_for_write(VERIFY),
+
+		/* Disabled, may change firmware 
+		   safe_for_write(0x3b),  WRITE_BUFFER */
+		/* Disabled due useless without WRITE_BUFFER 
+		   safe_for_write(0x3c),  READ_BUFFER */
+
 	};
 	unsigned char type = cmd_type[cmd[0]];
 
-	/* Anybody who can open the device can do a read-safe command */
-	if (type & CMD_READ_SAFE)
-		return 0;
-
-	/* Write-safe commands just require a writable open.. */
-	if (type & CMD_WRITE_SAFE) {
-		if (file->f_mode & FMODE_WRITE)
+	switch (mode) {
+	case SG_DXFER_FROM_DEV:
+		/* Anybody who can open the device can do a read-safe
+		 * command */
+		if (type & CMD_READ_SAFE)
 			return 0;
+		break;
+	case SG_DXFER_TO_FROM_DEV:
+		/* We need to be able to read and write to the device.. */
+		if (type & CMD_WRITE_SAFE && type & CMD_READ_SAFE) {
+			if (file->f_mode & FMODE_WRITE)
+				return 0;
+		}
+		break;
+	case SG_DXFER_TO_DEV:
+		/* Write-safe commands just require a writable open.. */
+		if (type & CMD_WRITE_SAFE) {
+			if (file->f_mode & FMODE_WRITE)
+				return 0;
+		}
+		break;
 	}
 
 	/* And root can do any command.. */
 	if (capable(CAP_SYS_RAWIO))
 		return 0;
 
+        /* Added for debugging*/
+       
+	if(file->f_mode & FMODE_WRITE)
+	  printk(KERN_WARNING "SCSI-CMD Filter: 0x%x not allowed with write-mode\n",cmd[0]);
+	else
+	  printk(KERN_WARNING "SCSI-CMD Filter: 0x%x not allowed with read-mode\n",cmd[0]);
+
+
 	/* Otherwise fail it with an "Operation not permitted" */
 	return -EPERM;
 }
@@ -193,7 +260,7 @@
 		return -EINVAL;
 	if (copy_from_user(cmd, hdr->cmdp, hdr->cmd_len))
 		return -EFAULT;
-	if (verify_command(file, cmd))
+	if (verify_command(file, cmd, hdr->dxfer_direction))
 		return -EPERM;
 
 	/*
@@ -343,7 +410,7 @@
 	if (copy_from_user(buffer, sic->data + cmdlen, in_len))
 		goto error;
 
-	err = verify_command(file, rq->cmd);
+	err = verify_command(file, rq->cmd, in_len ? SG_DXFER_TO_DEV : SG_DXFER_FROM_DEV);
 	if (err)
 		goto error;
 

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [PATCH] 2.6.8.1 Mis-detect CRDW as CDROM

[Frank Steiner]

Andreas Messer wrote:
> Hello again,
> 
> as i get informed, that the kmail emailclient has not made
> what i want, i decided to use mutt for next time. I will
> include the patch again to make it readable. I have also
> changed the thing with MODE_SELECT_10 to write mode 
> because Christer Weinig figured out, that this CMD may
> be insecure in connection with harddisks.

Of course, cdrecord won't work this way... Anyway, I tried cdrecord and
growisofs with your patch and got some more blocked commands:

This happens with a cd in a plextor cd writer  PX-W5224:

zassenhaus [10:32] fst 105) cdrecord -dao dev=ATAPI:/dev/hdd test.img
...
Supported modes:
cdrecord: Drive does not support SAO recording.
cdrecord: Illegal write mode for this drive.

Aug 18 10:29:38 zassenhaus kernel: SCSI-CMD Filter: 0xe9 not allowed with read-mode
Aug 18 10:29:38 zassenhaus kernel: SCSI-CMD Filter: 0xe9 not allowed with read-mode
Aug 18 10:29:38 zassenhaus kernel: SCSI-CMD Filter: 0xed not allowed with read-mode
Aug 18 10:29:38 zassenhaus kernel: SCSI-CMD Filter: 0xe9 not allowed with read-mode
Aug 18 10:29:38 zassenhaus kernel: SCSI-CMD Filter: 0x55 not allowed with read-mode

Without a cd in the drive, it gives some more commands:
...
Device seems to be: Generic mmc CD-RW.
cdrecord: Operation not permitted. prevent/allow medium removal: scsi sendcmd: no error
CDB:  1E 00 00 00 00 00
status: 0x0 (GOOD STATUS)
cmd finished after 0.000s timeout 200s
Using generic SCSI-3/mmc   CD-R/CD-RW driver (mmc_cdr).
Driver flags   : MMC-3 SWABAUDIO BURNFREE
Supported modes:
cdrecord: Drive does not support SAO recording.
cdrecord: Illegal write mode for this drive.

Aug 18 10:39:26 zassenhaus kernel: SCSI-CMD Filter: 0x1e not allowed with read-mode
Aug 18 10:39:26 zassenhaus kernel: SCSI-CMD Filter: 0x1e not allowed with read-mode
Aug 18 10:39:31 zassenhaus kernel: SCSI-CMD Filter: 0xe9 not allowed with read-mode
Aug 18 10:39:31 zassenhaus kernel: SCSI-CMD Filter: 0xe9 not allowed with read-mode
Aug 18 10:39:31 zassenhaus kernel: SCSI-CMD Filter: 0xed not allowed with read-mode
Aug 18 10:39:31 zassenhaus kernel: SCSI-CMD Filter: 0xe9 not allowed with read-mode
Aug 18 10:39:34 zassenhaus kernel: SCSI-CMD Filter: 0x55 not allowed with read-mode


When calling the same command on a NEC ND1300A dvd writer, 0xe9 and 0xed
do not occur, the rest is identical.

"growisofs -Z /dev/hdd=test.img" on the NEC fails with
":-( unable to READ FORMAT CAPACITIES: Operation not permitted"

Aug 18 10:45:37 aiken kernel: SCSI-CMD Filter: 0x23 not allowed with read-mode

I will try to add all of those because we need to allow users to write
CDs at the moment, but I have no clue what is safe and unsafe here :-/

cu,
Frank

-- 
Dipl.-Inform. Frank Steiner   Web:  http://www.bio.ifi.lmu.de/~steiner/
Lehrstuhl f. Bioinformatik    Mail: http://www.bio.ifi.lmu.de/~steiner/m/
LMU, Amalienstr. 17           Phone: +49 89 2180-4049
80333 Muenchen, Germany       Fax:   +49 89 2180-99-4049

Re: [PATCH] 2.6.8.1 Mis-detect CRDW as CDROM

[Frank Steiner]

Oh, I missed one case: When calling cdrecord with no cd in the plextor
for the first time after booting, i.e., when /etc/hotplug/block.agent
(on SuSE 9.1) jumps in, I see a 0x1 additionally:

Aug 18 10:27:00 zassenhaus /etc/hotplug/block.agent[8396]: new block device /block/hdc
Aug 18 10:27:00 zassenhaus /etc/hotplug/block.agent[8397]: new block device /block/hdd
Aug 18 10:27:56 zassenhaus kernel: SCSI-CMD Filter: 0x1e not allowed with read-mode
Aug 18 10:28:01 zassenhaus kernel: SCSI-CMD Filter: 0x1 not allowed with read-mode
Aug 18 10:28:02 zassenhaus kernel: SCSI-CMD Filter: 0x1e not allowed with read-mode
Aug 18 10:28:02 zassenhaus kernel: SCSI-CMD Filter: 0xe9 not allowed with read-mode
...

The 0x1 does not appear afterwors anymore...

Does it, by the way, make any sense that I report this here? Or will the
security model have to be desgined first like you discussed it, before
such tests are helpful? Just to avoid that I flood you with a list of
blocked commands when you can't make any use of it now :-)

cu,
Frank

-- 
Dipl.-Inform. Frank Steiner   Web:  http://www.bio.ifi.lmu.de/~steiner/
Lehrstuhl f. Bioinformatik    Mail: http://www.bio.ifi.lmu.de/~steiner/m/
LMU, Amalienstr. 17           Phone: +49 89 2180-4049
80333 Muenchen, Germany       Fax:   +49 89 2180-99-4049

[RFC] New security model for scsi_cmd_ioctl

[Andreas Messer]

On Wed, Aug 18, 2004 at 11:09:44AM +0200, Frank Steiner wrote:

> Does it, by the way, make any sense that I report this here? Or will the
> security model have to be desgined first like you discussed it, before
> such tests are helpful? Just to avoid that I flood you with a list of
> blocked commands when you can't make any use of it now :-)

I don't know. The problem, is that the model has completely redesigned to
improve security, as some commands for mmc-drives are necessary 
(like FORMAT) and destructive on harddiscs. Marc and i think, that there 
should be a additional parameter for verify_command, which specifies the 
device class. 
The problem is, that there is now way to detect the device class within the 
functions sg_io and sg_scsi_ioctl or even scsi_cmd_ioctl (which calles the
other functions). So the parameter has to be given to scsi_cmd_ioctl. This
function is called within the kernel from cdrom.c, sd.c, st.c and ide.c but
i'm not sure, if there are another ways to call this function. (i'm not so
familar with the kernel source) If so, there may be no save way to hand 
over the device class. 
Then we need a new acl, based on device class and command. This list seems
to be very large - who maintains it? Perhaps it would be better to have
a linked list with some default values, which may be changed from 
userspace (like iptables). Another problem might be the SCSI sub-commands. 
I'm not sure, if they have to be checked too.

 
Andreas
-- 
gnuPG keyid: 0xE94F63B7 
fingerprint: D189 D5E3 FF4B 7E24 E49D 7638 07C5 924C E94F 63B7

Re: [PATCH] 2.6.8.1 Mis-detect CRDW as CDROM

[Frank Steiner]

Hi,

I guess I'm just a bit stupid, but I need some help to find out why :-)
I took Andreas patch and tried to add the commands that growisofs and
cdrecord need here on my system so that users could write cds again.

The resulting scsi_ioctl.c now looks like this:
...
                /* read-mode */
                safe_for_read(GPCMD_GET_CONFIGURATION),
                safe_for_read(GPCMD_GET_EVENT_STATUS_NOTIFICATION),
                safe_for_read(GPCMD_GET_PERFORMANCE),
                safe_for_read(GPCMD_MECHANISM_STATUS),
                safe_for_read(GPCMD_PREVENT_ALLOW_MEDIUM_REMOVAL),
                safe_for_read(REZERO_UNIT),
                safe_for_read(0xe9),
                safe_for_read(0xed),
                safe_for_read(GPCMD_MODE_SELECT_10),
                safe_for_read(GPCMD_READ_FORMAT_CAPACITIES),

                /* should this allowed for read ? */

where the last 6 safe_for_read commands were added. To make sure that
I really used this new scsi_ioctl.c I also changed the debugging output to

printk(KERN_WARNING "THIS IS MY NEW PATCH SCSI-CMD Filter...)

and compiled a new kernel from these sources. Booting it, I still cannot
use cdrecord or growisofs, although the new kernel is running. Trying
growisofs tells me again:

Aug 18 13:52:21 aiken kernel: THIS IS MY NEW PATCH SCSI-CMD Filter: 0x23 not allowed with read-mode

although 0x23 should be GPCMD_READ_FORMAT_CAPACITIES according to cdrom.h,
and that command is definitely allowed by (see above)

                safe_for_read(GPCMD_READ_FORMAT_CAPACITIES),

So it seems that the new commands that I added are just ignored and have
no effect when running growisofs as user.

How can that be? Am I missing sth? Is the order in which the commands
are added via safe_for_read important?

Any hints appreciated :-)
cu,
Frank

-- 
Dipl.-Inform. Frank Steiner   Web:  http://www.bio.ifi.lmu.de/~steiner/
Lehrstuhl f. Bioinformatik    Mail: http://www.bio.ifi.lmu.de/~steiner/m/
LMU, Amalienstr. 17           Phone: +49 89 2180-4049
80333 Muenchen, Germany       Fax:   +49 89 2180-99-4049

Re: [PATCH] 2.6.8.1 Mis-detect CRDW as CDROM

[Marc Ballarin]

On Wed, 18 Aug 2004 14:01:04 +0200
Frank Steiner <fsteiner-mail@bio.ifi.lmu.de> wrote:

> So it seems that the new commands that I added are just ignored and have
> no effect when running growisofs as user.
> 
> How can that be? Am I missing sth? Is the order in which the commands
> are added via safe_for_read important?
> 

growisofs and dvd+r-format open the device read-only, even though they try
to do writes.

Two choices:
1) declare all needed commands as safe for read (you might as well disable
filtering completely...)

2) replace O_RDONLY in dvd+r-tools sources with O_RDWR and recompile
(that's what I did).

Marc

Re: [PATCH] 2.6.8.1 Mis-detect CRDW as CDROM

[Frank Steiner]

Hi Marc,

Marc Ballarin wrote:

> growisofs and dvd+r-format open the device read-only, even though they try
> to do writes.
> 
> Two choices:
> 1) declare all needed commands as safe for read 

yes, that's what I tried, but it had no effect. For instance, I declared

                safe_for_read(GPCMD_READ_FORMAT_CAPACITIES),

which is 0x23, but growisofs still complains with

Aug 18 13:52:21 aiken kernel: THIS IS MY NEW PATCH SCSI-CMD Filter: 0x23 not allowed with read-mode

That's what I don't understand. I think the line above should declare
0x23 as safe for read, but it seems to be ignored.

 > (you might as well disable filtering completely...)

Likely I will end up with this :-/


> 
> 2) replace O_RDONLY in dvd+r-tools sources with O_RDWR and recompile
> (that's what I did).

I will check that!

cu,
Frank

-- 
Dipl.-Inform. Frank Steiner   Web:  http://www.bio.ifi.lmu.de/~steiner/
Lehrstuhl f. Bioinformatik    Mail: http://www.bio.ifi.lmu.de/~steiner/m/
LMU, Amalienstr. 17           Phone: +49 89 2180-4049
80333 Muenchen, Germany       Fax:   +49 89 2180-99-4049

Re: [PATCH] 2.6.8.1 Mis-detect CRDW as CDROM

[Frank Steiner]

Hi,

sorry, the problem was just caused by an empty line in front of a closing
bracket... This somehow removed some (although not all) of the safe_for_read
commands from the list.

I thought I had missed some piece of information here, but it were just my
bad editing skills :-)

Sorry for bothering! Everything works fine now that I added some commands.

Thanks for all your help!
cu,
Frank

-- 
Dipl.-Inform. Frank Steiner   Web:  http://www.bio.ifi.lmu.de/~steiner/
Lehrstuhl f. Bioinformatik    Mail: http://www.bio.ifi.lmu.de/~steiner/m/
LMU, Amalienstr. 17           Phone: +49 89 2180-4049
80333 Muenchen, Germany       Fax:   +49 89 2180-99-4049
* Rekursion kann man erst verstehen, wenn man Rekursion verstanden hat. *

Re: 2.6.8.1 Mis-detect CRDW as CDROM

[Christer Weinigel]

Frank Steiner <fsteiner-mail@bio.ifi.lmu.de> writes:

> So what's the target in this process? Should users finally be able to
> write cds again without or only with suid bit set? It would be good to
> know if I should try to set all cd writing applications suid or just
> have to wait for some patches coming up that would allow users to
> write cds without suid again...

As far as I can tell the goal is:

    With read permissions on the device you should be able to read
    from the device, such as ripping from a CD.  So all known commands
    that don't change the state of the CD should be ok.

    With write permissions you should be able to write to media, for
    example write to a tape or blank and burn a CDRW.

    For all unknown commands you need CAP_SYS_RAWIO (which for most
    system means root permissions).  So reflashing the firmware of a
    CD needs root permissions.

Some commands are a bit questionable though, for example, should it be
possible to use GPCMD_PREVENT_ALLOW_MEDIUM_REMOVAL with only read
permissions?  

The MODE_SELECT command I belive is needed for read on some tape
drives because tape parameters such as compression and tape density
are configured this way.  But there might be a device where a
MODE_SELECT on a vendor configuration page might destroy the device,
so it might not be such a good idea to allow MODE_SELECT and in that
case I don't know how it should be handled.

Hopefully all commands needed for CD/DVD reading and writing are safe
enough to be allowed with just read or write permission.

  /Christer

-- 
"Just how much can I get away with and still go to heaven?"

Freelance consultant specializing in device driver programming for Linux 
Christer Weinigel <christer@weinigel.se>  http://www.weinigel.se

Re: 2.6.8.1 Mis-detect CRDW as CDROM

[Christer Weinigel]

Following up to myself...

Christer Weinigel <christer@weinigel.se> writes:

> Some commands are a bit questionable though, for example, should it be
> possible to use GPCMD_PREVENT_ALLOW_MEDIUM_REMOVAL with only read
> permissions?  
> 
> The MODE_SELECT command I belive is needed for read on some tape
> drives because tape parameters such as compression and tape density
> are configured this way.  But there might be a device where a
> MODE_SELECT on a vendor configuration page might destroy the device,
> so it might not be such a good idea to allow MODE_SELECT and in that
> case I don't know how it should be handled.

I just did a quick google search on "MODE SELECT" and "vendor" and
found the following documentation for an IBM DeskStar driver:

    http://www.embeddedlogic.com/TH99/h/txt/1478.txt

    Page 0
    Vendor Unique Parameters
    UQE - Untagged Queuing Enable (1)
    DWD - Disable Write Disconnect (0)
    UAI - Unit Attention Inhibit (0)
    CPE - Concurrent Processing Enable (1)
    TCC - Thermal Compensation (0)
    DSN Disable Target Initiated Synchronous Negotiation (0)
    FRDD Format Degraded (1)
    DRD - Disable Read Disconnect (1)

Allowing a user who is only supposed to have write access to a raw
partition to disable read or write disconnect does not seem like such
a hot idea, so MODE SELECT should probably be disallowed unless
someone writes a verify function that looks for safe bits in the
page.  

This could get a bit painful.

  /Christer

-- 
"Just how much can I get away with and still go to heaven?"

Freelance consultant specializing in device driver programming for Linux 
Christer Weinigel <christer@weinigel.se>  http://www.weinigel.se

Re: 2.6.8.1 Mis-detect CRDW as CDROM

[Marc Ballarin]

On 17 Aug 2004 13:29:45 +0200
Christer Weinigel <christer@weinigel.se> wrote:

> ...
> Some commands are a bit questionable though, for example, should it be
> possible to use GPCMD_PREVENT_ALLOW_MEDIUM_REMOVAL with only read
> permissions?  
> 
> The MODE_SELECT command I belive is needed for read on some tape
> drives because tape parameters such as compression and tape density
> are configured this way.  But there might be a device where a
> MODE_SELECT on a vendor configuration page might destroy the device,
> so it might not be such a good idea to allow MODE_SELECT and in that
> case I don't know how it should be handled.
> 

That's the biggest problem. I fear it might be necessary to make checks
device specific (at least for device classes) *and* even include operation
modes.
For example WRITE BUFFER in default mode would be safe and maybe useful
for read. However it can also be used to overwrite firmware, which makes it
unsafe even for regular write.

> Hopefully all commands needed for CD/DVD reading and writing are safe
> enough to be allowed with just read or write permission.
> 

The question is how other device types will interpret some of those commands.

Regards

Re: 2.6.8.1 Mis-detect CRDW as CDROM

[Marc Ballarin]

On Tue, 17 Aug 2004 08:32:41 +0200
Frank Steiner <fsteiner-mail@bio.ifi.lmu.de> wrote:

> So what's the target in this process? Should users finally be able to
> write cds again without or only with suid bit set? It would be good to
> know if I should try to set all cd writing applications suid or just
> have to wait for some patches coming up that would allow users to
> write cds without suid again...
> 
> If the programs must be set suid, is that safe? In the past I was
> always told that setting e.g. cdrecord suid was a possible security
> issue.

An unpatched cdrecord does not use root privileges to access devices. It
increases its priority, locks memory and drops privileges before doing
anything else. According to its author, cdrecord is designed for this mode
of operation. I don't know if the same is true for growisofs and other
tools.
suid has no effect on the issue at hand (provided cdrecord has not
been modified), it only serves to increase burning reliability.

Regards

Re: 2.6.8.1 Mis-detect CRDW as CDROM

[Petri Kaukasoina]

On Tue, Aug 17, 2004 at 01:41:33PM +0200, Marc Ballarin wrote:
> An unpatched cdrecord does not use root privileges to access devices. It
> increases its priority, locks memory and drops privileges before doing
> anything else. According to its author, cdrecord is designed for this mode
> of operation. I don't know if the same is true for growisofs and other
> tools.
> suid has no effect on the issue at hand (provided cdrecord has not
> been modified), it only serves to increase burning reliability.

I guess you are talking about some alpha version. The latest released
unpatched stable version cdrecord 2.00.3 burns ok as suid-root even with
this kind of device access rights:

brw-------  1 root root 22, 0 Jun  9  2002 /dev/hdc

[PATCH] update defines in cdrom.h

[Marc Ballarin]

This adds four commands defined in mmc4 spec to cdrom.h. I used the
official names and simply added the GPCMD prefix. This is a prerequisite
for improving filtering.

Some commands that are used in software but not mentioned in specs are
still missing.

Marc


--- linux-2.6.8/include/linux/cdrom.h.orig	2004-08-14 12:26:34.000000000 +0200
+++ linux-2.6.8/include/linux/cdrom.h	2004-08-17 16:14:41.580823560 +0200
@@ -481,4 +481,8 @@
 #define GPCMD_WRITE_10			    0x2a
 #define GPCMD_WRITE_AND_VERIFY_10	    0x2e
+#define GPCMD_READ_BUFFER_CAPACITY	    0x5C
+#define GPCMD_SEND_CUE			    0x5D
+#define GPCMD_ERASE			    0x2C
+#define GPCMD_SEND_DVD_STRUCTURE	    0xBF
 /* This is listed as optional in ATAPI 2.6, but is (curiously) 
  * missing from Mt. Fuji, Table 57.  It _is_ mentioned in Mt. Fuji

Re: [PATCH] update + fix defines in cdrom.h

[Marc Ballarin]

Improved version of the previous patch.
Use lower case letters + fix a real bug: SEND_DVD_STRUCTURE was defined
as 0xad, which is actually READ_DVD_STRUCTURE.
The only user is ide-cd.h, which uses it for simple information printing.

Marc

--- linux-2.6.8/include/linux/cdrom.h.orig	2004-08-14 12:26:34.000000000 +0200
+++ linux-2.6.8/include/linux/cdrom.h	2004-08-17 17:13:08.508689488 +0200
@@ -469,5 +469,5 @@
 #define GPCMD_SCAN			    0xba
 #define GPCMD_SEEK			    0x2b
-#define GPCMD_SEND_DVD_STRUCTURE	    0xad
+#define GPCMD_SEND_DVD_STRUCTURE	    0xbf
 #define GPCMD_SEND_EVENT		    0xa2
 #define GPCMD_SEND_KEY			    0xa3
@@ -481,4 +481,8 @@
 #define GPCMD_WRITE_10			    0x2a
 #define GPCMD_WRITE_AND_VERIFY_10	    0x2e
+#define GPCMD_READ_BUFFER_CAPACITY	    0x5c
+#define GPCMD_SEND_CUE			    0x5d
+#define GPCMD_ERASE			    0x2c
+#define GPCMD_READ_DVD_STRUCTURE	    0xad
 /* This is listed as optional in ATAPI 2.6, but is (curiously) 
  * missing from Mt. Fuji, Table 57.  It _is_ mentioned in Mt. Fuji

Re: 2.6.8.1 Mis-detect CRDW as CDROM

[Petri Kaukasoina]

On Mon, Aug 16, 2004 at 02:38:17PM +0200, Marc Ballarin wrote:
> On Sun, 15 Aug 2004 14:43:53 -0700
> John Wendel <jwendel10@comcast.net> wrote:
> 
> > K3B detects my Lite-on LTR-52327S CDRW as a CDROM when run with 2.6.8.1.
> 
> Due to the newly added command filtering, you now need to run cdrecord as
> root. Since cdrecord will drop root privileges before accessing the drive,
> setuid root won't help.


I can't confirm this.

I also have LITE-ON LTR-52327S and suid-root cdrecord burns just fine with
kernel 2.6.8.1. It's cdrecord 2.00.3 from Slackware. (I don't use any
graphic front end). cdrecord -checkdrive tells among other things this:
Supported modes: TAO PACKET SAO SAO/R96P SAO/R96R RAW/R16 RAW/R96P RAW/R96R

Re: 2.6.8.1 Mis-detect CRDW as CDROM

[Wolfgang Scheicher]

John Wendel wrote:

> K3B detects my Lite-on LTR-52327S CDRW as a CDROM when run with 2.6.8.1.
> Booting back into 2.6.7 corrects the problem.

I have the same problem.
I found out that cdrecord has a empty Line for the supported modes.
( not k3b fault )

cdrecord -checkdrive with kernel 2.6.7 (vanilla) gives:
Supported modes: TAO PACKET SAO SAO/R96P SAO/R96R RAW/R16 RAW/R96P RAW/R96R
with kernel 2.6.8 :
Supported modes:      ( the rest is blank )

Trying to burn anyway leads to "not supported mode" messages.

my system: Athlon on nforce2 board, LITE-ON brenner LTR-52327S, gcc 3.4.1

Worf

Re: 2.6.8.1 Mis-detect CRDW as CDROM

[Adam Jones]

In a futile gesture against entropy, Wolfgang Scheicher wrote:
> John Wendel wrote:
> 
> > K3B detects my Lite-on LTR-52327S CDRW as a CDROM when run with 2.6.8.1.
> > Booting back into 2.6.7 corrects the problem.

> I have the same problem.
> I found out that cdrecord has a empty Line for the supported modes.
> ( not k3b fault )

For the record, this also seems to have affected growisofs.  Running it
setuid root doesn't help, since it drops privileges before burning
(and thus I imagine it now ends up dropping too many privileges...).

Would the correct plan of attack here be to send fixes to the authors
of the various media-burning tools to make sure that they keep
CAP_SYS_RAWIO when dropping privileges?  (Are any other capabilities
required?)
-- 
Adam Jones (adam@yggdrasl.demon.co.uk)(http://www.yggdrasl.demon.co.uk/)
.oO("*ahem*"                                                           )
PGP public key: http://www.yggdrasl.demon.co.uk/pubkey.asc

Re: 2.6.8.1 Mis-detect CRDW as CDROM

[Wolfgang Scheicher]

Am Montag, 16. August 2004 16:10 schrieben Sie:
> On Llu, 2004-08-16 at 13:38, Marc Ballarin wrote:
>> Due to the newly added command filtering, you now need to run cdrecord as
>> root. Since cdrecord will drop root privileges before accessing the
>> drive, setuid root won't help
>
> cdrecord should be fine. k3b is issuing something not on the filter
> list.

unfortunately this isn't so

cdrecord itself only works as root
as user, the list of supported modes remains empty, and trying to burn anway 
gives the error
cdrecord: Drive does not support <whatever i try> recording.
cdrecord: Illegal write mode for this drive.

k3b is just a frontend. the reaction on the empty modes list is quite correct 
actually, because cdrecord itself behaves the same

Worf

Re: 2.6.8.1 Mis-detect CRDW as CDROM

[Frank Steiner]

Wolfgang Scheicher wrote:

> unfortunately this isn't so
> 
> cdrecord itself only works as root
> as user, the list of supported modes remains empty, and trying to burn anway 
> gives the error
> cdrecord: Drive does not support <whatever i try> recording.
> cdrecord: Illegal write mode for this drive.

It should work as user when the suid bit it set.

-- 
Dipl.-Inform. Frank Steiner   Web:  http://www.bio.ifi.lmu.de/~steiner/
Lehrstuhl f. Bioinformatik    Mail: http://www.bio.ifi.lmu.de/~steiner/m/
LMU, Amalienstr. 17           Phone: +49 89 2180-4049
80333 Muenchen, Germany       Fax:   +49 89 2180-99-4049

Re: 2.6.8.1 Mis-detect CRDW as CDROM

[Giacomo Perale]

cdrecord 2.00.3 seems to work flawlessy even if it isn't set suid, but
everyone I know noticed the problem with cdrecord 2.01alphaXX (checked
with alpha28, alpha33 and alpha36).

Re: 2.6.8.1 Mis-detect CRDW as CDROM

[Joerg Schilling]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 2622 bytes --]

>If the programs must be set suid, is that safe? In the past I was
>always told that setting e.g. cdrecord suid was a possible security issue.
>But I really don't understand enough of the new security model in the
>kernel to judge if that's right or wrong...

Judging from the number of reports, I would guess that the Linux kernel is
much more insecure than cdrecord.

What some people did (chmod on /dev/ entries) was definitely always a bigger
security risk than running cdrecord suid root.

What SuSE tries (writing a resource manager) is also a bigger security risk
then cdrecord itself (at least as long as it is not done decently).

There has been only one expliot for cdrecord so far and a fix has been available
within hours (long before the exploit has been made public). There has been
one additional possible buffer overflow (reported by the author of the SuSE 
resource manager who did not respond after I told him why the SuSE resource 
manager is a security risk).

Cdrecord has been converted to run with effective id 0 only in the start up 
phase 1.5 years ago. It has been enabled to work with Sun's security 
enhancements (euid 0 is needed for ioctl USCSI) 8 months ago.

If Linux believes that there should be enhanced security similar to Solaris and 
if Linux is a true open Source business, then I would expect that there is 
cooperation. If I change things in e.g. mkisofs or cdrecord that could result
in problems for my "users", I send a notification mail to the XCDRoast & k3b 
authors early enough.

If Linux plans to implement incompatible changes, I would expect that 
"important users" are informed in advance so that it is possible to discuss the 
problems an to have a planned smooth migration. As this did not happen, the 
change needs to be called a bug. This is even more obvious if we take into 
account that cdrtools curently is in code freeze state as a 2.01-final will 
come the next days.

For this reason, I would recommend that Linux immediately goes back to the old
behavior and informs "important users". A change that has effects that are as
widely as this one should not be tried again within the next 3 months. Then 
there is a change to have a smooth migration......

BTW: I try to inform my "important users" more than a year before I introduce
important changes.



Jörg

-- 
 EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
       js@cs.tu-berlin.de		(uni)  If you don't have iso-8859-1
       schilling@fokus.fraunhofer.de	(work) chars I am J"org Schilling
 URL:  http://www.fokus.fraunhofer.de/usr/schilling ftp://ftp.berlios.de/pub/schily

Re: 2.6.8.1 Mis-detect CRDW as CDROM

[Andreas Messer]

Joerg Schilling wrote:
> Judging from the number of reports, I would guess that the Linux kernel is
> much more insecure than cdrecord.
>
> What some people did (chmod on /dev/ entries) was definitely always a
> bigger security risk than running cdrecord suid root.

I, dont think, that running cdrecord suid root is a risk, but i think, that 
there are much more cd-recording applications, not based on cdrecord, which 
may be insecure. Or perhaps someone will write a little programm, wich will 
override the firmware.
I think its a good way to filter the commands within the kernel. Its a 
additional security-barrage. 

Andreas
-- 
gnuPG keyid: 0xE94F63B7 fingerprint: D189 D5E3 FF4B 7E24 E49D 7638 07C5 924C 
E94F 63B7

Re: 2.6.8.1 Mis-detect CRDW as CDROM

[Joerg Schilling]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 2488 bytes --]

>From: Andreas Messer <andreas.messer@gmx.de>
>Joerg Schilling wrote:
>> Judging from the number of reports, I would guess that the Linux kernel is
>> much more insecure than cdrecord.
>>
>> What some people did (chmod on /dev/ entries) was definitely always a
>> bigger security risk than running cdrecord suid root.

>I, dont think, that running cdrecord suid root is a risk, but i think, that 
>there are much more cd-recording applications, not based on cdrecord, which 
>may be insecure. Or perhaps someone will write a little programm, wich will 
>override the firmware.
>I think its a good way to filter the commands within the kernel. Its a 
>additional security-barrage. 

I did not say that it should not be done at all. I only don't like that it
has been introduced without warning.

Next week, I will publish cdrtools-2.01-final and thus there is code freeze now.
Only extreme bugs _inside_ cdrtools will be fixed and only if this is possible
with knowing all side effects.

As I already wrote: libscg already has the ability to switch to euid 0 before
a SCSI command is send and to switch back to the old euid directly after the 
SCSI command returns. But this has only been introduced and tested on Solaris.
Making it work on Linux too would be a feature extension which is not possible
while in code freeze.

Also note that it is questionable whether this change really increases the 
security. In case that the check is only done at open() time, cdrecord could
later switch into a state that does not allow to become root again later.
In case you need root privs for sending generic SCSI, cdrecord needs to keep
its ability to become root again later. If there was a possible buffer overrun
problem, then a user could just push seteuid(0) before execl("/bin/sh".....
when creating an expliot.


Of course, all security issues that are independent from buffer overflows
will not happen with a uid switching cdrecord.

In general, applications that directly access hardware should be audited to be
secure and trusted. 

BTW: I am planning to make cdrecord usable on a rootless Solaris 10 in the 
near future. You then of course would need to use pfksh as your shell.

Jörg

-- 
 EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
       js@cs.tu-berlin.de		(uni)  If you don't have iso-8859-1
       schilling@fokus.fraunhofer.de	(work) chars I am J"org Schilling
 URL:  http://www.fokus.fraunhofer.de/usr/schilling ftp://ftp.berlios.de/pub/schily

Re: 2.6.8.1 Mis-detect CRDW as CDROM

[Andreas Messer]

Joerg Schilling wrote:
> I did not say that it should not be done at all. I only don't like that it
> has been introduced without warning.

I don't like the way, new features are introduced into or old things are 
removed from kernel, too. But i think, it makes no sense for me to complain 
about, as i'm not that linux-kernel-guru. I hope, the patch i posted or 
another one doing the same, will be accepted to allow users to burn again.
Some fine-tuning is still necessary.

Andreas
-- 
gnuPG keyid: 0xE94F63B7 fingerprint: D189 D5E3 FF4B 7E24 E49D 7638 07C5 924C 
E94F 63B7