| ### Log session started at Tue Dec 10 20:49:28 2002 ### | |
| garoeda | sarnold: goedenaond iedereen, vandaag gaat Chris wright ons vertellen over de Linux Security Modules interface die momenteel in de 2.5 reeks van de kernel geimplementeerd wordt |
|---|---|
| garoeda | woord aan cdub (chris) |
| garoeda | vandaag ga ik spreken over het linux security modules project (LSM) |
| garoeda | dank u allen voor de aanwezigheid |
| garoeda | ik zou willen starten met een kort overzicht waar LSM vandaan komt, een historisch overzicht |
| garoeda | de 2001 kernel bijeenkomst in 2001 is een goed startpunt |
| garoeda | een lid van het SELinux team (Pete Loscoco) toonde SELinux aan de vergadering met een voorstel om het aan de kernel toe te voegen |
| garoeda | linux en anderen vonden dat SELinux te indringend was en enkel een specifiek probleem oploste, daardoor bleven andere security projecten op de achtergrond |
| garoeda | dit had tot gevolgd dat Linus een framework vroeg dat verschillende andere security projecten ondersteunde dmv plugbare modules |
| garoeda | dit was de geboorte van het LSM project |
| garoeda | bijna ogenblikkelijk begonnen leden van verschillende security projecten samen te werken om een framework te ontwikkelen dat de verschillende security projecten zou ondersteunen |
| garoeda | dit frameworkd werd gebouwd op een aantal veronderstellingen |
| garoeda | 1. het framework zou generisch genoeg moeten zijn om verschillende security modellen te ondersteunen |
| garoeda | 2. het mag geen significante overhead op de werking hebben (de werking vertragen) |
| garoeda | 3. Het zou alleen maar ACcess Control security modellen ondersteunen (betekend: volledige audit, vaak nodig voor accreditatie is niet ondersteund) |
| garoeda | 4. het moest de al bestaande mogelijkheden ondersteunen |
| garoeda | dit leidde het LSM project naar zijn huidige design dat gedeeltelijk 'gemerged' is met de 2.5 kernel |
| garoeda | vraag: meer uitleg over access control versus full audit |
| garoeda | zeker |
| garoeda | vaak leiden 'Common Criteria' of Orange Book certificaties tot een verscheidenheid van security verbeteringen |
| garoeda | waarvan één al duidelijk: access control |
| garoeda | een ander aspect van certificatie is de mogelijkheid om in realtime een audit te doen van de transacties in en systeem |
| garoeda | dus, niet alleen de toegang van proces AAA tot object BBB tegenhouden maar dit ook bijhouden op een gestructureerde manier |
| garoeda | deze logging/auditing is buiten het bereik van het LSM project |
| garoeda | dus, laat me beginnen met de verschillende aspecten van LSM te ontleden |
| garoeda | maar eerst een snelle vraag: |
| garoeda | kan LSM functionaliteit ondersteunen die de OpenBSD mensen Privilage Separation noemen? |
| garoeda | ja |
| garoeda | ;-) |
| garoeda | ok, hier zijn een paar basics van het LSM framework |
| garoeda | 1. het biedt de mogelijkheid een nieuwe security module te registreren |
| garoeda | 2. het geeft de in de kernel aanwezige hooks zodat de module access control kan uitvoeren |
| garoeda | 3 'it treat'? brengt de kernel tot zijn basisobjecten en beschermt fundamenteel de toegang tot de data van de objecten |
| garoeda | registratie van de module is simpel: de module vult de benodigde callbacks en roept register_security() aand |
| garoeda | een vraag: is er een lijst van objecten waarvoor security modules geschreven kunnen worden? |
| garoeda | daar ga ik het nog over hebben ;-) |
| garoeda | laat ons snel een blik werpen op de lijst van objecten die beschermd zijn, dan kijken we naar het geval 'syscall' |
| garoeda | het LSM framework houdt de toegang tot basis kernel opbjecten in de gaten, hieronder vallen: super blocks, inodes, binrpm (tijdens programmauitvoering), ipc objects, semaphores, mqueues, shared geheugen |
| garoeda | het bindt zich ok aan de netwerk stack op enkele niveaus (socket niveau, transport niveau, netwerk niveau) |
| garoeda | dus, basis kernelobjecten definieren is intrinsiek ver van de syscall entry points |
| garoeda | het syscall entry point geef ons een mooie userspace abstractie om te communiceren met de services die de kernel ons biedt |
| garoeda | maar, het werkt niet met kernel primitieven zoals dentry's en inode's |
| garoeda | dus het syscall entry point neemt data van de gebruiker (vaak strings in de fs laag) en converteert ze tot kernel objecten. dit wordt gedaan door 'pathname resolutie' |
| garoeda | de kernel copieert deze data en vertaalt het in een niet-atomaire manier dus race condities kunnen ontstaan door enkel het syscall entry point te gebruiken |
| garoeda | (noot vertaler: ik twijfel aan bovenstaande zin) |
| garoeda | uiteindelijk, het syscall entry point beschrijft wat de gebruiker kan doen met het systeem |
| garoeda | dus LSM moet ons beschermen tegen al deze acties |
| garoeda | daardoor is het niet ongewoon om LSM 'hooks' te zien die verdacht veel op het syscall entry point lijken |
| garoeda | in feite, de socket internal api is gelijk aan de socket syscall api |
| garoeda | riel_: does that answer your question |
| garoeda | vraag: kan je een voorbeeld van een race condition geven |
| garoeda | ja, open("foo") |
| garoeda | foo wordt in de kernel gecopieerd en opgezocht, als de LSM interface voor de vertaling was kon het opvragen en toegang geven |
| garoeda | dan zou een andere thread ook kunnen wijzigen, en de kernel zou dan newfoo zien, weten dat het voorbij LSM ging en het opvragen |
| garoeda | blam |
| garoeda | ok, om samen te vatten sinds er vragen tussenvielen |
| garoeda | het LSM framework is een simpele 'hooking' api, het biedt registratie en in-kernel callbacks |
| garoeda | vraag: een nieuwe kernel level thread ? anders begrijp ik het niet |
| garoeda | nee, het draait in userspcace |
| garoeda | vraag: kan men verscheidende security modules laden tegelijkertijd en zoja, wat zijn de beperkingen |
| garoeda | dat is een interessante vraag |
| garoeda | laat me nog even doorgaan en dan beantwoord ik je vraag |
| garoeda | een van de dingen die de LSM interface biedt is de mogelijk om kernel objecten te labelen met security id's |
| garoeda | dit is de basis om te beslissen of een actie veilig is. de LSM module kan de security id van de taak vergelijken het met het security id van de inode bv |
| garoeda | door security labeling is het moeilijk om verschillende modules de LSM ruimte te laten delen op hetzelfde moment |
| garoeda | (zonder toevoegingen aan de interface te doen zodat men kan weten welke module een object onderzoekt) |
| garoeda | linus wilde dit niet |
| garoeda | en in feite, security onderzoek toont dat willekeurige security modellen samenstellen en willekeurige resultaten produceren |
| garoeda | wat dus niet gewenst is |
| garoeda | dus, de LSM interface biedt de mogelijkehid om modules te stacken maar hiervor is wel een module nodig die het stapelen beheert. eigenlijk iemand die kan beslissen hoe de resultaten van de verschillende moduls samen te vatten |
| garoeda | er is zo een module geschreven alhoewel ze geen deel uitmaakt van de LSM tree |
| garoeda | dit is een onderdeel waar toekomstige ontwikkelingen het huidige gedrag zullen veranderen |
| garoeda | laat ons nu iets anders volgen, KISS |
| garoeda | vraag: zijn de syscall hooks en callbacks pointers naar functies die ingevuld moeten worden wanneer we een security module registreren? |
| garoeda | de LSM interface is een structuur van callback pointers, dit is het enige wat je moet invullen om te registreren |
| garoeda | sommige callback pointers hangen zeer nauw samen met het syscall entry point dat ze beschermen, maar niet allemaal |
| garoeda | we kunnen kijken naar een simpele oproep om te zien hoe dit er in code uitziet |
| garoeda | de meeste security modules gaan kijken naar, bijvoorbeeld, het maken van een nieuwe task en specifiek execve() die je uitvoeringsdomein kan veranderen |
| garoeda | vraag: hoeveel overhead heb je met die hooks en waar liggen de grootste performantie verliezen |
| garoeda | de overhead gemeten in macro benchmarks is zeer klein |
| garoeda | 0 tot 2% |
| garoeda | vraag: of is dit meer verbonden met de implementatie van de hooks in de security module? |
| garoeda | absoluut |
| garoeda | de netwerk hooks hebben neiging meer overhead te geven |
| garoeda | maar een slechte gecodeerde hook kan een operatie serialiseren die anders concurrente en zeer geoptimiseerd verloopt |
| garoeda | dus de module zelf is critisch in de systeemperfomantie metingen |
| garoeda | het is mogelijk een module te maken, juist om het framework te testen |
| garoeda | en daar zien we dat de netwerk stack een opvallende impact heeft |
| garoeda | ook zien we dat stat open/close en unlink een grotere impact hebben dan de ander fs hooks |
| garoeda | beschouw alles dat het kernel path (of dentry) moet opzoeken meerdere toegangschecks zal ondergaan, een op iedere directory en een check op het uiteindleijke object, dus dit is niet verwonderlijk |
| garoeda | ok, ik ging dus een simpel functieoproepschema tonen |
| garoeda | execve("/bin/foo") |
| garoeda | dit gaat het ./bin/foo object opzoeken en veranderen in een kernel bestands pointer |
| garoeda | deze opzoeking zal een aantal toegangschecks oproepen op "/" en "/bin" en "/bin/foo' |
| garoeda | dan, veronderstellende dat men volledige toegang tot het pad heeft, de binformat handlers zullen gequeried worden |
| garoeda | tijdens deze uitvoering wordt een binrpm structuur gemaak en LSM geeft deze een label |
| garoeda | dit wordt duidelijk als je denkt aan een UNIX setuid programma |
| garoeda | de task zou een label hebben, bijvoorbeeld (uid 500 == chris) |
| garoeda | maar de binrpm structuur zou een ander label hebben, bijvoorbeeld 0 |
| garoeda | later wordt de module ondervraagd en is het in orde om het nieuw programma uit te voeren. dit bevat mogelijk de transitie van de taak naar een nieuw security domein |
| garoeda | dit zou 'elevated' of 'lowered' kunnen zijn |
| garoeda | om dit in de code te volgen zou iemand kijken naar de bprm gebaseerde LSM hookds |
| garoeda | eens de task een label heeft, via fork of exec, alle toekomstige toegang tot kernel objecten (superblocks via mount(2), files via open/read/write, netwerk via sockets ap) |
| garoeda | moet gaan via de LSM module, en de labels van de kernel objecten worden vergeleken met het task label |
| garoeda | dit is het fundamentele gedrag van LSM |
| garoeda | vraag: maar waarom toegang toelaten van upped sec-levels van unsecured sec-level via het hoofdlevel (????) |
| garoeda | ik ben niet zeker of ik de vraag versta, dit is een security policy vraag |
| garoeda | bijvoorbeeld, het kan in ok zijn voor het /bin/foo security domein (van execve("/bin/foo") |
| garoeda | om /bin/bar op te roepen |
| garoeda | en overeenkomstig de policie, kan het een manier zijn om hogere privileges te verkijken, maar ook niet. dit is allemaal gedefinieerd door de policy die gecodeerd is in de security module |
| garoeda | in feite is dit een van de kritische eigenschappen van LSM |
| garoeda | de policiy is in de module |
| garoeda | het framework geeft er niet om |
| garoeda | vraag: behandelt LSM het doorgeven van filedescriptors via unix domain sockets? |
| garoeda | absoluut |
| garoeda | (netsplit) |
| MJesus | garoeda please repeat here from: |
| garoeda | vraag: behandelt LSM het doorgeven van filedescriptors via unix domain sockets? |
| garoeda | absoluut |
| garoeda | (momenteel druk bezig met het aan elkaar rijgen van de teksten) |
| garoeda | het is mogelijk om het doorgeven van file descriptors te controleren |
| garoeda | sommige policies kunnen dit toelaten maar als je een lager security niveau fd krijgt is het mogelijk dat je task , of althans het security domein ervan ook naar beneden gaat |
| garoeda | je kan ook simpelweg niet toelaten dat er fd's doorgegeven worden |
| garoeda | een vaak gehoorde vraag: zijn modules niet insecure? |
| garoeda | men kan hier debatten rond voeren maar LSM hoeft niet modulair te zijn, het kan compleet statisch zijn, net als andere modules. dit is dus niet echt een probleem |
| garoeda | en natuurlijk, de security module kan het laden en ontladen van modules in de gaten houden, je kan dus vrij secure zijn |
| garoeda | ok, zoals ik al eerder zei, LSM is voor access controle |
| garoeda | het is veooral gebruikt voor Mandatory Acces Control (MAC) maar kan meer doen |
| garoeda | het standaard UNIX Discretionary Access Control is nog altijd volledig intact |
| garoeda | er is een ordering probleem tussen DAC en MAC |
| garoeda | over het algemeen plaatsen we LSM hooks waar er reeds een kernel permission checking is |
| garoeda | en we checken eerst LSM om dan terug tte vallen op DAC checks (zoals vereist door MAC) |
| garoeda | en is daarom is het anders, vooral wanner het over GPL en kernel code gaat |
| garoeda | de meeste kernel ontwikkelaars zijn zeer bezorgd om GPL en willen niet dat hun code misbruikt wordt in een niet-GPL situatie |
| garoeda | daarom is de LSM API een enkel-GPL API |
| garoeda | dit komt omdat het zo nauw verbonden is met het hart van de kernel, daarom is het belangrijkt om duidelijk te maken dat de security modules een deel van de core kernel zijn |
| garoeda | en een afgeleid werk van de kernel is |
| garoeda | zet hier de juiste "ik ben geen advocaat" disclaimer |
| garoeda | ik ben niet zeker wat de mensen gemist hebben tijdens de netsplit |
| garoeda | ik zal nu enkele vragen beantwoorden |
| garoeda | vraag: nu zijn alle LSM toevoegingen en afgeleiden gebonden aan GPl en verwijderen ze zo de de geheime natuur van de LSM operaties |
| garoeda | (noot vertaler: veel twijfel rond deze zin) |
| garoeda | als de geheime ingredient van iedere LSM vrijgegeven wordt, wat is dan het nut van LSM? |
| garoeda | antwoord: |
| garoeda | dit is een belangrijke vraag en ik hoop niet in licentie oorlogen terecht te komen |
| garoeda | ten eerste: het gebruik van de LSM interface ligt dicht tegen de core van de linux kernel |
| garoeda | het hangt rond de linux kernel core objecten en geeft/weigert toegang |
| garoeda | men kan dus argumenteren dat de LSM interface duidelijk afgeleidt is van de linux kernel |
| garoeda | verder, |
| garoeda | in dit geval spreken we over security |
| garoeda | het is een goed geweten feit dat geheimen niet goed zijn voor security |
| garoeda | dit wil niet zeggen dat de code 'open' moet zijn maar het algoritme moet beschikbaar zijn en goed begrepen door de mensen |
| garoeda | anders ben je op de rand van "security through obscurity" |
| garoeda | samengevat: als het vrijgeven van je module de security van de module in gevaar brengt dan is het goed mogelijk dat de module op zichzelf al niet secure is, onafhankelijk van de licentie |
| garoeda | terug naar de licenties: het LSM project geeft niet om de licentie |
| garoeda | we geven wel om het volgende: geef de kernel een security infrastructuur |
| garoeda | linus zei wat hij wilde en wij gaven het hem |
| garoeda | hij vindt dat de LSM api als GPL_ONLY geexporteerd moet worden |
| garoeda | deze opoffering willen we maken, om zeker te zijn dat LSM niet uit de kernel verdwijnt |
| garoeda | (netsplit) |
| garoeda | en dat wilden we behouden |
| garoeda | de mogelijkheden zijn een kleine verbetering op de UID == 0 policy (super user policy) |
| garoeda | maar, de task mogelijkheden zijn redelijk statisch |
| garoeda | capabilities (vertaald als mogelijkheden) zijn gedaan zowel als module als inline code in de kernel |
| garoeda | we splitsten alle capabilities logica en stopten ze achter functies die opgeroepen kunnen worden via de security module |
| garoeda | niet zo lang geleden, gregkh maakt het mogelijk om LSM weg te compileren zodat je met een kernel oude stijl overblijft |
| garoeda | dit roept de capabilities die inline gesplitst waren ipv door de LSM interface |
| garoeda | echter, een van deze capabilities is niet in LSM |
| garoeda | (vertaler: vreemde engelse zin) |
| garoeda | het task label gebruikt om het security domein te identificeren is niet gebruikt door capabilities |
| garoeda | in de plaats daarvan gebruikt het nog altijd het task_structure native capabilities data structuur |
| garoeda | capabilities zijn het vreemde eendje, half in, half uit |
| garoeda | en het primaire doel is om security beslissingen te herzien |
| garoeda | met andere woorden, de meeste MAC modellen beperken toegang als volgt 'mag ik toegang to" yes/no |
| garoeda | maar capabilities overstijgen dit: "ik ben niet verondersteld van toegang te hebben, maar...alstublieft?" yes/nno |
| garoeda | de compatibilieit met capabilities heeft van LSM een andere interface gemaakt dan we oorspronkelijk van plan waren |
| garoeda | rene: sure ;-) |
| garoeda | ik denk dat er nog een onderwerp is waar ik het nog niet over gehad heb |
| garoeda | LSM probeert zo dicht mogelijk bij de core kernel te zitten |
| garoeda | dit betekent dat het niet echt aanwezig is in drivers, filesystems etc.. |
| garoeda | (natuurlijk, de uitzondering is capable() die overal aanwezig is ;-)) |
| garoeda | en de meeste LSM hooks worden aangeroepen vanuit process context |
| garoeda | dit betekent dat de meest LSM hooks opgeroepen worden (on behalf of) als system call |
| garoeda | sommige worden echter opgeropen in interrupt context |
| sarnold | (anyone have questions?) |
| garoeda | meer specifiek, sommige async io data ready events worden afgeleverd en gefilterd door LSM |
| garoeda | hieronder vallen ook inkomende netwerkpacketten |
| garoeda | dus wanneer iemand een LSM module schrijft moet deze op de hoogte zijn van de context waarin de hook opgeroepen kan worden |
| garoeda | ik zal ook vermelden wat we heden ten dage al hebben |
| garoeda | de LSM interface bestaat uit ongeveer 150 callbacks |
| garoeda | ongeveer de helft ervan is samengevoegd met de tree van Linus |
| garoeda | de netwerkcode is klaar om te mergen maar het zal nog wat werk vragen om ze in de kernel te krijgen (wegens de performantie inpact) |
| garoeda | gelukkig maakte gregkh LSM compatibel, dus we hopen dat dit helpt met het performantie argument |
| garoeda | er zijn zo'n 5 modules ontworpen |
| garoeda | de eerste 2 zijn simpel: super user en capabilities |
| garoeda | de derde voegt een beetje Openwall kernel patch toe |
| garoeda | (ok, er zijn er zes ;-) |
| garoeda | de laatste 3 zijn heel complex |
| garoeda | aiee...(ok, er zijn er 7 ;-)) |
| garoeda | gregkh schreef een voorbeeld module die je toont hoe je een policy kan opleggen zodat je een specifiek USB aan je pc moet hangen om root privileges te verkregen (of iets gelijkaardigs) |
| garoeda | de laatste 3, LIDS, DTE en SELinux zijn veel ingewikkelder voorbeelden van het gebruik van LSM |
| garoeda | SELinux gebruikt het meeste van de interface |
| garoeda | en het laat je toe iedere toegang tot ieder object te controleren |
| garoeda | het laat je toe om MAC, TE en MLS te doen . dingen die belangrijk zijn wanneer verschillende gebruikers toegang hebben tot je systeem en het geheime (dikwijls militaire) inforamtie bevat |
| garoeda | er zijn verder ook andere modules, bv SubDomain en de dingen waar HP en SGI aan werken. Er zouden ook nieuwe modules komen van IBM security research |
| garoeda | vraag: TE/MLS ? |
| garoeda | Type Enforcement |
| garoeda | Multi Level Security |
| garoeda | op google kan je complete definities vinden |
| garoeda | vraag: kan je nog eens uitleg geven over id's en het registreren ervan? wanneer wordt een object geregistreerd? en wanneer wordt het opgevraagd als men een syscall maakt. en hoe zijn de intene hooks verbonden met de userland syscalls (pfieuw) |
| garoeda | well, ik zal er snel op antwoorden, anders kunnen we offline verder spreken |
| garoeda | de LSM interface geeft een structuur van callbacks (functie pointers) |
| garoeda | de module vult een structuur met callbacks specifiek aan zijn policy |
| garoeda | dan registreert het zichzelf met het framework |
| garoeda | vanaf dan treden de LSM hooks in de kernel in werking |
| garoeda | de LSM kernelhooks zullen een callback doen naar de module (door de functie pointer) |
| garoeda | de callbacks geven de module informatie, bv een nieuw object wordt gemaakt |
| garoeda | een object wordt vernietigt |
| garoeda | of er is toegang tot een object |
| garoeda | wanneer een nieuw object gemaakt wordt, bv een inode |
| garoeda | maakt de kernel het object, roept dan de module aan om ruimte te voorzien (specifiek voor deze module) |
| garoeda | in het object zodat dit een security label kan bevatten |
| garoeda | (vertaler: weer vreemde zin) |
| garoeda | dit label is dikwijls het security ID |
| garoeda | en later, wanneer het object aangesproken wordt |
| garoeda | het huidige security domein (typisch dat van het lopende proces dat de syscall maakt bijvoorbeeld) |
| garoeda | wordt dan vergeleken met label van het object |
| garoeda | afhankelijk van de policy, kan deze informatie gebruikt worden om toegang te geven/weigeren tot het object |
| garoeda | dat is het in een notendop |
| garoeda | ik hoop het zo iets duidelijker te maken |
| garoeda | LSM is verre van af |
| garoeda | behalve de opkuis en het mergen met de kernel |
| garoeda | zijn we op zoek naar manieren op properder in de kernel infrastructuur in te passen |
| garoeda | dit zou de module interface net houden en bovendien gemakkelijk te onderhouden, nu is dat vrij moeilijk |
| garoeda | we hopen ook nieuwe modules toe te voegen |
| garoeda | ideeën van gelijkaardige projecten, bijvoorbeeld RSBAC (voor linux) en TrustedBSD (bsd natuurlijk) hebben leuke ideeën waarvan we onderzoeken hoe we ze kunen gebruiken |
| garoeda | als je geinteresseerd ben, kijk eens op lsm.immunix.org., het heeft code, docs, mail lists, link,s irc links ,etc |
| garoeda | ik beantwoord zonder probleem vragen |
| garoeda | well, ik zie dat alsof jullie in slaap gevallen zijn ;-) |
| garoeda | dank u zeer voor jullie tij |
| garoeda | (applaus) |
| MJesus | clap clap clap clap clap clap clap clap clap clap |
| MJesus | clap clap clap clap clap clap clap clap clap clap |
| MJesus | clap clap clap clap clap clap clap clap clap clap |
| MJesus | clap clap clap clap clap clap clap clap clap clap |
| garoeda | thank you very much for your attentioin |
| MJesus | thank you very much for your work (excellent work!) |