Brennprogramme SUID-root setzen?

[0815Chaot]

Hallo,

habt ihr euch schon mal überlegt, die Programme zum Brennen von CDs/DVDs SUID-root zu setzen, damit jeder Anwender Datenträger brutzeln kann? Das habe ich jetzt testweise gemacht. Tatsächlich kann man als normaler Benutzer nun problemlos CDs und DVDs brennen.

Jetzt kommt natürlich die Frage nach der Sicherheit. Ein Anwender soll selbstverständlich keine Dateien/Verzeichnisse brennen können, auf die er eigentlich keine Leserechte besitzt - trotz SUID-root. cdrecord(1) und growisofs(1) scheinen das auch ganz gut hinzubekommen. Dazu habe ich folgendes als nicht-priviligierter Benutzer ausgeführt:

> touch TEST
> chmod 000 TEST

> cdrecord dev=1,0,0 TEST
cdrecord: Permission denied. No read access for 'TEST'.

> growisofs -Z /dev/cd0 TEST
WARNING: /dev/cd0 already carries isofs!
About to execute 'mkisofs TEST | builtin_dd of=/dev/pass0 obs=32k seek=0'
mkisofs: Permission denied. File TEST is not readable - ignoring
Total translation table size: 0
Total rockridge attributes bytes: 0
Total directory bytes: 0
Path table size(bytes): 10
Max brk space used 7ac4
48 extents written (0 Mb)
/dev/pass0: "Current Write Speed" is 4.1x1385KBps.
builtin_dd: 48*2KB out @ average infx1385KBps
/dev/pass0: flushing cache
/dev/pass0: stopping de-icing
/dev/pass0: writing lead-out

> growisofs -Z /dev/cd0=TEST
:-( unable to open64("TEST",O_RDONLY): Permission denied

Zum Lesen von Dateien werden die root-Rechte brav abgelegt. Außerdem ruft growisofs(1) das mkisofs(8) nicht mit der effektiven UID auf, sehr schön.

Da man aber ja schnell was übersehen kann, würde ich gerne möglichst viele Meinungen einholen. Gibt es von eurer Seite her irgenwelche Sicherheitsbedenken gegen SUID-root-Brennprogramme? Vielleicht habe ich einen Schalter/ein Szenario übersehen, mit dem ein Benutzer Blödsinn treiben könnte.

 

[ouTi]

da geb ich meinem user oder der benutzergruppe lieber rechte auf die cd-devices direkt

und zusätzlich zum mounten rechte auf den mount-point und vfs.usermount=1

 

[0815Chaot]

da geb ich meinem user oder der benutzergruppe lieber rechte auf die cd-devices direkt

Dann mußt du aber den ganzen CAM-Layer freigeben. Da habe ich keine Lust drauf, vor allem, da einige Rechner auch SCSI-Platten besitzen.

und zusätzlich zum mounten rechte auf den mount-point und vfs.usermount=1

Hat aber nichts mit der Frage zu tun.

 

[MrFixit]

Wenn keine "echte" SCSI Hardware verwendet wird, und man auch sonst nix ueber CAM angebunden hat (USB/Firewire-Platten/Sticks) dann empfehle ich folgendes in /dev/devfs.conf

own     cd0     root:operator
perm    cd0     0664
perm    xpt0    0660
perm    pass0   0660
own     acd0    root:operator
perm    acd0    0664

Dann muss man sich noch in die Operator-Gruppe packen und fertig ist das root-lose brennen. Mich nerven dann nur die "tollen" Warnungen von cdrecord, dass es nicht als root laeuft und nicht mlock verwenden kann. Das habe ich aber rausgepatcht, schliesslich kann mein Brenner Burnproof (oder wie das heisst) und da kann mir das Scheduling egal sein.

Immer diese Annahmen, dass man unter "Linux" nur als Root brennen kann. Und das dann auch noch vom Joerg ... tsss

 

[0815Chaot]

@MrFixit:

Nochmal: Weder will ich den ganzen CAM-Layer freigeben noch war das die Frage, über die hier abgestimmt werden soll.

Und bevor du Leute in die Gruppe operator packst, solltest du mal gucken, daß diese Gruppe auf alle Festplattenpartitionen Lesezugriff hat. In solche Gruppen stecke ich mit Sicherheit keinen Anwender rein.

Ehrlich gesagt ist dieses Verfahren viel umständlicher als ein SUID-root und zudem noch wesentlich unsicherer.

@Die zwei Leute, die "Nein" gestimmt haben:

Es war um eine Begründung gebeten, warum SUID-root-Brennprogramme bedenklich sind. Einfach nur "Nein, das ist gefährlich" ist wohl keine Aussage, mit der irgendwer was anfangen kann.

 

[MrFixit]

Dann macht man halt eine spezielle Gruppe ("user" zum Beispiel, D'oh!). Umstaendlich finde ich das nicht, im Gegenteil, das ganze ueberlebt sowohl portupgrades als auch das Wechseln der Brennprogramme. Wenn du wirklich viele User hast, dann will schliesslich jeder seine eigene Brenn-GUI.

Desweiteren koennen die Leute dann in vollem Umfang auf ihre USB/Firewire-Platten/Sticks zugreifen. Nur beim Multiuser-Zugriff wird's etwas haarig.

 

[Björn König]

Und bevor du Leute in die Gruppe operator packst, solltest du mal gucken, daß diese Gruppe auf alle Festplattenpartitionen Lesezugriff hat. In solche Gruppen stecke ich mit Sicherheit keinen Anwender rein.

... und 'ls -l /sbin/shutdown'

Dann macht man halt eine spezielle Gruppe ("user" zum Beispiel, D'oh!).

Nero macht das unter Windows übrigens genauso. Es wird eine Gruppe angelegt der die Benutzer angehören müssen, die brennen dürfen sollen.


Björn

 

[0815Chaot]

Wenn du wirklich viele User hast, dann will schliesslich jeder seine eigene Brenn-GUI.

Die GUIs sind auch nur Frontends für cdrecord(1)/growisofs(1), denke ich doch mal. Also selbst wenn jeder seine eigene GUI wollte (was bis jetzt noch nicht vorgekommen ist), sollte das kein Problem darstellen.

Desweiteren koennen die Leute dann in vollem Umfang auf ihre USB/Firewire-Platten/Sticks zugreifen.

Das will ich nicht und darum geht's auch nicht.

... und 'ls -l /sbin/shutdown'

-r-sr-x---  1 root  operator  10200  5 Nov  2004 /sbin/shutdown

Bezug zum Thema?

Nero macht das unter Windows übrigens genauso.

Windows ist ja wohl nicht wirklich die Referenz, wenn ich nach Sicherheit frage. Ein SUID-Bit kennt Windows sowieso nicht - das war aber ebenfalls nicht die Frage.

Also, da es keine Sicherheitsbedenken gegen SUID-root-Brennprogramme zu geben scheint (die zwei Nein-Stimmen haben jedenfalls keine Begründung abgegeben), geht das dann so ok.

 

[Björn König]

Bezug zum Thema?

Der gleiche wie bei

Und bevor du Leute in die Gruppe operator packst, solltest du mal gucken, daß diese Gruppe auf alle Festplattenpartitionen Lesezugriff hat. In solche Gruppen stecke ich mit Sicherheit keinen Anwender rein.