Toon posts:

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

Pagina: 1
Acties:

  • drm
  • Registratie: Februari 2001
  • Laatst online: 26-05 17:59
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?".

Music is the pleasure the human mind experiences from counting without being aware that it is counting
~ Gottfried Leibniz
[ melp.nl | twitter ]


  • CyBeR
  • Registratie: September 2001
  • Niet online

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.

All my posts are provided as-is. They come with NO WARRANTY at all.


  • Wolfboy
  • Registratie: Januari 2001
  • Niet online

Wolfboy

ubi dubium ibi libertas

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.

Blog [Stackoverflow] [LinkedIn]


  • Sir Isaac
  • Registratie: September 2002
  • Laatst online: 11-01-2022
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:
1
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
  • Registratie: Februari 2003
  • Laatst online: 27-05 13:25

CAPSLOCK2000

zie teletekst pagina 888

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.

This post is warranted for the full amount you paid me for it.


  • drm
  • Registratie: Februari 2001
  • Laatst online: 26-05 17:59
Dank voor de antwoorden :-) Niks nieuws eigenlijk, maar goed om te weten dat ik niks over het hoofd zie.

Music is the pleasure the human mind experiences from counting without being aware that it is counting
~ Gottfried Leibniz
[ melp.nl | twitter ]


  • d1ng
  • Registratie: Augustus 2009
  • Laatst online: 18-05 17:28
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 :)

Acties:
  • 0Henk 'm!

  • icyx
  • Registratie: Januari 2007
  • Niet online

icyx

chown -R us ./base

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

When you think you’ve succeeded / but something’s missing / means you have been defeated / by greed, your weakness.


Acties:
  • 0Henk 'm!

  • silentsnake
  • Registratie: September 2003
  • Laatst online: 31-05 20:57
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 :)

Acties:
  • 0Henk 'm!

  • Anoniem: 28958
  • Registratie: Juni 2001
  • Niet online
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.

Acties:
  • 0Henk 'm!

  • icyx
  • Registratie: Januari 2007
  • Niet online

icyx

chown -R us ./base

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.

When you think you’ve succeeded / but something’s missing / means you have been defeated / by greed, your weakness.


Acties:
  • 0Henk 'm!

  • webfreakz.nl
  • Registratie: November 2003
  • Laatst online: 28-08-2022

webfreakz.nl

el-nul-zet-é-er

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.

"You smell that, son? What sir? Napalm, I love the smell of napalm in the mornin!" || Children of Bodom fan!


  • drm
  • Registratie: Februari 2001
  • Laatst online: 26-05 17:59
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.

Music is the pleasure the human mind experiences from counting without being aware that it is counting
~ Gottfried Leibniz
[ melp.nl | twitter ]


  • d1ng
  • Registratie: Augustus 2009
  • Laatst online: 18-05 17:28
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.
Pagina: 1


Tweakers maakt gebruik van cookies

Tweakers plaatst functionele en analytische cookies voor het functioneren van de website en het verbeteren van de website-ervaring. Deze cookies zijn noodzakelijk. Om op Tweakers relevantere advertenties te tonen en om ingesloten content van derden te tonen (bijvoorbeeld video's), vragen we je toestemming. Via ingesloten content kunnen derde partijen diensten leveren en verbeteren, bezoekersstatistieken bijhouden, gepersonaliseerde content tonen, gerichte advertenties tonen en gebruikersprofielen opbouwen. Hiervoor worden apparaatgegevens, IP-adres, geolocatie en surfgedrag vastgelegd.

Meer informatie vind je in ons cookiebeleid.

Sluiten

Toestemming beheren

Hieronder kun je per doeleinde of partij toestemming geven of intrekken. Meer informatie vind je in ons cookiebeleid.

Functioneel en analytisch

Deze cookies zijn noodzakelijk voor het functioneren van de website en het verbeteren van de website-ervaring. Klik op het informatie-icoon voor meer informatie. Meer details

janee

    Relevantere advertenties

    Dit beperkt het aantal keer dat dezelfde advertentie getoond wordt (frequency capping) en maakt het mogelijk om binnen Tweakers contextuele advertenties te tonen op basis van pagina's die je hebt bezocht. Meer details

    Tweakers genereert een willekeurige unieke code als identifier. Deze data wordt niet gedeeld met adverteerders of andere derde partijen en je kunt niet buiten Tweakers gevolgd worden. Indien je bent ingelogd, wordt deze identifier gekoppeld aan je account. Indien je niet bent ingelogd, wordt deze identifier gekoppeld aan je sessie die maximaal 4 maanden actief blijft. Je kunt deze toestemming te allen tijde intrekken.

    Ingesloten content van derden

    Deze cookies kunnen door derde partijen geplaatst worden via ingesloten content. Klik op het informatie-icoon voor meer informatie over de verwerkingsdoeleinden. Meer details

    janee