<chapter id="security">
<title
>&kppp; e la sicurezza</title>

<para
>Questa sezione si rivolge principalmente a superutenti (<systemitem
>root</systemitem
>) con alte richieste di sicurezza, o semplicemente a persone interessate nella parte tecnica. Non è necessario leggere questa sezione se usi &Linux; a casa, sebbene potresti in ogni caso imparare qualcosa.</para>

<sect1 id="security-restricting-access">
<title
>Restringere l'accesso a &kppp;</title>

<para
>Un amministratore di sistema potrebbe voler restringere l'accesso a chi dovrebbe poter usare &kppp;. Ci sono due modi per far ciò.</para>

<sect2 id="security-group-permissions">
<title
>Restringere l'accesso con i permessi del gruppo</title>

<para
>Crea un nuovo gruppo (puoi chiamarlo &eg; <systemitem
>dialout</systemitem
> o qualcosa di simile), e inserisci nel gruppo ogni utente che dovrebbe poter usare &kppp;. Digita quindi al prompt:</para>

<screen
><prompt
>#</prompt
> <userinput
><command
>chown</command
> <option
>root.dialout</option
> <filename
>/opt/kde/bin/kppp</filename
></userinput>
<prompt
>#</prompt
> <userinput
><command
>chmod</command
> <option
>4750</option
> <filename
>/opt/kde/bin/kppp</filename
></userinput
>
</screen>

<para
>Ciò assume che &kde; è stato installato in <filename class="directory"
> /opt/kde/</filename
> e che il nuovo gruppo è chiamato <systemitem
>dialout</systemitem
>.</para>

</sect2>

<sect2 id="security-kppps-way">
<title
>Restringere l'accesso nel modo di &kppp;</title>

<para
>Prima di tutto, &kppp; controlla se esiste un file chiamato <filename
>/etc/kppp.allow</filename
>. Se questo file esiste, solo gli utenti nominati in questo file possono effettuare connessioni. Questo file deve essere leggibile da tutti (ma ovviamente <emphasis
>NON</emphasis
> scrivibile). Solo i nomi di utenti sono riconosciuti, così non puoi usare <acronym
>UID</acronym
> in questo file. Qui vi è un breve esempio:</para>

<screen
># /etc/kppp.allow
# le linee di commento come questa sono ignorate
# così come le linee vuote

federico
carlo
daisy
</screen>

<para
>Nell'esempio sopra, solo gli utenti <systemitem
>federico</systemitem
>, <systemitem
>carlo</systemitem
> e <systemitem
>daisy</systemitem
> possono effettuare connessioni, così come gli utenti con un <acronym
>UID</acronym
> uguale a 0 (così non devi elencare <quote
>root</quote
> esplicitamente nel file).</para>

</sect2>

</sect1>

<sect1 id="security-why-suid">
<title
>&kppp; ha il bit <acronym
>SUID</acronym
> attivo? E la sicurezza?</title>

<para
>È virtualmente impossibile scrivere un programma per la connessione senza il bit <acronym
>SUID</acronym
> che sia allo stesso tempo sicuro e facile da usare da parte di utenti inesperti. &kppp; cerca di risolvere i problemi di sicurezza con la seguente strategia.</para>

<itemizedlist>
<listitem>
<para
>Subito dopo l'avvio del programma, &kppp; effettua un fork.</para>
</listitem>
<listitem>
<para
>Il processo master, che gestisce tutte le operazioni dell'interfaccia grafica (come l'interazione con l'utente), perde lo stato <acronym
>SUID</acronym
> dopo il fork, e viene così eseguito con i normali privilegi dell'utente.</para>
</listitem>
<listitem>
<para
>Il processo slave mantiene i suoi privilegi, ed è responsabile di tutte le azioni che richiedono i privilegi di <systemitem
>root</systemitem
>. Per mantenere sicura questa parte, non sono usate chiamate a librerie &kde; o &Qt;, ma solo chiamate di libreria semplici. Il codice sorgente di questo processo è corto (circa 500 linee) e ben documentato, così è semplice da controllare in cerca di falle di sicurezza.</para>
</listitem>
<listitem>
<para
>I processi master e slave comunicano l'un l'altro con le procedure <acronym
>IPC</acronym
> (Inter-Process Communication, o comunicazione interprocesso N.d.T.) standard di &UNIX;.</para>
</listitem>
</itemizedlist>

<para
>Particolari ringraziamenti ad Harri Porten per aver scritto in modo eccellente questa parte di codice. Si pensava che fosse impossibile, ma è riuscito a scriverla in una settimana.</para>

</sect1>

</chapter>