Pebret Sikkerhed
Da jeg var purk, var min mor dagplejermor og derfor havde huset et "legerum" hvor hele legokassen blev tømt ud i ferier og weekender.
En mandag efter en sådan extravaganza, kom en af børnene ud i køkkenet til min mor med en stor gul LegoTeknik konstruktion og overrakte den med ordende "Den ligner noget jeg ikke skal lege med".
Denne tankegang er stadig dybt fremmed for operativsystemer og programmer, selvom "Priviledge Separation" bestemt ikke er noget nyt.
Bortset fra nogle få centrale programmer med OpenSSHd og Googles Chromium som poster-boys, er princippet ukendt i vide kredse.
Ikke mindst fordi det er utroligt svært at implementere separationen, den "sandboxing" som Googles Chromium browser laver fylder f.eks 22,350 linier kode i Windows, med avendelse af Discretionarly Access Control og ACL's og sikrer faktisk ikke ret godt.
Men der er håb forude.
Min gode ven og lusepuster, Robert Watson, har i nogle år arbejdet på et projekt der hedder "Capsicum" som udvider POSIX modellen med en "capability" facilitet.
Med Capsicum, kan Chromiums sandboxe laves med blot 100 linier kode under FreeBSD og det lukker alle ladeportene: Filsystem, IPC, net osv.
Dem der har oplevet Robert Watson holde foredrag ved at man virkelig får noget for pengene, men desværre er det stort set krop umuligt at læse hans slides uden lydsporet, hvis man ikke på forhånd ved hvad han taler om. Men der er et par guldkorn i hans slides fra USENIX Security Symposium denne uge der er værd at checke.
Hatten af for Robert: Det er den slags nytænkning der skal til.
phk
Om Poul-Henning KampKommentarer (6)
Capability-orienteret sikkerhed er noget jeg har været en fortaler for gennem et par år. Desværre har det ikke, indtil nu, rigtigt været muligt at få i klassiske operativsystemer. Men det har R. Watson nu lavet om på. Tak for det!
Privsep bliver også benyttet i mange andre systemer end lige dem du nævner. Qmail og Postfix. Xorg, OpenNTPd, tcpdump, etc på OpenBSD.
For dem der ikke kender til ideen: En capability er en "nøgle/token" til at kunne gøre noget i systemet. De kan ikke forfalskes, selv om man skulle prøve. Hvis f.eks. en webserver skal have lov til at kunne kommunikere på en given port, så kan man sende den capability til ham fra operativsystemet. Dermed har han lov til at gøre dette, og kun dette med den capability. Andre kan ikke få adgang da de ikke sidder med den token som giver adgang og ikke kan forfalske sig til den.
Det kan vises, at capabilities er stærkere end den traditionelle UNIX-sikkerhedsmodel. Man kan f.eks. ende op med et system hvor selv superbrugeren ikke har adgang til dele af systemet - og det uden de helt store krumspring.
Ikke helt tilfældigt, så har sprog som Google Go implicit support for capabilities i dets kanalprimitiv. Det skyldes formentlig plan9-historikken blandt Go's forfattere. Erlang har også capabilities: Process ID'er og Referencer er non-forgeable i Erlang. Men for begge sprogs vedkommende handler det ikke i så høj grad om at sikre systemet som det handler om at en programmør ikke ved et uheld gør noget utilsigtet.
-
0 -
0
Det kunne være interessant at forsøge at mappe det ud fra et personid perspektiv.
Umiddelbart ville jeg mene at det er i fuld overenstemmelse med det jeg ville kalde kontekstuel identitet og kontekst isolering.
Det kan langt hen ad vejen være ækvivalent om du definerer en kontekst ud fra den viden som konteksten indeholder eller ud fra de implicitte rettigheder til noget udenfor kontekst, fordi rettighederne i praksis inddrage viden i kontekst.
-
0
-
0
Man kan f.eks. ende op med et system hvor selv superbrugeren ikke har adgang til dele af systemet - og det uden de helt store krumspring.
Ja, det hedder "jail" :-)
Men lige som den privsep der anvendes andre steder, er det en utrolig grovkornet form for capabilities der slet ikke kan udtrykke de nuancer der er behov for.
@Henrik: Robert har lovet at et nyt patch imod FreeBSD 8.1 vil være klart inden længe, det giver det definitive svar på dit spørgsmål. Hold øje med Capsicum siden.
Poul-Henning
-
0
-
0
Nu er jeg ikke så meget inde i sandboxing, men er der (og i så fald: hvad er?) forskel på det PHK beskriver og så Sydbox[1], som Ali Polatel udvikler til exherbo?
-
0
-
0
Jeg kender ikke Sydbox, men efter et hurtigt kig kan jeg ikke se hvorledes de undgår "the usual replacement race" hullet.
Forestil dig et open("/dev/null"...) kald.
Så snart checket har clear'et dig for adgang til /dev/null har du en anden tråd der skifter pointeren ud med en der peger på "/dev/mem" inden kernen når at åbne filen.
Man kan ikke implementere "layered security" hvis man ikke kan sikre argumenterne der arbejdes på og derfor skal man enten wrappe systemkaldene helt, eller lade være at prøve.
Men den rigtige person at spørge er Robert Watson, jeg er bare observatør på sidelinien.
Poul-Henning
-
0
-
0
