daemons die nicht unter root laufen müssen

23/01/2015 - 19:30 von Fritz | Report spam
Soweit ich mich richtig erinnere, habe ich gelesen, dass unter Unix
daemons die einen Port unter 1024 zur Verfügung stellen eigentlich unter
root laufen müssten.
Der gravierende Nachteil, wenn dieses Programm kompromittiert würde,
könnte der Angreifer locker den gesamten Rechner übernehmen.

Apple (und auch andere) stellen als Abhilfe die Möglichkeit der Sandbox
zur Verfügung. Der Daemon làuft zwar unter root kann aber nicht über die
Grenzen, welche in seiner Sandbox Konfiguration festgelegt wird hinaus.

Eine andere Möglichkeit verwendet MacPorts, da wird der daemon
anscheinend von einem Helper, der unter root làuft, gestartet, làuft
aber selbst unter einem anderen User (ID über 500) mit sehr
eingeschrànkten Rechten.

Ich habe nun auch gelesen, dass bei BSD artigen Unix'en User mit einer
UID unter 500 auch die Berechtigung hàtten Ports unter 1024 zur
Verfügung zu stellen. Ist das so korrekt?

Welche Möglichkeiten gibt es noch einen daemon so abzuschotten, dass man
nicht im Worstcase über ihn das gesamte System kompromittieren kann.

Kann man eigentlich die ID eines Users oder einer Gruppe auch
nachtràglich noch veràndern?

PS: Ich weiß 100% Sicherheit gibt es nicht!

Fritz
Ironie, Sarkasmus, Satire, Farce, Persiflage, Metapher sind keinesfalls
ausgeschlossen!
 

Lesen sie die antworten

#1 Juergen P. Meier
23/01/2015 - 19:42 | Warnen spam
Fritz :
Soweit ich mich richtig erinnere, habe ich gelesen, dass unter Unix
daemons die einen Port unter 1024 zur Verfügung stellen eigentlich unter
root laufen müssten.



DaS ist klassischer BSD Stack, ja.

Der gravierende Nachteil, wenn dieses Programm kompromittiert würde,
könnte der Angreifer locker den gesamten Rechner übernehmen.



Einige Moderne Unix Varianten erlauben es, Ports aus diesem
Bereich fuer unprivilegierte Prozesse freizugeben.

Andere wiederherum erlauben es einem Prozess, privilegien abzulegen,
so dass der Daemon zwar als root gestartet wird (um den Port zu
allozieren), aber danach alle anderen Rechte ablegt um nach einer
Kompromittierung keine privilegien mehr zu haben..

Wieder andere machen Sandboxing und MACL.

Apple (und auch andere) stellen als Abhilfe die Möglichkeit der Sandbox
zur Verfügung. Der Daemon làuft zwar unter root kann aber nicht über die
Grenzen, welche in seiner Sandbox Konfiguration festgelegt wird hinaus.

Eine andere Möglichkeit verwendet MacPorts, da wird der daemon
anscheinend von einem Helper, der unter root làuft, gestartet, làuft
aber selbst unter einem anderen User (ID über 500) mit sehr
eingeschrànkten Rechten.



Auch das geht, dafuer muss man aber idR. eine Form von IPC haben.

Ich habe nun auch gelesen, dass bei BSD artigen Unix'en User mit einer
UID unter 500 auch die Berechtigung hàtten Ports unter 1024 zur
Verfügung zu stellen. Ist das so korrekt?



Es gibt viele Varianten.

Welche Möglichkeiten gibt es noch einen daemon so abzuschotten, dass man
nicht im Worstcase über ihn das gesamte System kompromittieren kann.



Die am weitestgehende kommt aus der Ecke "Trusted Computing" und
erfordert eine white-list aller relevanten Prozessablaeufe eines Programms.
Das Trust-Framework setzt diese dann durch, so dass keine anderen
Ablaeufe moeglich sind.

Kann man eigentlich die ID eines Users oder einer Gruppe auch
nachtràglich noch veràndern?



Man kann die ID eines Prozesses aendern (setuid())..

Wenn du die ID eines Users aenderst, veraenderst du die Interpretation
der urspruenglichen ID.

PS: Ich weiß 100% Sicherheit gibt es nicht!



Allgemeinplatz. Natuerlich kann man 100% Sicherheit vor *definierten*
Gefahren mit geeigneten Massnahmen erreichen.

Juergen
Juergen P. Meier - "This World is about to be Destroyed!"
end
If you think technology can solve your problems you don't understand
technology and you don't understand your problems. (Bruce Schneier)

Ähnliche fragen