[aix] File (private key) blokkeren voor root

[leuk_he]

Er moet ergens een file (of gewoon een klein beetje data) geschreven worden. Deze moet geheim zijn. Echter op een unix systeem mag root alles lezen/schrijven. maar root (systeem beheer) mag eigenlijk absoluut niet bij de file. Is dit te blokkeren?

-verbergen is geen oplossing. (b.v. in een executable encrypten)
-en hoe voorkom je dat de root "su" gebruikt
-en het moet in "batch" (cron ofzo) opgestart worden, een wachtwoord intikken is geen optie.
-root is wel beschikbaar om dit in de bestaande configuratie aan te passen.

[wzzrd]

Niet.
Root is 'god' op een *nix systeem. Hij mag werkelijk letterlijk ALLES. Het verbergen van bestanden voor root zou grote veiligheidsrisico's met zich mee brengen. Naar mijn weten kan dit niet zonder hacks of andere truckjes. En dat is maar goed ook.

[ Voor 12% gewijzigd door wzzrd op 06-03-2003 15:52 ]

[igmar]

leuk_he schreef op 06 March 2003 @ 15:48:
Er moet ergens een file (of gewoon een klein beetje data) geschreven worden. Deze moet geheim zijn. Echter op een unix systeem mag root alles lezen/schrijven. maar root (systeem beheer) mag eigenlijk absoluut niet bij de file. Is dit te blokkeren?

-verbergen is geen oplossing. (b.v. in een executable encrypten)
-en hoe voorkom je dat de root "su" gebruikt
-en het moet in "batch" (cron ofzo) opgestart worden, een wachtwoord intikken is geen optie.
-root is wel beschikbaar om dit in de bestaande configuratie aan te passen.

Heel simpel : Niet. Root kan en mag alles op een systeem, en dat is niet te wijzigen.

[Verwijderd]

simple: encryptie. als het een private key is lijkt het me stug dat je hem niet kunt protecten met een passphrase, anders gpg gebruiken als encryptie mechanisme, of een encrypted file system loop back mounten ofzo. Anywayz, encryptie is de manier om het van de ogen van meneer root af te houden.

-ozy

[Verwijderd]

Idd. Encryptie is het enige wat haalbaar is. Onder linux zou je eventueel nog capabilities van root af kunnen nemen, maar niet zonder de kernel te patchen. Een AIX kernel hacken lijkt mij echter niet reeel mogelijk.

[Verwijderd]

oke, ik had het cron gebruik ff over het hoofd gezien, maar veelal is het dan onmogelijk, behalve als je een ssh keymanager gebruikt, maar dat is niet in alle gevallen toepasbaar. Maar als je zelf beschikt over root, dan zie ik het nut er niet van in.

Alternatieve oplossing is remote opstarten vanuit een box die je wel 100% secure acht.

[leuk_he]

Verwijderd schreef op 06 maart 2003 @ 15:55:
simple: encryptie. als het een private key is lijkt het me stug dat je hem niet kunt protecten met een passphrase,

-ozy

encryptie, dat was ook mijn gedachte.

Een passphrase.... iets wat je intikt. Dit conflicteerd dus met de requirement dat het in batch moet kunne worden opgestart. en alles wat ene gebruiker opstart kan ook root opstarten. (of heeft gpg nog andere opties ofzo)

[Hmzaniac]

maarja.. de vraag is.. als je de root user niet vertrouwt, waarom gebruik je het systeem dan uberhaupt? encrypted loopback filesystems zijn leuk, maar kunnen ook met brute force gekraakt worden. Bovendien, for all you know heeft hij een gebackdoorde /bin/mount..

dus ik vraag me vooral af waarom je dan het systeem nog gebruikt, of als het je eigen systeem is, mensen die je niet vertrouwt root rechten geeft.

[ Voor 3% gewijzigd door Hmzaniac op 06-03-2003 16:27 ]

[leuk_he]

Verwijderd schreef op 06 maart 2003 @ 16:02:
behalve als je een ssh keymanager gebruikt, maar dat is niet in alle gevallen toepasbaar. Maar als je zelf beschikt over root, dan zie ik het nut er niet van in.

Alternatieve oplossing is remote opstarten vanuit een box die je wel 100% secure acht.

wat is een ssh keymanager? [google="ssh keymanager"] kwam niet met duidelijke resultaten in de eerste pagina.

om het in te richten kan ik e.v.t tijdelijk beschikking krijgen over root, maar het moet uiteindelijk draaien onder een "normale" gebruiker

[leuk_he]

Hmzaniac schreef op 06 maart 2003 @ 16:27:
maarja.. de vraag is.. als je de root user niet vertrouwt, waarom gebruik je het systeem dan uberhaupt?
dus ik vraag me vooral af waarom je dan het systeem nog gebruikt, of als het je eigen systeem is, mensen die je niet vertrouwt root rechten geeft.

Nu is de beveiliging helemaal niet bestaand, maar langzaam en zeker worden functies gescheiden, goede file protecties op de file systemen gezet etc etc. uiteraard wordt hier een prioritieten lijstje afgegaan. En private keys, daar heeft 1 bepaald applicatie alleen iets te zoeken. Die zou je dus dicht moeten zetten. Als er encryptie gebruikt wordt heeft dit niet zoveel zin als de key te publiek zou zijn. daar ben ik dus eens effe aan het kijken of dit beter kan.

Nou weet ik dat het niet kan onder unix V, maar wellicht heeft een meer recente aix versie hier iets voor of heeft iemand ideeen hiervoor.

Ik moet nog nadenken over die opmerking of "dan maar vanaf een remote systeem dat je wel vertrouwd." Stel systeem A vertrouw ik niet 100% (dus niet in encryptie termen) maar systeem B wel. Hoe kan A iets triggeren op B zonder dat B weet of A een niet vertwoude of vertroude gebruiker is?

Ik zat meer te denken aan NT achtige oplssingen, waar je ook rechten van administrator kunt halen. Administortor kan ze er wel weer opzetten(anders kun je niet alles beheren), maar dan kun je in de auditing wel zien dat het gebeurt is.

[odysseus]

leuk_he schreef op 06 March 2003 @ 17:05:
Ik zat meer te denken aan NT achtige oplssingen, waar je ook rechten van administrator kunt halen. Administortor kan ze er wel weer opzetten(anders kun je niet alles beheren), maar dan kun je in de auditing wel zien dat het gebeurt is.

Kun je dan zien dat het gebeurd is? Hoe dan? Als administrator alles kan, dan kan hij ook het spoor uitwissen waaraan jij ziet dat het gebeurd is. De enige werkelijke oplossing die mutaties zeker weten opslaat is het plaatsen van een netwerkprinter in een dichtgemetselde kamer, die via een bewaakte kabel verbonden is met het te bewaken systeem...je laat dan elke actie die maar voorkomt gewoon op papier printen .

_{En zelfs dat is niet helemaal waterdicht, omdat een gebruiker eerst zoveel acties uit kan laten voeren dat het papier opraakt en er dus geen dingen meer gelogd kunnen worden .}

[leuk_he]

[quote]odysseus schreef op 06 March 2003 @ 17:11:
Kun je dan zien dat het gebeurd is? Hoe dan? Als administrator alles kan, dan kan hij ook het spoor uitwissen waaraan jij ziet dat het gebeurd is. ....
[sub]

Verdoezelen zou nog kunnen, maar wissen levert sporen op (om de anologie te gebruiken: het papier is plotseling ergens afgescheurd, of de kamer is afgebrand) Zeker als je bedenkt dat logging vaak (ook) op een ander unix systeem gebeurt .

[Hmzaniac]

Dat is waar. Maar het lijkt me sterk dat een admin van een Unix bak zijn logs stuurt naar een logging computer waar hij geen root rechten heeft...

En mijn punt staat nog steeds, je moet de root user onvoorwaardelijk vertrouwen, of het systeem niet gebruiken.

[Verwijderd]

sorry, ssh keymanager moet zijn 'ssh agent' een keymanager is dan vaak weer iets wat deze agent beheert. Anyways, dit is een proces dat in zijn geheugen de gedecrypte private keys bewaart en dan deze voor ssh clients (ssh, sftp, .. ) zodat je via een public private key kan inloggen en andere dingen doen (geencrypte data decrypten) zonder elke keer je passphrase in te typen. Remote gaat dit ook prima, als je inlogt op een remote bak met 'ssh -A' forward je je ssh agent en kun je daar dingen decrypten zonder ooit een passphrase in te typen en zo komen jou private keys nooit op die remote bak.

check ook:
http://www-106.ibm.com/developerworks/library/l-keyc.html
http://www-106.ibm.com/developerworks/library/l-keyc2/
http://www-106.ibm.com/developerworks/linux/library/l-keyc3/

overigens nog 1 fabeltje de wereld uit helpen: encryptie is niet te kraken, ook niet brute force. Uiteraard onder voorwaardes dat er goede passphrases zijn gebruikt en encryptie van redelijke sterkte is gebruikt. En ja het is wel te kraken, maar niet door jou en mij, tenzij je over miljoenen euros beschikt.

-ozy

[odysseus]

Verwijderd schreef op 06 maart 2003 @ 19:02:
overigens nog 1 fabeltje de wereld uit helpen: encryptie is niet te kraken, ook niet brute force. Uiteraard onder voorwaardes dat er goede passphrases zijn gebruikt en encryptie van redelijke sterkte is gebruikt. En ja het is wel te kraken, maar niet door jou en mij, tenzij je over miljoenen euros beschikt.

Je spreekt jezelf nogal tegen: eerst zeg je dat het niet te kraken is, daarna beweer je dat het wel kan als je over veel geld beschikt.

Alle huidige encryptietechnieken zijn te kraken door brute-force alle mogelijkheden te proberen. Er is één uitzondering en dat is het gebruik van een volledig random sleutel die even lang is als je originele bericht ('one-time pad'). Daarvan kun je eenvoudig wiskundig bewijzen dat hij niet gekraakt *kan* worden, ook niet via brute force (het komt er op neer dat je bij het kraken niet weet welke uitkomst de goede is). Probleem hierbij is echter dat een volledig random getal niet haalbaar is.

Er is een patch voor Linux om ook netwerkverkeer als entropy te gebruiken, maar sommigen willen die niet gebruiken omdat netwerkverkeer niet alleen niet random is maar ook door een potentiële cracker te beïnvloeden. Banken gebruiken speciale verzegelde kaarten met nummergenerators die bijna random zijn, maar er zal altijd een bepaalde mate van regelmaat in je entropy zitten. Door die regelmaat is een bericht theoretisch te kraken zonder de sleutel te bezitten. Practisch is het niet mogelijk, maar een absolute beveiliging is er dus niet...

* odysseus heeft het idee dat dit een beetje off-topic is .

[Verwijderd]

oke, nog ff of topic dan maar,

het idee was dat encryptie normaal gesproken niet te kraken is, dus als je bang bent dat jou system administrator door you ge-encrypte dingen gaat decrypten is dat een non issue, encryptie is voor normale mensen niet te kraken, dat was mijn punt. Dus als jij iets veilig wilt hebben op jou harddisk is normale encryptie meer dan voldoende. Tegen vage overheids instanties kun je toch niks doen met encryptie, want het weigeren van het decrypten van die data is ook strafbaar. Ik hoor heel veel mensen roepen dat encryptie niet veilig genoeg is omdat het te kraken is, maar dat argument is dus alleen geldig als je jezelf wilt beschermen tegen de ogen van mensen met miljoenen, nogmaals een non-issue dus.

en dan nog eventjes over one time path, probleem hier is dat je key net zo groot is als je data, hoe ga je die key dan gebruiken? Hoe hou je deze secret, nu kun je je data publiek laten zien, maar je key, die even groot is moet je ineenen super goed beschermen, waarom bescherm je je data niet direct super goed? Het punt is dat je deze key niet meer 'in je hoofd stoppen' en daarmee niet meer goed kunt beschermen, dat maakt one time path juist weer minder veilig dan iets wat beveiligd is met een passphrase. Encryptie van tegenwoordig breekt op zijn zwakste punten, en dat is niet brute force attack, dat is het rondslingeren van passwords/phrases op papiertjes, unencrypted private keys op usb drives etc, of het simpele feit dat de data ook unecrypted nog in een (al dan niet virtuele) prullenbak ligt, of ergens anders te verkrijgen is.
-ozy

[FCA]

odysseus schreef op 06 March 2003 @ 19:13:

[...]

Er is een patch voor Linux om ook netwerkverkeer als entropy te gebruiken, maar sommigen willen die niet gebruiken omdat netwerkverkeer niet alleen niet random is maar ook door een potentiële cracker te beïnvloeden. Banken gebruiken speciale verzegelde kaarten met nummergenerators die bijna random zijn, maar er zal altijd een bepaalde mate van regelmaat in je entropy zitten. Door die regelmaat is een bericht theoretisch te kraken zonder de sleutel te bezitten. Practisch is het niet mogelijk, maar een absolute beveiliging is er dus niet...

* odysseus heeft het idee dat dit een beetje off-topic is .

even verder off-topic hierover:
Op die kaarten zit vaak een radio-actieve bron. Dit is volgens alle huidige natuurkundige theorieen wel volledig random, hoewel je beperkt wordt door technische zaken, zaken als digitalisering van analoge gegevens e.d.

[Verwijderd]

Het is wel mogelijk.
Download kernel 2.4.20 + de GRSEC (www.grsecurity.org) patch.
Maak een ACL voor de betreffende file.
Zelfs root kan nu de file niet meer benaderen. (ps. GRSEC kan in sommige gevallen problemen geven met een config. Maar verder is het een verdomd mooie patch)

[wzzrd]

* wzzrd betwijfelt of de topicstarter wel een kernelletje kan compileren als 'ie geen root is

[Verwijderd]

Verwijderd schreef op 07 March 2003 @ 12:05:
Het is wel mogelijk.
Download kernel 2.4.20 + de GRSEC (www.grsecurity.org) patch.
Maak een ACL voor de betreffende file.
Zelfs root kan nu de file niet meer benaderen. (ps. GRSEC kan in sommige gevallen problemen geven met een config. Maar verder is het een verdomd mooie patch)

Ik zag toch echt AIX in de titel van de topic staan en geen Linux

[Verwijderd]

Verwijderd schreef op 06 March 2003 @ 19:02:
sorry, ssh keymanager moet zijn 'ssh agent' een keymanager is dan vaak weer iets wat deze agent beheert. Anyways, dit is een proces dat in zijn geheugen de gedecrypte private keys bewaart en dan deze voor ssh clients (ssh, sftp, .. ) ...

Op het moment dat je lees toegang hebt tot het stuk geheugen waar de unencrypted key is opgeslagen heb ik de key ook te pakken zonder relatief veel moeite ...

[xzenor]

wzzrd schreef op 07 March 2003 @ 12:22:
* wzzrd betwijfelt of de topicstarter wel een kernelletje kan compileren als 'ie geen root is

Zelfs als je 'wel' root bent is dat in IAX best wel ehm... onmogelijk?
ik geloof dat er geeneens standaard compilers voor IAX zijn..
die moet je aanvragen bij IBM geloof ik..

[Hmzaniac]

En dan nog. Als je de root user niet vertrouwt, heeft ook GrSecurity geen zin. Het kan namelijk net zo hard weer uitgezet worden.

Net zoals dat encrypted bestanden op een bak die je niet vertrouwt echt geen zin hebben. Je kan het dan wel niet brute forcen, maar daar doelde ik ook niet op.. ik zat meer in een andere richting te denken:

encrypted loopback fs mounten? root kan /bin/mount backdooren
files encrypten/decrypten? root kan je programma om te decrypten backdooren

Verder zijn er nog legio mogelijkheden, zoals het geheugen uitlezen (al genoemd), het programma waarmee je je encrypted informatie bekijkt een backdoor geven, je kan zelfs je shell al niet meer vertrouwen, want daar zou hij ook mee gekloot kunnen hebben.

[u_nix_we_all]

Dit probleem ken ik uit de praktijk. Als admin van een aantal unix bakken met
grote financiele applicaties ben ik van mening dat ik of mijn collega unix admin
niet de enige zijn die het root wachtwoord weten, dat wij niet meer kunnen garanderen
dat het systeem veilig en stabiel is, en dat doen we dus niet.

Maar voor test en development systemen moet een ontwikkelaar soms vaak dingen als root
doen , en het kan lastig zijn om ons daar steeds bij nodig te hebben.
In dat geval doe ik het zo:
1. Op die systemen is software aanwezig die een snapshot met checksums van alle
files op de machine maakt. Die bestanden bewaar ik op een ander systeem.
2. Het root wachtwoord wordt gewijzigd in iets wat we de betreffende developer
geven.
3. De developer moet alle acties die hij doet opschrijven.
4. Als hij klaar is , wijzig ik het root wachtwoord weer,
kijk zijn lijst door, en check wat dingen, checksums van meeste binairies enzo,
afhankelijk van hoeveel ik die developer vertrouw
5. klaar.

[Hmzaniac]

offtopic:
Je kan ook UML (User Mode Linux)opzetten. hierbij kan je een "virtueel" linux systeem booten binnen een ander linux systeem mbv een installatie op een loopback device. Hiermee kan je bijvoorbeeld als hoster meerdere klanten op dezelfde server zetten, en hierdoor dus goedkopere services aanbieden.( En in jouw geval een developer root rechten geven op een systeem wat je na testen gewoon weer terugzet door het image terug te zetten naar de originele staat

[ Voor 33% gewijzigd door Hmzaniac op 08-03-2003 03:14 ]

[DGTL_Magician]

leuk_he schreef op 06 maart 2003 @ 17:05:
[...]


Nu is de beveiliging helemaal niet bestaand, maar langzaam en zeker worden functies gescheiden, goede file protecties op de file systemen gezet etc etc. uiteraard wordt hier een prioritieten lijstje afgegaan. En private keys, daar heeft 1 bepaald applicatie alleen iets te zoeken. Die zou je dus dicht moeten zetten. Als er encryptie gebruikt wordt heeft dit niet zoveel zin als de key te publiek zou zijn. daar ben ik dus eens effe aan het kijken of dit beter kan.

Nou weet ik dat het niet kan onder unix V, maar wellicht heeft een meer recente aix versie hier iets voor of heeft iemand ideeen hiervoor.

Ik moet nog nadenken over die opmerking of "dan maar vanaf een remote systeem dat je wel vertrouwd." Stel systeem A vertrouw ik niet 100% (dus niet in encryptie termen) maar systeem B wel. Hoe kan A iets triggeren op B zonder dat B weet of A een niet vertwoude of vertroude gebruiker is?

Ik zat meer te denken aan NT achtige oplssingen, waar je ook rechten van administrator kunt halen. Administortor kan ze er wel weer opzetten(anders kun je niet alles beheren), maar dan kun je in de auditing wel zien dat het gebeurt is.

Het is eigenlijk heel simpel. Je probleem benader je alleen vanaf de verkeerde kant. Traditioneel kan een systeembeheerder namelijk overal bij. In sommige bedrijven (mischien de meeste?) is dit niet gewenst. Echter er mist vaak een technische oplossing om tegen te gaan dat de Superuser alles kan lezen/bewerken. Hoe los je dit probleem op? Simpel, de Superuser sluit een contract af met de directie van het bedrijf. In dit contract wat door beide partijen wordt ondertekend verklaart de Superuser dat hij/zij niet in de bestanden zal kijken. Op straffe van vervolging/dwangsom. Op deze manier zit je waterdicht ingebakken.

[blaataaps]

DGTL_Magician schreef op 08 March 2003 @ 14:12:
[...]

Op deze manier zit je waterdicht ingebakken.

Ik zie nergens een waterdichte oplossing eigenlijk?
Ik zie een belofte, die bestraft wordt als hij gebroken wordt, maar dit een waterdichte oplossing noemen gaat wat ver. Een nette admin neust toch al niet zomaar door andermans files. En ook al laat je hem beloven dat niet te doen, dan heb je niet de garantie dat hij het echt niet doet. Als hij je data echt niet mag zien, zal het feit dat hij moet betalen nadat hij het gezien heeft je worst wezen, dan is het leed al geschied, lekker waterdicht zeg.

[Verwijderd]

u_nix_we_all schreef op 07 March 2003 @ 18:57:
Dit probleem ken ik uit de praktijk. Als admin van een aantal unix bakken met
grote financiele applicaties ben ik van mening dat ik of mijn collega unix admin
niet de enige zijn die het root wachtwoord weten, dat wij niet meer kunnen garanderen
dat het systeem veilig en stabiel is, en dat doen we dus niet.

Maar voor test en development systemen moet een ontwikkelaar soms vaak dingen als root
doen , en het kan lastig zijn om ons daar steeds bij nodig te hebben.
In dat geval doe ik het zo:
1. Op die systemen is software aanwezig die een snapshot met checksums van alle
files op de machine maakt. Die bestanden bewaar ik op een ander systeem.
2. Het root wachtwoord wordt gewijzigd in iets wat we de betreffende developer
geven.
3. De developer moet alle acties die hij doet opschrijven.
4. Als hij klaar is , wijzig ik het root wachtwoord weer,
kijk zijn lijst door, en check wat dingen, checksums van meeste binairies enzo,
afhankelijk van hoeveel ik die developer vertrouw
5. klaar.

Hmm, zou je voor zoiets niet veel beter sudo kunnen gebruiken? Dus die developer via sudoers file alleen voor een bepaalde taak die hij nodig heeft rechten geven. Die taak kan hij dan uitvoeren met zijn eigen wachtwoord. Lijkt mij toch een stuk veiliger dan elke keer een root wachtwoord meegeven aan een developer.