O &kppp; e os problemas de segurançaEsta secção é principalmente para os super-utilizadores (o root) com grandes necessidades de segurança, ou simplesmente para as pessoas interessadas tecnicamente. Não é necessário ler isto se você usa o &Linux; em casa para si, ainda que possa aprender uma ou duas coisas, de qualquer forma.Restringir o acesso ao &kppp;Um administrador de sistemas poderá querer restringir o acesso às pessoas que têm permissão para usar o &kppp;. Existem duas formas de o conseguir.Restringir o acesso com as permissões do grupoCrie um novo grupo (você poderá querer chamar-lhe ligacao ou algo do género), e colocar todos os utilizadores que poderão usar o &kppp; nesse grupo. A partir daí, escreva na linha de comandos:#chown/opt/kde/bin/kppp#chmod/opt/kde/bin/kpppIsto irá assumir que o &kde; foi instalado em /opt/kde/ e que o seu grupo se chama ligacao.Restringir a forma de acesso do &kppp;Antes de fazer algo, o &kppp; verifica se existe um ficheiro chamado /etc/kppp.allow. Se existir, só os utilizadores indicados neste ficheiro poderão estabelecer a ligação. Este ficheiro deverá ser legível por todos (mas obviamente NÃO poderá ter permissões de escrita.) Só os nomes dos utilizadores serão reconhecidos, por isso você não poderá usar os UID's neste ficheiro. Aqui está um pequeno exemplo:# /etc/kppp.allow
# as linhas de comentário semelhantes a esta
# são ignoradas, assim como as linhas em branco
ze
pedro
manel
No exemplo acima, só os utilizadores ze, pedro e manel é que têm permissões para estabelecer a ligação, assim como todos os utilizadores com um UID igual a 0 (por isso, você não terá de pôr explicitamente o 'root' nesse ficheiro).O &kppp; tem o bit SUID activo? E a segurança?É virtualmente possível criar um activador de ligações sem o 'bit' SUID activo e que seja tanto seguro como simples de usar por utilizadores pouco experientes. O &kppp; trata das questões de segurança com a seguinte estratégia.Logo a seguir ao início do programa, o &kppp; faz um 'fork'.O processo-pai, que trata de todas as operações de GUI (como a interacção com o utilizador), descarta o estado SUID a seguir ao 'fork', e corre com permissões de utilizador normal.O processo-filho mantém os seus privilégios e é responsável por todas as acções que necessitem de privilégios do root. Para manter esta parte segura, não são usadas chamadas de bibliotecas do &kde; ou do &Qt; aqui, somente chamadas de bibliotecas simples. O código-fonte para este processo é pequeno (à volta de 500 linhas) e está bem documentado, por isso é fácil detectar nele falhas de segurança.Os processos-pai e filho comunicam com o IPC normal do &UNIX;.Muito obrigado ao Harri Porten por ter escrito este pedaço excelente de código. Pensou-se que seria impossível, mas ele conseguiu fazê-lo numa semana.