# &kppp; en beveiliging

Deze sectie is hoofdzakelijk voor de systeembeheerder (`root`) met hoge beveiligingsniveaus of eenvoudig technisch geïnteresseerde mensen. Het is niet nodig dit te lezen als u &Linux; alleen thuis voor uzelf gebruikt, hoewel u er wel wat van op kan steken.

## Beperking van toegang tot &kppp;

Een systeembeheerder zou de toegang willen beperken tot wie het is toegestaan om &kppp; te gebruiken. Er zijn twee manieren om dat te doen.

### Beperking van toegang met groepstoegangsrechten

Maak ee nieuwe groep aan (deze zou de naam `dialout` of zoiets) kunnen krijgen en zet elke gebruiker die &kppp; mag gebruiken in die groep. Type daarna op de prompt:

    # chown root.dialout /opt/kde/bin/kppp
    # chmod 4750 /opt/kde/bin/kppp

Hierbij is aangenomen dat &kde; is geïnstalleerd in `/opt/kde/` en dat uw nieuwe groep de naam `dialout` heeft gekregen.

### Beperking van toegang op de manier van &kppp;

Alvorens iets te doen, controleert &kppp; of er een bestand genaamd `/etc/kppp.allow` is. Als zo'n bestand bestaat, dan mogen alleen gebruikers genoemd in dit bestand uitbellen. Dit bestand moet leesbaar zijn door iedereen (maar natuurlijk NIET beschrijfbaar.) Alleen aanmeldnamen worden herkend, zodat u geen UID's in dit bestand kunt gebruiken. Hier is een kort voorbeeld:

    # /etc/kppp.allow
    # commentaar regels zoals deze worden genegeerd
    # evenals lege regels

    fred
    karl
    daisy

In het bovenstaande voorbeeld mogen alleen de gebruikers `fred`, `karl` en `daisy` uitbellen, evenals elke gebruiker met een UID van 0 (u hoeft root dus niet expliciet in deze lijst op te nemen).

## &kppp; heeft het SUID bit aan? Hoe zit dat met de beveiliging?

Het is vrijwel onmogelijk om een uitbel systeem te schrijven zonder het SUID-bit dat zowel veilig is als voor onervaren gebruikers gemakkelijk te gebruiken. &kppp; houdt rekening met de beveiligingszaken met de volgende strategie.

- Onmiddellijk nadat het programma start, doet &kppp; een fork.

- Het hoofdproces, dat alle GUI-bewerkingen uitvoert (zoals interactie met de gebruiker), laat de SUID-status vallen na de fork en draait met normale gebruikersprivileges.

- Het slave-proces behoudt zijn privileges en is verantwoordelijk voor alle acties die nodig zijn met `root`-privileges. Om dit gedeelte veilig te houden, worden hier geen &kde;- of &Qt;- bibliotheekaanroepen gebruikt, alleen eenvoudige bibliotheekaanroepen. De broncode voor dit proces is kort (ongeveer 500 regels) en goed gedocumenteerd, zodat het gemakkelijk voor u is om te controleren op beveiligingsgaten.

- Hoofd- en slave-processen communiceren met standaard &UNIX; IPC.

Speciale dank gaat naar Harri Porten voor het schrijven van dit uitzonderlijke stuk code. Het leek onmogelijk, maar hij heeft het binnen een week gedaan.