Ich glaube, hier wird ganz schön was durcheinander geschmissen.
Nochmal: admin ist der Meister des DSM und das hat erstmal nix mit root und ssh zu tun
@armut: Du will ein sicheres System?
Dann mache ein "forwarding" für sowenig Ports wie irgend möglich, (am besten gar keine) und aktiviere die "automatische Blockierung" von IPs, die zu viele fehlerhafte Loginversuche erzeugen!
Wenn du eine Fritzbox hast, nutze deren VPN Funktion, um dich über das Internet in dein Netz einzuklinken und greife dann auf die DS zu.
Was über "su" im Wiki steht, ist (mittlerweile?) falsch...zumindest was die DS betrifft.
Ich habe mich hier mal als admin per ssh an der DS angemeldet. Im folgenden die Befehle:
Mit "id" schaue ich nach, wer ich bin.
Dann sieht man, dass ein "su - root" nicht funktioniert. Das liegt daran, dass ich "su" als admin gestartet habe und "su" nicht SETUID-root ist.
head -11 /etc/passwd zeigt mir die ersten 11 User (die restlichen gehen euch nix an
) und dort sieht man, dass root die UID 0 hat und admin hat die UID 1024.
Rich (BBCode):
ds> id
uid=1024(admin) gid=100(users) groups=25(smmsp),100(users),101(administrators)
ds> su - root
su: must be suid to work properly
ds> head -11 /etc/passwd
root:x:0:0:root:/root:/bin/ash
lp:x:4:7:lp:/var/spool/lpd:/sbin/nologin
anonymous:x:21:21:Anonymous FTP User:/nonexist:/sbin/nologin
ftp:x:21:21:Anonymous FTP User:/nonexist:/sbin/nologin
smmsp:x:25:25:Sendmail Submission User:/var/spool/clientmqueue:/sbin/nologin
postfix:x:125:125:Postfix User:/nonexist:/sbin/nologin
dovecot:x:143:143:Dovecot User:/nonexist:/sbin/nologin
spamfilter:x:783:1023:Spamassassin User:/var/spool/postfix:/sbin/nologin
nobody:x:1023:1023:nobody:/home:/sbin/nologin
admin:x:1024:100:System default user:/var/services/homes/admin:/bin/sh
guest:x:1025:100:Guest:/nonexist:/bin/sh
ds>
Jetzt das gleiche Spiel als root.
Da kommt bei "su - root" keine Fehlermeldung, da "su" selbst prüft, ob es mit der Berechtigung des Users root gestartet wurde.
In diesem Fall ist das so, und deshalb funktioniert es auch. (wenn's so auch nicht dem eigentlichen Sinn von "su" entspricht)
Zum Schluß noch ein "su - admin", um zu zeigen, wie es sinnvoll genutzt werden kann.
Rich (BBCode):
ds> id
uid=0(root) gid=0(root) groups=0(root)
ds> su - root
BusyBox v1.16.1 (2013-08-17 02:36:47 CST) built-in shell (ash)
Enter 'help' for a list of built-in commands.
ds> head -11 /etc/passwd
root:x:0:0:root:/root:/bin/ash
lp:x:4:7:lp:/var/spool/lpd:/sbin/nologin
anonymous:x:21:21:Anonymous FTP User:/nonexist:/sbin/nologin
ftp:x:21:21:Anonymous FTP User:/nonexist:/sbin/nologin
smmsp:x:25:25:Sendmail Submission User:/var/spool/clientmqueue:/sbin/nologin
postfix:x:125:125:Postfix User:/nonexist:/sbin/nologin
dovecot:x:143:143:Dovecot User:/nonexist:/sbin/nologin
spamfilter:x:783:1023:Spamassassin User:/var/spool/postfix:/sbin/nologin
nobody:x:1023:1023:nobody:/home:/sbin/nologin
admin:x:1024:100:System default user:/var/services/homes/admin:/bin/sh
guest:x:1025:100:Guest:/nonexist:/bin/sh
ds>
ds> su - admin
BusyBox v1.16.1 (2013-08-17 02:36:47 CST) built-in shell (ash)
Enter 'help' for a list of built-in commands.
ds> id
uid=1024(admin) gid=100(users) groups=25(smmsp),100(users),101(administrators)
ds>
SETUID funktioniert so, dass der Eigentümer eines Binärprogramms (Scripte gehen nicht!), diesem Programm das SETUID Bit setzen kann.
Dadurch wird das Programm dann immer mit der Berechtigung des Eigentümers ausgeführt, egal, wer das Programm startet.
Dieses System ist eine potentielle Sicherheitslücke, wenn sich der Eigentümer über die möglichen Folgen nicht im klaren ist.
Bestes Beispiel für vollkommene Blödheit war Oracle, die dem TCL-Interpreter mal das SETUID-root-Bit gesetzt hatten:
http://dl.packetstormsecurity.net/9905-exploits/oracle.8.0.5.intelligent.agent.txt
Der TCL-Interpreter ist dazu gedacht, Scripte auszuführen. Durch die "Leistung" von Oracle war jeder lokale User in der Lage, ein selbst geschriebenes TCL-Script als root auszuführen.
Da sich, wie hier bereits jemand anmerkte, busybox hinter dem "su" Befehl befindet, wäre es tödlich, busybox SETUID-root zu geben.
Auf der anderen Seite funktioniert "su" nicht ohne root Rechte. Hier würde nur helfen, "su" auszutauschen.
