Wurzelverzeichnis mit Rechten 777?

[mehle]

Hallo,

warum hat das Wurzelverzeichnis mit die Rechte 777? Ja, ich weiss, dass die meisten Programme als root laufen, aber einige eben nicht - aus gutem Grund.

Sollten wir denn nicht / mit den Rechten 755 mounten?

Danke
Stephan

 

[olistudent]

Ich wüßte nicht, dass das rootfs gemountet wird!? Macht das der Kernel? Kann man die Rechte mit "mount -o remount ..." ändern?

MfG Oliver

 

[jojo-schmitz]

Auf einer ungefreetzten Box ist es 770. Aber da es nur 2 user gibt, root und ftp, und beide die GID 0 haben und darüberhinaus das root file system eh read-only ist, macht das keinen wirklichen Unterschied.

EDIT:

# mount
rootfs on / type rootfs (rw)
/dev/root on / type squashfs (ro)
...

Tschö, Jojo

 

[RalfFriedl]

Sollten wir denn nicht / mit den Rechten 755 mounten?

Ein Verzeichnis wird nicht mit irgendwelchen Rechnen gemountet (Dateisysteme, die keine Unix Zugriffsrechte speichern einmal ausgenommen).

Bei Unix Dateisystemen werden die Recht vom Hauptverzeichnis wie die von anderen Verzeichnissen im Dateisystem gespeichert.

Und da das SquashFS Dateisystem sowieso nicht beschreibbar ist, macht es keinen großen Unterschied, wer da Schreibrechte hat.

 

[mehle]

Mir ist gerade aufgefallen dass /var die Rechte 777 hat. Da dies ein tmpfs Dateisystem ist, ist dies extrem schlecht. Dies muss auf 755 gesetzt werden da ansonsten nichts in diesem Verzeichnis vertrauenswürdig ist.

Danke
Stephan

 

[abraXxl]

Mir ist gerade aufgefallen dass /var die Rechte 777 hat. Da dies ein tmpfs Dateisystem ist, ist dies extrem schlecht. Dies muss auf 755 gesetzt werden da ansonsten nichts in diesem Verzeichnis vertrauenswürdig ist.

Genauer sollte es normalerweise 1777 haben. Directory mit Sticky-Bit, d.h. nur Datei-Eigentümer dürfen ihre Datein löschen, obwohl alle Schreibrechte auf das Dir haben. Damit Temp-Dateien nicht eingesehen werden drfen, sollten diese 600 oder 700 sein.
Sehe ich aber auf der Fritzbox als unkritisch, wo sowieso alles als root läuft.

Und das Rootverzeichnis ist 777 weil, ggf. beim Freetz-Compilieren das Verzeichnis beim Bauen des Squashfs Images mit einer entsprechenden umask in der fakeroot-Umgebung angelgt wurde, bzw. nachträglich chmod angewandt wurde. Für das squashfs ist das auch nicht kritisch da dies nur lesbar ist. BTW jeder der einen AVM Prozess kapert/remote exploitet ist sowieso auch root ist und kommt. an alle Datein ran.

Unschön ist beides natürlich, es hat beides schleichendes Fussschusspotential.

cya

 

[mehle]

Sehe ich aber auf der Fritzbox als unkritisch, wo sowieso alles als root läuft.

Jungs, überlegt nochmal gaaaaaanz genau! Diese Boxes sind der IDEALE Bot! Immer am Internet, nicht richtig kontrolliert! Zugang zu allen Netzen (intern/WLAN/extern)! Jeder Traffic (intern/extern) geht über die Box!

Ich versuche hier aufzuräumen, damit immer mehr als non-root läuft und ggf. im chroot.

Diese Box ist sicherheitstechnisch gesehen kritischer als dein Desktop-PC!

Ciao
Stephan

 

[cuma]

Wir so sein, allerdings müsste da am besten AVM anfangen. Frag doch mal nach :-]

 

[mehle]

Wohl war, und ich bin dran. Aber in der Zwischenzeit können wir doch etwas tun, oder?

Ausserdem, ich frage hier einfach mal so, da IIRC das Wurzelverzeichnis von Freetz mit den Rechten 777 gesetzt wird, von AVM wird dies mit 775 gemacht (ich bin mir nicht ganz sicher, woher ich dies habe). Wenn dies so ist, nehme ich auch einfach mal an, dass Freetz an den Rechten von /var dreht.

Ciao
Stephan

 

[abraXxl]

Jungs, überlegt nochmal gaaaaaanz genau! Diese Boxes sind der IDEALE Bot! Immer am Internet, nicht richtig kontrolliert! Zugang zu allen Netzen (intern/WLAN/extern)! Jeder Traffic (intern/extern) geht über die Box!

Ich versuche hier aufzuräumen, damit immer mehr als non-root läuft und ggf. im chroot.

Ja es ist der Ideale Bot es gibt bereits einen Mispel-Bot-Netclient. Guckst du hier.

Solltest du aber aufräumen wollen, musst du AVM triggern, da es deren Programme sind die Zwangsweise als Root laufen müssen.

 

[olistudent]

@mehle
Such in der fwmod mal nach chmod. Da sind ein paar drin. Ich hab nichts dagegen, wenn die abgeändert werden, solange noch alles funktioniert. ;-)

MfG Oliver

 

[olistudent]

@Mehle
Was soll denn hier jetzt passieren?

Müssen wir ein vorhandenes chmod aus der fwmod löschen oder eins hinzufügen? Wie sollte das aussehen?

MfG Oliver

 

[mehle]

Sorry, war gerade beschäftigt.

Ich schaue mir jetzt fwmod an.

Update: Ich glaube nicht, dass die fwmod daran Schuld ist - die packt ja nur aus. Und wenn ich mir var.tar anschaue sind da auch keine falschen Rechte drinnen. Ich glaube eher, dass der Fehler beim Anlegen von /var in /etc/init.d/rc.S liegt. Es wird /var als tmpfs gemountet - dies ergibt erst einmal die Rechte 755. Danach wird var.tar ausgepackt. Irgendwo hier, glaube ich, liegt der Fehler.

Ciao
Stephan

 

[olistudent]

freetz/trunk/build/original/filesystem$ ls -al
total 84
drwxrwxr-x 12 oliver oliver  4096 2009-08-10 15:56 .
drwxr-xr-x  5 oliver oliver  4096 2009-08-21 18:10 ..
drwxrwxr-x  2 oliver oliver  4096 2009-08-10 15:56 bin
drwxrwxr-x  2 oliver oliver  4096 2009-08-10 15:56 data
drwxrwxr-x  3 oliver oliver 12288 2009-08-10 15:56 dev
drwxrwxr-x  7 oliver oliver  4096 2009-08-10 15:56 etc
drwxrwxr-x  3 oliver oliver 12288 2009-08-10 15:56 lib
lrwxrwxrwx  1 oliver oliver    19 2009-08-21 18:10 nohup.out -> ./var/tmp/nohup.out
drwxrwxr-x  2 oliver oliver  4096 2009-08-10 15:56 proc
drwxrwxr-x  2 oliver oliver  4096 2009-08-10 15:56 sbin
drwxrwxr-x  3 oliver oliver  4096 2009-08-10 15:56 share
drwxrwxr-x  6 oliver oliver  4096 2009-08-10 15:56 usr
drwxrwxr-x  2 oliver oliver  4096 2009-08-10 15:56 var
-rw-rw-r--  1 oliver oliver 20480 2009-08-10 15:56 var.tar

Aber das var-Verzeichnis ist doch fest im squashfs. Das mounten vom tmpfs ändert doch nichts an den Rechten von /var oder?

MfG Oliver

 

[abraXxl]

Aber das var-Verzeichnis ist doch fest im squashfs. Das mounten vom tmpfs ändert doch nichts an den Rechten von /var oder?

U.u. doch, da man tmpfs und ramfs noch mit "mount -o mode=1777" z.B. andere Rechte für den Mountpoint genauer den "."-Eintrag für das Rootverzeichnis des tmpfs-Mounts geben kann.
Da "/var" und "/var/." gleichwertig sind ändert sich somit im VFS die Berechtigung von /var.

 

[olistudent]

Stimmt meine /etc/fstab so? Warum mountet er beim expliziten mount anders wie beim Booten?

/ # ls -al
drwxr-xr-x    4 root     root            0 Aug 10 21:34 .
drwxr-xr-x    4 root     root            0 Aug 10 21:34 ..
drwxr-xr-x    2 root     root         1397 Aug 10 21:35 bin
drwxr-xr-x    5 root     root            0 Jan  1  1970 data
drwxr-xr-x    7 root     root            0 Aug 22 13:22 dev
drwxr-xr-x    3 root     root            0 Aug 22 13:21 etc
lrwxrwxrwx    1 root     root           12 Aug 10 21:34 home -> var/mod/home
drwxr-xr-x    3 root     root         5214 Aug 10 21:35 lib
lrwxrwxrwx    1 root     root            7 Aug 10 21:34 mod -> var/mod
lrwxrwxrwx    1 root     root           19 Aug 10 21:34 nohup.out -> ./var/tmp/nohup.out
drwxr-xr-x    2 root     root            3 Aug 13  2008 oldroot
dr-xr-xr-x   81 root     root            0 Jan  1  2000 proc
drwxrwxrwx   15 root     root          212 Aug 10 21:35 rom
drwxr-xr-x    2 root     root          892 Aug 10 21:35 sbin
drwxr-xr-x    3 root     root           20 Jun 24 17:54 share
drwxr-xr-x    5 root     root            0 Jan  1  1970 sto
drwxr-xr-x   10 root     root            0 Jan  1  2000 sys
lrwxrwxrwx    1 root     root            7 Aug 10 21:34 tmp -> var/tmp
drwxr-xr-x   10 root     root          114 May 13 03:38 usr
drwxrwxrwx   15 root     root            0 Aug 22 13:23 var
-rw-r--r--    1 root     root        30720 Aug 10 21:35 var.tar
/ # cat /etc/fstab
# /etc/fstab: static file system information.
#
# <file system> <mount point>   <type>  <options>               <dump>  <pass>
proc            /proc           proc    nosuid,nodev,noexec     0       0
tmpfs           /var            tmpfs   defaults,mode=1777     0       0
sysfs           /sys            sysfs   nosuid,nodev,noexec     0       0
/ # mount /var
/ # ls -al |grep var
lrwxrwxrwx    1 0        0              12 Aug 10 21:34 home -> var/mod/home
lrwxrwxrwx    1 0        0               7 Aug 10 21:34 mod -> var/mod
lrwxrwxrwx    1 0        0              19 Aug 10 21:34 nohup.out -> ./var/tmp/nohup.out
lrwxrwxrwx    1 0        0               7 Aug 10 21:34 tmp -> var/tmp
drwxr-xr-x    2 0        0               0 Aug 22 13:27 var
-rw-r--r--    1 0        0           30720 Aug 10 21:35 var.tar
/ #

MfG Oliver

 

[abraXxl]

@ollistudent: Ja deine Fstab ist an sich richtig. Bei mir passiert auc nicht das was ich in #15 gepredigt habe. Ich muss somit #15 erstmal revidieren, bis ich mehr gelesen habe. Auf meiner Desktop-Maschine verhält sich das jedoch wie erwartet. hmm ...

 

[olistudent]

Na toll...

/ # ls -al
drwxr-xr-x    4 root     root            0 Aug 10 21:34 .
drwxr-xr-x    4 root     root            0 Aug 10 21:34 ..
drwxr-xr-x    2 root     root         1397 Aug 10 21:35 bin
drwxr-xr-x    5 root     root            0 Jan  1  1970 data
drwxr-xr-x    7 root     root            0 Jan  1  2000 dev
drwxr-xr-x    3 root     root            0 Aug 22 13:21 etc
lrwxrwxrwx    1 root     root           12 Aug 10 21:34 home -> var/mod/home
drwxr-xr-x    3 root     root         5214 Aug 10 21:35 lib
lrwxrwxrwx    1 root     root            7 Aug 10 21:34 mod -> var/mod
lrwxrwxrwx    1 root     root           19 Aug 10 21:34 nohup.out -> ./var/tmp/nohup.out
drwxr-xr-x    2 root     root            3 Aug 13  2008 oldroot
dr-xr-xr-x   83 root     root            0 Jan  1  2000 proc
drwxrwxrwx   15 root     root          212 Aug 10 21:35 rom
drwxr-xr-x    2 root     root          892 Aug 10 21:35 sbin
drwxr-xr-x    3 root     root           20 Jun 24 17:54 share
drwxr-xr-x    5 root     root            0 Jan  1  1970 sto
drwxr-xr-x   10 root     root            0 Jan  1  2000 sys
lrwxrwxrwx    1 root     root            7 Aug 10 21:34 tmp -> var/tmp
drwxr-xr-x   10 root     root          114 May 13 03:38 usr
drwxr-xr-x   15 root     root            0 Aug 23 21:39 var
-rw-r--r--    1 root     root        30720 Aug 10 21:35 var.tar
/ # ctlmgr -s
/ # ctlmgr
/ # ls -al
drwxr-xr-x    4 root     root            0 Aug 10 21:34 .
drwxr-xr-x    4 root     root            0 Aug 10 21:34 ..
drwxr-xr-x    2 root     root         1397 Aug 10 21:35 bin
drwxr-xr-x    5 root     root            0 Jan  1  1970 data
drwxr-xr-x    7 root     root            0 Jan  1  2000 dev
drwxr-xr-x    3 root     root            0 Aug 22 13:21 etc
lrwxrwxrwx    1 root     root           12 Aug 10 21:34 home -> var/mod/home
drwxr-xr-x    3 root     root         5214 Aug 10 21:35 lib
lrwxrwxrwx    1 root     root            7 Aug 10 21:34 mod -> var/mod
lrwxrwxrwx    1 root     root           19 Aug 10 21:34 nohup.out -> ./var/tmp/nohup.out
drwxr-xr-x    2 root     root            3 Aug 13  2008 oldroot
dr-xr-xr-x   83 root     root            0 Jan  1  2000 proc
drwxrwxrwx   15 root     root          212 Aug 10 21:35 rom
drwxr-xr-x    2 root     root          892 Aug 10 21:35 sbin
drwxr-xr-x    3 root     root           20 Jun 24 17:54 share
drwxr-xr-x    5 root     root            0 Jan  1  1970 sto
drwxr-xr-x   10 root     root            0 Jan  1  2000 sys
lrwxrwxrwx    1 root     root            7 Aug 10 21:34 tmp -> var/tmp
drwxr-xr-x   10 root     root          114 May 13 03:38 usr
drwxrwxrwx   15 root     root            0 Aug 23 21:40 var
-rw-r--r--    1 root     root        30720 Aug 10 21:35 var.tar

MfG Oliver

 

[abraXxl]

ctlmgr ändern scheinbar automagish den Mdus des /var Eintrags, na geil ...

 

[olistudent]

1540  mkdir("/var", 0777)               = -1 EEXIST (File exists)
1540  mkdir("/var/flash", 0777)         = -1 EEXIST (File exists)
1540  unlink("/var/flash/ar7.cfg")      = 0
1540  mknod("/var/flash/ar7.cfg", S_IFCHR|0666, makedev(240, 113)) = 0
1540  open("/var/flash/ar7.cfg", O_RDONLY) = 6

Ist das das hier?

MfG Oliver