Hoe evil is het om daemons onder "gewone" users te starten?

[drm]

Ik zit al een tijdje met de volgende vraag te spelen. Ik heb intussen aardig wat ervaring met het draaien van Linux en FreeBSD systemen op zowel servers als desktop, maar hier heb ik eigenlijk nooit iets zinnigs over gelezen of uitgevonden.

De use case is de volgende: ik wil binnenkort Sphinx Search gaan inzetten binnen een aantal verschillende toepassingen. Ik heb niet in alle situaties root access op die machines (die wil ik in een aantal gevallen niet eens hebben), maar heb wel een bash user met wie ik de daemons kan starten en natuurlijk de owner van het webserver-process waarmee ik e.e.a. kan. Stel, ik wil meerdere instanties van de searchd daemon draaien voor verschillende toepassingen op diezelfde server, maar ik wil dat niet met de root user doen, wat voor implicaties heeft dat? Denk dan vooral aan het (extreme) geval waarbij ik de daemon zelfs wil kunnen managen via de webinterface, en de webserver-user dus owner wordt van het proces van die daemon.

Even afgezien van het applicatiebeheer en/of systeembeheer (waarover je op "business"-niveau allerlei discussies over kunt voeren), ben ik benieuwd wat voor technische en implicaties het heeft als je (bijvoorbeeld) de webserver-user de daemon laat starten en laat managen. Het is prima te doen, omdat je aan de daemon (in dit geval) een configuratiefile mee kunt geven waarmee de poorten en pid-, log- en databestanden gewoon geconfigureerd kunnen worden (dus ook binnen een voor die user schrijfbare dir).

Het voor-de-handliggende antwoord dat de webserver-user daarmee ook owner wordt van de data-bestanden vind ik niet zo'n probleem, dat is namelijk voor een heel groot deel van de data (alle data die niet in de database staat, bijvoorbeeld) ook al het geval. Daar kom je wel uit.

Ook dat eventuele initscripts niet bij opstarten uitgevoerd worden vind ik geen direct probleem, dit zou je altijd alsnog in kunnen regelen.

Zijn er nog andere gevolgen / dingen waar ik rekening mee zou moeten houden? Is er meer te beantwoorden dan: "Het is gewoon not done?".

[CyBeR]

Het heeft security implicaties, meer eigenlijk praktisch gezien niet. De gebruikelijke manier van werken is om daemons onder een eigen user te laten draaien zodat ze een bepaalde mate van separation van elkaar hebben. Maar als het voor jou handiger is om sphinx onder www-data te draaien is er imo niets wat je tegen staat. Denk erover na wat een inbraak op die www-data user voor impact kan hebben op sphinx en weeg dat af.

[Wolfboy]

Goede daemon processen draaien niet als root (voor zover mogelijk uiteraard) maar als "gewone" user. Bij ongeveer elke Linux/Unix distro zullen FTP programma's als user "ftp" draaien.

Het draaien als aparte user is dan ook zeker een goed idee, meerdere processen als dezelfde user draaien is natuurlijk wel een mogelijk beveiligingsrisico (je kan de andere processen killen en/of bestanden wijzigen).

Persoonlijk zou ik alles draaien via supervisord, die kan heel netjes al je processen beheren en eventueel (als je supervisord als root draait) je processen als een andere user starten.

[Sir Isaac]

Ik heb zelf een webapplicatie gemaakt die mijn proxy server moet kunnen herstarten. Beide draaien met een eigen account (www-data resp tinyproxy). Ik heb dit geregeld met sudo. In mijn /etc/sudoers file staat:

code:

www-data ALL=(root) NOPASSWD: /etc/init.d/tinyproxy restart

De web server kan dus niets anders dan het herstarten van de proxy. Werkt prima.

[CAPSLOCK2000]

Het is juist een heel goed idee om die daemons niet als root te draaien. Hoe minder je als root draait, hoe beter. Maak er wel een aparte gebruiker voor aan. Je gewone login gebruiken is een minder goed idee. Als het even kan kun je het beste voor iedere instance een aparte gebruiker hebben, dan weet je zeker dat het goed is geisoleerd.

Een kleine waarschuwing, traditioneel moge gewone gebruikers geen poorten onder de 1024 openen. Als je dus een webserver op poort 80 wil draaien dan gaat dat niet, al ga ik er van uit dat FreeBSD een manier heeft om het toch toe te staan.

[drm]

Dank voor de antwoorden :-) Niks nieuws eigenlijk, maar goed om te weten dat ik niks over het hoofd zie.

[d1ng]

CAPSLOCK2000 schreef op donderdag 07 juli 2011 @ 18:58:
Het is juist een heel goed idee om die daemons niet als root te draaien. Hoe minder je als root draait, hoe beter. Maak er wel een aparte gebruiker voor aan. Je gewone login gebruiken is een minder goed idee. Als het even kan kun je het beste voor iedere instance een aparte gebruiker hebben, dan weet je zeker dat het goed is geisoleerd.

Een kleine waarschuwing, traditioneel moge gewone gebruikers geen poorten onder de 1024 openen. Als je dus een webserver op poort 80 wil draaien dan gaat dat niet, al ga ik er van uit dat FreeBSD een manier heeft om het toch toe te staan.

In FreeBSD is standaard < 1024 alleen starten als root.
Deze defaults staan gedefinieerd in sysctl:

net.inet.ip.portrange.reservedhigh: 1023
net.inet.ip.portrange.reservedlow: 0

Heb je uiteraard wel alsnog root voor nodig om deze waarden aan te passen, en uiteraard staan deze waarden niet voor niets ingesteld als defaults

[icyx]

d1ng schreef op donderdag 07 juli 2011 @ 23:29:
[...]

In FreeBSD is standaard < 1024 alleen starten als root.
Deze defaults staan gedefinieerd in sysctl:

net.inet.ip.portrange.reservedhigh: 1023
net.inet.ip.portrange.reservedlow: 0

Heb je uiteraard wel alsnog root voor nodig om deze waarden aan te passen, en uiteraard staan deze waarden niet voor niets ingesteld als defaults

Of je start je code als root, opent de port, en dropt vervolgens alle privileges tot je weer 'gewone' rechten hebt. Als je dat goed aan pakt draait het proces ook nog als gewone user, en kan je toch zo'n poort gebruiken.

Overigens kan je dan weer beter met iptables doen, en direct naar de privileged port luisteren. Dit kan bijvoorbeeld zo:

iptables -t nat -A PREROUTING -p tcp --dport 80 -j REDIRECT --to-port 8080

[silentsnake]

icyx schreef op vrijdag 08 juli 2011 @ 07:02:
[...]
Overigens kan je dan weer beter met iptables doen, en direct naar de privileged port luisteren. Dit kan bijvoorbeeld zo:

iptables -t nat -A PREROUTING -p tcp --dport 80 -j REDIRECT --to-port 8080

Ook een oplossing, alleen heb je zover ik weet geen iptables op FreeBSD. Dat moet dus IPFirewall of PF worden

[Anoniem: 28958]

d1ng schreef op donderdag 07 juli 2011 @ 23:29:
Heb je uiteraard wel alsnog root voor nodig om deze waarden aan te passen, en uiteraard staan deze waarden niet voor niets ingesteld als defaults

Vertel maar eens waarom dat zo is. Zolang root niet al een dienst op een bepaalde poort heeft draaien zie ik niet waarom het erg zou zijn als een gebruiker een of andere mail server draait, bijv.

[icyx]

silentsnake schreef op vrijdag 08 juli 2011 @ 13:28:
Ook een oplossing, alleen heb je zover ik weet geen iptables op FreeBSD. Dat moet dus IPFirewall of PF worden

Je hebt gelijk, maar ik wilde alleen het idee aanduiden. Met IPTables kan ik dat met deze situatie uit mijn hoofd

Anoniem: 28958 schreef op zondag 10 juli 2011 @ 18:23:
Vertel maar eens waarom dat zo is. Zolang root niet al een dienst op een bepaalde poort heeft draaien zie ik niet waarom het erg zou zijn als een gebruiker een of andere mail server draait, bijv.

Dat weet ik eigenlijk ook niet zeker, maar ik kan me indenken dat het iets met het 'vertrouwen' van de server te maken heeft. Externen zien immers alleen de portnummers, en niet de users. Zijn kunnen er bij < 1024 gewoon vanuit gaan dat het door root is gefixt, en daarmee dus door de beheerder van het systeem.

[webfreakz.nl]

Anoniem: 28958 schreef op zondag 10 juli 2011 @ 18:23:
[...]

Vertel maar eens waarom dat zo is. Zolang root niet al een dienst op een bepaalde poort heeft draaien zie ik niet waarom het erg zou zijn als een gebruiker een of andere mail server draait, bijv.

Dus jij denkt dat het handig is dat een user zomaar een mailserver op kan zetten? Die dan vervolgens een open relay blijkt te zijn en de IP range / domein op een blacklist komt te staan. Of deze user zet een FTP server op welke nooit geupdate wordt en ooit eens een vatbaar wordt voor een remote privilege escalation exploit?

Nee, dat moet afgeschermd zijn door een firewall en een policy dat user niet zomaar porten kunnen openen.

[drm]

webfreakz.nl:
Dus jij denkt dat het handig is dat een user zomaar een mailserver op kan zetten? Die dan vervolgens een open relay blijkt te zijn en de IP range / domein op een blacklist komt te staan. Of deze user zet een FTP server op welke nooit geupdate wordt en ooit eens een vatbaar wordt voor een remote privilege escalation exploit?

Nee, dat moet afgeschermd zijn door een firewall en een policy dat user niet zomaar porten kunnen openen.

Maar dat is feitelijk alleen maar conventie, want datzelfde probleem kan op hogere poortnummers ook optreden. Alleen ligt het niet voor de hand dat men een FTP server gaat exploiten die niet op poort 21 draait, omdat men dan wel eerst het goeie poortnummer moet gokken.

[d1ng]

Anoniem: 28958 schreef op zondag 10 juli 2011 @ 18:23:
[...]

Vertel maar eens waarom dat zo is. Zolang root niet al een dienst op een bepaalde poort heeft draaien zie ik niet waarom het erg zou zijn als een gebruiker een of andere mail server draait, bijv.

Dat is ook niet zo erg als je vertrouwde users hebt en je bewust die privileges weggeeft.

Het is anders als je bv. een mailserver draait voor een bedrijf met webmail op poort 443 en op een dag besluit een user om een pornosite oid te gaan draaien op poort 80. Het is een voorbeeld. Is ook een beetje standaardisatie. Webserver draaien op poort 81 gaat ook prima, maar iemand heeft besloten om voor webservers de poort 80 te reserveren. En zo ook alle poorten < 1024 vallen onder de noemer gereserveerd.