Hee?!

Zelf ben ik behoudend als het gaat om upgrades, met een uitzondering voor security bugfixes. Als iets de juiste functionaliteit biedt en voldoende veilig is het in mijn ogen niet per se noodzakelijk altijd "the latest and the greatest" software op uw machines te installeren. Schreuders [1] eerste wet schrijft immers voor dat het in eerste instantie om de gewenste en geboden functionaliteit gaat, met andere woorden: als het voldoende veilig doet wat het moet doen, blijf er dan af.

Schreuders wet en de verwachting dat veel lezers wat oudere hardware en software in gebruik hebben hebben er voor gezorgd dat ik in het laatste artikel ben uitgegaan van een Red Hat 6.1 distributie met upgrade naar een 2.2.20 kernel. Als testmachine heb ik een oude Pentium 133 gebruikt. De al wat oudere, maar zeer stabiele versie 1.1.2 van RSBAC pastte daar uitstekend bij.

Toch ga ik u aanraden (en helpen) te migreren naar de nieuwste stabiele versie: RSBAC 1.2.0. Daar zijn een aantal redenen voor: de nieuwe functionaliteit die versie 1.2.0 biedt is in veel gevallen bijzonder handig. Daarnaast is het administreren van het systeem onder de oude versie niet eenvoudig. Ik geef u hiervan een voorbeeld.

In dit voorbeeld ga ik er van uit dat u de stappen in het vorige artikel heeft gevolgd en dus als security officer een fd_type "Executable" heeft aangemaakt en een role "Greetingsmaster". Herinnert u zich: dit kunt u nazien door als security officer de commando's rc_get_item list_used_fd_types en rc_get_item list_used_roles uit te voeren. Nu maken we als gewone gebruiker een directory aan die we dan door de security officer willen laten beschermen:

$ mkdir .untouchable $ ls .untouchable drwxrwxr-x 3 henk henk 4096 Apr 30 20:49 .untouchable $ _

De default rol voor de gebruiker (in dit geval henk) hadden we verleden keer op 'Greetingsmaster' gezet (op te vragen middels het commando attr_get_user henk rc_def_role).

Log nu aan als security officer en probeert u nu eens om de nieuwe directory van het FD type Executable te maken. Dat geeft een onverwachte verrassing:

secoff:~ > attr_set_fd FD rc_type_fd 03 /home/henk/.untouchable stat for file /home/henk/.untouchable returned error: Permission denied secoff:~ > _

Oei. Wat is hier aan de hand? Wel, heel eenvoudig: naast de extra beveiligingen die RSBAC kent zijn er natuurlijk ook nog de gewone file permissies. En die staan niet toe dat een gewone andere gebruiker zoals secoff bij de bestanden van een andere gewone gebruiker kan komen. Dat is tamelijk onhandig: hoe kan een security officer nu dan in hemelsnaam de bevoegdheden van anderen wijzigen als die anderen hem daar geen toestemming voor kunnen of willen geven? Natuurlijk kan men de RSBAC utilities setuid laten uitvoeren, maar zelfs de root rechten zijn op een RSBAC systeem niet langer meer voldoende.

Als we besluiten om het ACL model ook te implementeren en we gebruiken het meegeleverde script linux2acl om de reguliere permissies over te nemen binnen de ACL structuur komen we een heel eind in de richting van een oplossing. We moeten dan wel ook de security officer (of zijn tools) overal rechten geven binnen ACL.

Dit probleem is met de nieuwe versie 1.2.0 veel eenvoudiger op te lossen, omdat 1.2.0 ook Linux capabilities (CAP) ondersteund. De tools of de security officer kunen dan lees- en zoekrechten krijgen voor alle bestanden op een Linux machine (DAC_READ_SEARCH).

Upgraden is dus op zijn minst handig. Daarnaast kent de nieuwe versie 1.2.0 nog meer leuke voordelen, waaronder:

1. het RC model kan nu een slechts door geheugen en schijfruimte beperkt aantal rollen en typen aan;

2. er zijn vele optimalisaties doorgevoerd, zoals nieuwe, veel snellere geheugen- en disklijsten;

3. er zijn netwerk- en firewall configuraties mogelijk met RSBAC: middels nieuwe systeem typen (SCD) en diverse nieuwe targettypen (NETDEV, NETTEMP en NETOBJ) alsmede het gebruik van zogenaamde templates wordt ook controle van toegang tot het netwerk mogelijk;

4. en de nieuwe versie is nog steeds te gebruiken voor 2.2.20 kernels