Re: 2.6.8.1 Mis-detect CRDW as CDROM

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

[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

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

[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

[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

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

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

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