Tidligere administrator slettet serverne til hostingselskap

[henrikwl]

Hvorfor skal det finnes et root-passord som noen kan?  Jeg beskrev jo akkurat hvordan man enten tar bort muligheten eller håndterer den typen nøkler.

 

 

 

Jeg ser Per Buer har tilført mesteparten av det jeg hadde å si her.

 

I tillegg er jo et oppsett slik du beskriver egentlig kun relevant for software delivery, det finnes flust av hyllevare som opereres på gamlemåten: det installeres på en server og driftes derfra.

 

Du ser heller ikke ut til å ta inn over deg at i dag OS-et tjenestene kjører i som regel kun et av de øverste lagene i stacken - det vanlige er virtuelle serverfarmer (om det er VMWare vSphere eller tilsvarende), og da har administratorene av disse verktøyene brått fullstendig makt over hele den verden som CI-pipelinen din lever i.

 

Det er faktisk ikke alt som kan løses med verktøy, som Per sier så er det noen ting som rett og slett krever god, gammeldags mellommenneskelig tillit.

[oppat]

 

Hvorfor skal det finnes et root-passord som noen kan?  Jeg beskrev jo akkurat hvordan man enten tar bort muligheten eller håndterer den typen nøkler.

 

 

 

Jeg ser Per Buer har tilført mesteparten av det jeg hadde å si her.

 

I tillegg er jo et oppsett slik du beskriver egentlig kun relevant for software delivery, det finnes flust av hyllevare som opereres på gamlemåten: det installeres på en server og driftes derfra.

 

Du ser heller ikke ut til å ta inn over deg at i dag OS-et tjenestene kjører i som regel kun et av de øverste lagene i stacken - det vanlige er virtuelle serverfarmer (om det er VMWare vSphere eller tilsvarende), og da har administratorene av disse verktøyene brått fullstendig makt over hele den verden som CI-pipelinen din lever i.

 

Det er faktisk ikke alt som kan løses med verktøy, som Per sier så er det noen ting som rett og slett krever god, gammeldags mellommenneskelig tillit.

 

 

Joda, jeg vet at det jeg beskrev typisk gjøres for tjenester, men det fungerer også på laveste nivå.

 

Det eneste som trengs er å provisjonere serverne med en bootloader som kan sjekke signaturer for image som lastes.  Det kan de fleste systemer i dag enten ved hjelp av Trusted Computing eller ved at man har en modul i bootloaderen som er installert på disken.

 

Resten, OS-bildet som lastes er da signert av CI-systemet som igjen har nøkler som er blitt kastet (se policy som jeg beskrev).

 

Det er litt plunder og heft mhp nøkkelrotering, men det fikser man med X509-sertifikater om man vil.  Selv uten nøkkelrotering så er et slikt setup ganske sikkert for en ansatt må da fysisk kompromittere serveren for at det skal bli problem.

 

Bruker man Trusted Computing (Intel TXT f.eks.) for sjekking av signaturer blir det vanskelig for den ansatte å omgå systemet med mindre man finner exploits ala de Invisible Labs fant i selve chip-implementasjonen av TXT.

 

Jeg har selv bygget dette - det er ikke spesielt vanskelig.

[Per Buer]

 

 

 

Joda, jeg vet at det jeg beskrev typisk gjøres for tjenester, men det fungerer også på laveste nivå.

 

Det eneste som trengs er å provisjonere serverne med en bootloader som kan sjekke signaturer for image som lastes.  Det kan de fleste systemer i dag enten ved hjelp av Trusted Computing eller ved at man har en modul i bootloaderen som er installert på disken.

 

Resten, OS-bildet som lastes er da signert av CI-systemet som igjen har nøkler som er blitt kastet (se policy som jeg beskrev).

 

Det er litt plunder og heft mhp nøkkelrotering, men det fikser man med X509-sertifikater om man vil.  Selv uten nøkkelrotering så er et slikt setup ganske sikkert for en ansatt må da fysisk kompromittere serveren for at det skal bli problem.

 

Bruker man Trusted Computing (Intel TXT f.eks.) for sjekking av signaturer blir det vanskelig for den ansatte å omgå systemet med mindre man finner exploits ala de Invisible Labs fant i selve chip-implementasjonen av TXT.

 

Jeg har selv bygget dette - det er ikke spesielt vanskelig.

 

Dette kommer ikke spesielt langt i å løse problemet. Jeg greier ikke hvordan en skal kunne greie å løse dette rent teknisk. Unix er, på godt og vondt, ekstremt fleksibelt. Det er ikke noe vanntett skille mellom konfigurasjon og applikasjoner. Så det å få en unix-server til å komme opp med et reverse shell ved bare å endre noe på databasekonfigurasjonen i en tilsynelatende uskyldig fil er relativt greit å få til. Du kan legge på krav om audit av alle endringer - men Unix er nå engang såpass fleksibel at å snike inn en endring har vist seg å være enklere enn det burde være.

 

Og du kan ikke reprovisjonere databasene dine regelmessig når databasen din er en terrabyte og det tar en time bare å få den igang. Du kan kjøre tripwire alt du vil - men i et system hvor det rulles ut endringer daglig blir strømmen av endringer såpass at en team som er litt bakpå aldri vil ha 100% kontroll.

 

Du kan kreve all den signeringen du vil - men root er og blir root. Og selv om du er helt på "immutable infrastructure"-kjøret så vil noen måtte bygge images. Og sysadmin vil mest sannsynligvis ha root på systemet som bygger images. Og da er vi egentlig ikke kommet så skrekkelig mye lenger.

I Unix har sikkerhet har aldri vært noen prioritet. Det var noe en ikke tenkte på de første 10 årene og dermed er vi der vi er idag. Den relativt geniale tanken om små prosesser som arbeider sammen har laget et lappverk som alltid kommer til å være avhengig av tillit mot sysadmin. Du kan komme langt i å skjule de dataene som maskinen prosesserer  mot en snokende sysadmin - men skadeverk kommer du ikke unna. Selv om du greier å kjøre prosesseringen din i en SGX-enclave (garanterer konfidensialitet mot sysadmin) så greier ikke denne å beskytte mot en ondsinnet prosess med root-privilegier som begynner å rable tilfeldige data på blokkenhetene.

 

Husk at de fleste driftsleverandører også er avhengig av å tilby standardiserte plattformer. Så idag vil vel mesteparten være EL6. Det gjør at muligheten deres til å sette opp vanntette systemer er begrenset hvis de skal ha noe å tilby av verdi.