[Linux] directory's afschermen, 2 roots

[Verwijderd]

Heren,

ik heb een Linux systeem (suse ent srv), hierbij is het volgende aan de gang:

er zijn 2 systeembeheerders welke beide momenteel de root user benutten.
Nu is het zo dat 1 van de 2 niet in een map op deze server mag of dat dit op zijn minst gelogged wordt.
Het vormt dus een probleem aangezien ze beiden alles moeten kunnen kwa installeren, configureren etc maar dus 1 van de 2 de map niet in mag.
Iemand een idee hoe dit op te lossen of op zijn minst te loggen (soort windows auditing)?

[moto-moi]

Wat voor map gaat het om ?
Als het om een map met .txtfiles gaat kun je bijvoorbeeld naar encrypted filesystems kijken

[Verwijderd]

moto-moi schreef op donderdag 29 september 2005 @ 16:28:
Wat voor map gaat het om ?
Als het om een map met .txtfiles gaat kun je bijvoorbeeld naar encrypted filesystems kijken

het is 1 map met php files en wat docs/ppts etc. Het hele filesystem omgooien lijkt mij enigzins omslachtig.

[ge-flopt]

Dat zal dan denk ik moeilijk worden. Root account kan overal in, ook al zijn de rechten niet ingesteld voor hem.

[Verwijderd]

ge-flopt schreef op donderdag 29 september 2005 @ 16:31:
Dat zal dan denk ik moeilijk worden. Root account kan overal in, ook al zijn de rechten niet ingesteld voor hem.

Dat dacht ik al... Het zou echter al mooi zijn als bijv poging tot wijzigen van rechten op een map gelogd worden ofzo.

[moto-moi]

Verwijderd schreef op donderdag 29 september 2005 @ 16:29:
het is 1 map met php files en wat docs/ppts etc. Het hele filesystem omgooien lijkt mij enigzins omslachtig.

Loopback devices zijn daar zeer handig voor hoor ?

Verder, phpfiles kun je beveiligen voor sneaky inkijkers door iets als eaccelerator of mmTrunk of Zend eroverheen te halen, dan zijn ze nog wel uit te voeren, maar de originele code is onleesbaar

[axis]

is het niet op een ander niveau te regelen BUITEN deze pc?

[Soultaker]

De root user kan alles op het systeem, dus ook logfiles wissen. Sowieso hoeft de root user geen rechten te wijzigen om een bestand uit te lezen. Als je iemand niet vertrouwd op je systeem moet je 'm geen root rechten geven.

Bestanden coderen zou een oplossing kunnen zijn, maar ik neem aan dat het de bedoeling is dat die bestanden wel door de webserver e.d. gedecodeerd kunnen worden; dan is het dus altijd te omzeilen. Is dat niet de bedoeling dan heb ik een veel makkelijkere oplossing, zet die bestanden er gewoon niet op!

De enige oplossing is om de gebruiker die je niet volledig vertrouwd niet als root user te laten inloggen. Je kunt iets als sudo of een jail gebruiken om 'm toch delen van het systeem te laten administreren (maar dan alleen de dingen die jij expliciet toestaat).

[Cyphax]

Soultaker schreef op donderdag 29 september 2005 @ 16:40:
De root user kan alles op het systeem, dus ook logfiles wissen. Sowieso hoeft de root user geen rechten te wijzigen om een bestand uit te lezen. Als je iemand niet vertrouwd op je systeem moet je 'm geen root rechten geven.

Bestanden coderen zou een oplossing kunnen zijn, maar ik neem aan dat het de bedoeling is dat die bestanden wel door de webserver e.d. gedecodeerd kunnen worden; dan is het dus altijd te omzeilen. Is dat niet de bedoeling dan heb ik een veel makkelijkere oplossing, zet die bestanden er gewoon niet op!

De enige oplossing is om de gebruiker die je niet volledig vertrouwd niet als root user te laten inloggen. Je kunt iets als sudo of een jail gebruiken om 'm toch delen van het systeem te laten administreren (maar dan alleen de dingen die jij expliciet toestaat).

Met dit in je achterhoofd is het misschien het slimst om ze beide een apart account te geven en de rechten van die 2 accounts goed te zetten. Dan kun je het root account met rust laten. Dat lijkt mij sowieso het netst. Als het systeem van jou is moet je de root user voor jezelf houden.

[daft_dutch]

jongens jongens rustig aan er is sudo waar je kan instellen dat een bepaalde users root commandos kunnen uit voeren. als root

sudo dus ^^

[Verwijderd]

hmm sudo klinkt erg goed.

Misschien dat we het daarmee gewoon eens moeten proberen!
In ieder geval hartstikke bedankt voor jullie meningen/oplossingen tot nu toe!

[Gerco]

Ik heb iets soortgelijks pas als vraag van een klant gekregen. Ze hebben een AIX server colocated ergens bij KPN. KPN doet het beheer van het ijzer en het OS en heeft daarom dus root rechten. De klant wil echter de garantie dat KPN hun bedrijfsdata op die server niet kan lezen of wijzigen.

Ik heb ze verteld dat root op een unix systeem in principe God is en dat je daar niets tegen kan doen, maar heb ik wel gelijk gehad? 1 van hun medewerkers kwam vervolgens met de opmerking dat Windows dan dus veiliger is, aangezien je een Administrator nog steeds beperkingen kan opleggen, is dat waar? Ik vraag me af wie er dan precies die beperkingen moet beheren.

[ Voor 22% gewijzigd door Gerco op 29-09-2005 16:58 ]

[McCloud]

Root in Unix/Linux is gewoon GOD, punt uit. Om te zeggen dat Windows veiliger is omdat je een Administrator nog kan beperken is onzin, er zal altijd iemand moeten zijn die dat Administrator account weer beheerd.

Zoals al eerder gezegd, op een Unix/Linux machine kan je ook een Administrator account maken zonder dat deze alle root-rechten heeft, bijvoorbeeld met sudo of door een account te maken die je in een adminstrator group plaatst. Als je vervolgens deze group rechten geeft op de specifieke commandos die ze mogen uitvoeren (waaronder commandos die normaal alleen door root mogen worden uitgevoerd) heb je het probleem ook opgelost.

Windows veiliger, LOL. Als ik iets heb ontdekt na mijn overstap op Linux is het wel dat rechten een stuk makkelijker te beheren zijn op een Unix/Linux bak.

[smokalot]

de beheerder van een OS heeft altijd toegang tot de hardware, bij windows is dit dus schijnveiligheid.

Als iemand root heeft kun je dus altijd het loggen uitzetten, logfiles veranderen, alle bestanden inzien, enz. Wellicht zou je het loggen via het netwerk kunnen laten verlopen, waarbij ook de poging om het loggen te stoppen kan laten loggen. Als je dan ziet in je log dat het loggen uitgezet is weet je dan dus dat er iets niet klopt.

Maar goed, sudo is inderdaad een stuk betere oplossing, en een stuk makkelijker voor elkaar te krijgen.

[Seth4Chaos]

smokalot schreef op donderdag 29 september 2005 @ 17:43:
-knip-
Als iemand root heeft kun je dus altijd het loggen uitzetten, logfiles veranderen, alle bestanden inzien, enz. Wellicht zou je het loggen via het netwerk kunnen laten verlopen, waarbij ook de poging om het loggen te stoppen kan laten loggen. Als je dan ziet in je log dat het loggen uitgezet is weet je dan dus dat er iets niet klopt.
-knip-

jah en als je nou eerst een firewall regel inlaad die uitgaand UDP verkeer van/naar poort 514 blocked (want dat kan root ) dan kan die vervolgens zonder problemen de logging stoppen zonder dat het extern gelogged word en kan die weer aanpassen wat die wil.
Zoals al eerder gezet is hier Root=God en daar doe je niets aan. Wil je een account met beperkingen zie dan de tips hierboven (sudo enzo dus)

[Confusion]

Iedere keer dat ik iets over sudo ben tegengekomen stond het omringt met waarschuwingen dat je ermee moet oppassen, omdat het schijnveiligheid kan geven. Het kan dus de moeite waard zijn even te Googlen op sudo en security oid.

[Seth4Chaos]

Confusion schreef op donderdag 29 september 2005 @ 19:59:
Iedere keer dat ik iets over sudo ben tegengekomen stond het omringt met waarschuwingen dat je ermee moet oppassen, omdat het schijnveiligheid kan geven. Het kan dus de moeite waard zijn even te Googlen op sudo en security oid.

Tja als je iemand sudo rechten geeft op vi (of wat voor editor ook) dan kan je 'sudo vi /etc/sudoers' doen en jezelf extra rechten geven en dus ook weer alles kunnen doen.

verder moet je ook oppassen dat je 'sudo -s' niet kan uitvoeren want ook dan kan je weer alles.

kortom je moet goed opletten als je iemand sudo rechten geeft.

[daft_dutch]

je moet inderdaad op passen met sudo. maar als je wilt dat de "alsmost root" wil laten updaten instaleren en aanpassen kan je hem (debian voorbeeld) apt-get en dpkg-reconfigure sudo recht geven.
apt-get om updates te instaleren en dpkg-reconfigure om huidige pakketen aan te passen.

natuurlijk kan je met apt-get remove --purge libc6 in 1 klap je hele systeem saboteren.
dus voordat je hem ontslaat zijn access verwijderen . maar toch hij kan nooit het systeem overnemen

je moet voorkomen dat de gebruiker door middel van sudo werkelijk root kan worden.
hier voor de volgende regels in acht nemen:

1) geen aplicaties die andere applicaties kunnen uitvoeren. - duidelijk
2) geen editors - al vermeld in een voorgaande post
3a) geen sudo geven aan aplicaties waar de user zelf schijf toegang heeft. - deze kan de aplicatie vervangen door een andere. bijvoorbeeld bash. met scripts idemdito.
3b) opletten moet chmod

edit:
bij deze wil ik ook nog een andere oplossing geven
UML (user mode linux) linux over linux (lees vm ware of iets dergelijks)

hier mee kan je je linux server opdelen in meerde linuxen.
splits de taak verdeling op tussen de echte linux en de uml en geef hem root op de uml.

+ 100% save (de uml is een gebruiker en kan niet eens een commando naar de echte linux door sturen)
- performence verlies
- veel lastiger op te zetten dan sudo

[ Voor 22% gewijzigd door daft_dutch op 30-09-2005 03:38 ]

[Seth4Chaos]

daft_dutch schreef op vrijdag 30 september 2005 @ 03:25:
-knip-
natuurlijk kan je met apt-get remove --purge libc6 in 1 klap je hele systeem saboteren.
dus voordat je hem ontslaat zijn access verwijderen . maar toch hij kan nooit het systeem overnemen
-knip-

Hij zou natuurlijk een eigen sudo package kunnen maken waar die zijn eigen /etc/sudoer file in heeft staan en zo weer volledige controle over het systeem krijgen

[Lethalis]

Gerco schreef op donderdag 29 september 2005 @ 16:56:
Ik heb iets soortgelijks pas als vraag van een klant gekregen. Ze hebben een AIX server colocated ergens bij KPN. KPN doet het beheer van het ijzer en het OS en heeft daarom dus root rechten. De klant wil echter de garantie dat KPN hun bedrijfsdata op die server niet kan lezen of wijzigen.

Ik heb ze verteld dat root op een unix systeem in principe God is en dat je daar niets tegen kan doen, maar heb ik wel gelijk gehad? 1 van hun medewerkers kwam vervolgens met de opmerking dat Windows dan dus veiliger is, aangezien je een Administrator nog steeds beperkingen kan opleggen, is dat waar? Ik vraag me af wie er dan precies die beperkingen moet beheren.

De domain administrator

Wat jouw klant moet doen: zelf het beheer overnemen en KPN root rechten ontzeggen. En ook in Windows: als je een lokale administrator beperkt, kan hij zelf die beperkingen opheffen. En als je Windows auditing aan hebt staan, kan hij alsnog berichten uit de eventlogs laten verdwijnen

[Gerco]

Lethalis schreef op vrijdag 30 september 2005 @ 09:29:
En ook in Windows: als je een lokale administrator beperkt, kan hij zelf die beperkingen opheffen. En als je Windows auditing aan hebt staan, kan hij alsnog berichten uit de eventlogs laten verdwijnen

Met andere woorden: Op Windows is (local) Administrator ook God? Kan een local admin de beperkingen die hem zijn opgelegd door de domain admin weer opheffen bijvoorbeeld?

Ik ga de beveiliging van mijn linux-server maar eens herzien, aangezien ik natuurlijk zo weinig mogelijk als root wil doen. Het eerste wat ik nu doe als ik erop inlog is "su -" en daar wil ik eigenlijk vanaf. Ik bedacht dat ik mezelf rechten kon geven op de verschillende configfiles en dan rechten om /etc/init.d/* als root uit te voeren. Zou dat voldoende zijn om de server als non-root te kunnen administreren?

[Cyphax]

Gerco schreef op vrijdag 30 september 2005 @ 10:34:
[...]


Met andere woorden: Op Windows is (local) Administrator ook God? Kan een local admin de beperkingen die hem zijn opgelegd door de domain admin weer opheffen bijvoorbeeld?

Ik ga de beveiliging van mijn linux-server maar eens herzien, aangezien ik natuurlijk zo weinig mogelijk als root wil doen. Het eerste wat ik nu doe als ik erop inlog is "su -" en daar wil ik eigenlijk vanaf. Ik bedacht dat ik mezelf rechten kon geven op de verschillende configfiles en dan rechten om /etc/init.d/* als root uit te voeren. Zou dat voldoende zijn om de server als non-root te kunnen administreren?

Misschien is sudo slimmer dan. Daar moet je het root wachtwoord voor hebben namelijk. Als iemand jouw account overneemt op de een of andere manier zou ie alle rechten die jij hebt ook kunnen misbruiken. Als jij met sudo werkt en je account is verder beperkt, dan kan iemand die je account kaapt nog steeds niets zonder het root wachtwoord.

[Gerco]

Cyphax schreef op vrijdag 30 september 2005 @ 11:05:
Misschien is sudo slimmer dan. Daar moet je het root wachtwoord voor hebben namelijk.

Het hele idee van sudo is dat je het root password niet nodig hebt. Je moet namelijk je eigen password intikken, niet dat van root. Ik gebruik dus ook sudo, vooralsnog lijkt het goed te werken.

Ik heb nu bepaalde users de mogelijkheid gegeven om "/etc/init.d/apache2 stop|(re)start|reload" uit te voeren met sudo en de rechten op de configfiles wat aangepast zodat die bewerkbaar zijn met die non-root accounts. Bewust geen sudo rechten voor een editor gegeven, dan kunnen ze wel meer aanpassen dan alleen die files .

Helaas zijn die bepaalde accounts nu wel een groter security risk geworden dan ze eerst waren, ze kunnen immers meer. Is het misschien een idee om een user "apacheadmin" te maken om die dingen te kunnen editen, ssh login van die user te verbieden en de normale accounts ongemoeid te laten?

[Sendy]

Op Linux kan je ook extended attributes (w.o. acl's) gebruiken om rechten te ontnemen. Dit zit standaard ingebouwd in tenminste ext2, ext3 en xfs.

Op Debian moet je een pakketje "acl" installeren om setfacl en getfacl te kunnen gebruiken.

[ Voor 8% gewijzigd door Sendy op 30-09-2005 11:30 ]

[Cyphax]

Gerco schreef op vrijdag 30 september 2005 @ 11:28:
[...]

Het hele idee van sudo is dat je het root password niet nodig hebt. Je moet namelijk je eigen password intikken, niet dat van root. Ik gebruik dus ook sudo, vooralsnog lijkt het goed te werken.

Oh, duh.. tuurlijk.
Ik gebruik sudo helemaal niet, als ik wat op m'n eigen systeem gedaan moet hebben su ik naar root en voor overige zaken stel ik de rechten goed in. Systeembeheer doe ik echter dus wel altijd met root.

[Gerco]

Cyphax schreef op vrijdag 30 september 2005 @ 11:31:
Systeembeheer doe ik echter dus wel altijd met root.

Daar is ook weinig tegenin te brengen, het is alleen de vraag wat je onder systeembeheer verstaat. Het toevoegen/aanpassen van een vhost vind ik daar niet onder vallen en ik vind dus dat je daar geen root voor moet hoeven worden.

De enige reden dat dat "moet" is omdat je een tcp poort < 1024 moet openen voor je webserver, het zou prettig zijn als ik gewoon de apache2 binary het recht kon geven om dat te doen, scheelt gedoe. Dan kun je met user rechten verder wel instellen wie die binary precies mag uitvoeren.

Ik probeer een situatie te maken waarbij je met minimale rechten toch je werk kan doen, elke keer su'en naar root als je een instelling wilt aanpassen vind ik not-done op een produktieserver. Voor systeembeheerstaken (software installeren ofzo), heb je natuurlijk wel root nodig. Ik maak dus onderscheid tussen een applicatiebeheerder en een systeembeheerder.