# Säkerhetshänsyn med &kppp;

Det här avsnittet är i huvudsak ämnat för systemadministratörer (`root`), de med höga säkerhetskrav eller helt enkelt tekniskt intresserade. Det är inte nödvändigt att läsa det här om du bara använder &Linux; hemma själv, även om du i alla fall kan lära dig ett och annat.

## Att begränsa tillgången till &kppp;

En systemadministratör kan vilja begränsa tillgången med avseende på vem som får använda &kppp;. Det finns två sätt att åstadkomma detta.

### Att begränsa tillgången med gruppskydd

Skapa en ny grupp (du skulle kunna vilja döpa den till `dialout` eller något liknande), och lägg till alla användare som ska få lov att använda &kppp; i den här gruppen. Skriv sedan på kommandoraden:

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

Det här förutsätter att &kde; installerades i `/opt/kde/` och att den nya gruppen heter `dialout`.

### Att begränsa tillgången på &kppp;s eget sätt

Innan det gör någonting, kontrollerar &kppp; om det finns en fil som heter `/etc/kppp.allow`. Om den här filen finns, tillåts bara användare som namnges i den här filen att ringa upp. Den här filen måste vara läsbar av alla (men förstås INTE skrivbar). Bara inloggningsnamn känns igen, så du kan inte använda en UID i den här filen. Här är ett kort exempel:

    # /etc/kppp.allow
    # kommentarrader som den här ignoreras
    # precis som tomma rader

    hans
    karl
    lena

I det ovanstående exemplet, tillåts bara användarna `hans`, `karl` och `lena` att ringa upp, liksom alla användare med UID 0 (så du behöver inte explicit ange root i filen).

## Kppp har SUID-biten satt? Vad händer då med säkerheten?

Det är mer eller mindre omöjligt att skriva ett uppringningsprogram som både är säkert och lätt att använda för ovana användare utan att sätta SUID-biten. &kppp; hanterar säkerhetsproblemen med följande strategi.

- Omedelbart efter att programmet har startat, så skapar &kppp; en ny process (fork).

- Huvudprocessen, som hanterar hela det grafiska gränssnittet med användarpåverkan, släpper SUID-tillståndet efter den nya processen skapats, och kör med normala användarrättigheter.

- Den nya processen behåller sina rättigheter, och ansvarar för alla åtgärder som behöver rättigheter som `root`. För att hålla den här delen säker, så används inga anrop till &kde;- eller &Qt;-biblioteken, utan bara enkla biblioteksanrop. Källkoden för den här processen är kort (omkring 500 rader) och väldokumenterad, så det är lätt att kontrollera den för att hitta säkerhetsluckor.

- Huvudprocessen och den nya processen kommunicerar med vanliga &UNIX; IPC.

Särskilt tack till Harri Porten för att ha skrivit den här utmärkta koden. Det ansågs omöjligt, men han lyckades inom en vecka.