2.6.8.1 Mis-detect CRDW as CDROM

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 ([email protected]) (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

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

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

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:

@@ -196 +196 @@
-	if (verify_command(file, cmd))
+/*	if (verify_command(file, cmd))

@@ -198 +198 @@
-
+*/

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

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

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

Hi,

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

Alan Cox <[email protected]> ha scritto:

cdrecord (from debian) does not work.

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 <[email protected]>.
      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

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:

@@ -174,0 +175,2 @@
+	else	
+		printk(KERN_WARNING "FILTERED: %x \n", cmd[0]);

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

Read Buffer Capacity

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

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

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

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.

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.

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

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

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 <[email protected]>  http://www.weinigel.se

Following up to myself...

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 <[email protected]>  http://www.weinigel.se

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

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.

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

Regards

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

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

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

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

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.

@@ -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;
 }

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

Hello,

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

Yes, this is really a problem.

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

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

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

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

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

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

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

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

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

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

Hi Marc,

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.

Likely I will end up with this :-/

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

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