Quem leu o primeiro artigo sobre LIDS que postei aqui não deve perder esta segunda parte, onde são tratados os novos recursos de sua versão 1.2 e apresentadas as evoluções desse formidável sistema.
Vamos ver um pouco de como o novo módulo do TPE age em nível de
kernel no sistema Linux.
No kernel para verificar se um aplicativo é ou não protegido,
existe uma função básica que já havia sido implementada no LIDS.
O TPE é implementado basicamente nessas 3 funções a seguir:
lids_exec_tpe_permission (brpm):
Esta função checa se o binário é protegido ou não.
lids_mmap_tpe_permission (file, protection):
Esta função checa se as libraries são protegidas ou não.
lids_module_tpe_permission (module):
Esta função checa se o módulo é protegido ou não antes de carregá-lo no sistema.
Lugares onde estas funções estão colocadas podem ser considerados derivados dos
LSM Hooks(8)*.
Para o lids_exec_tpe_permission(brpm), pode-se adicionar um hook para chamar
a função fs/exec.c:do_exec(). Um algoritmo básico que poderia fazer isso pra
gente seria:
lids_exec_tpe_permission(bprm)
{
int error = 0
if (!lids_check_base(bprm->file->dentry, LIDS_APPEND))
error = -EACCES;
return error;
}
Estamos mostrando apenas como exemplo, não vamos nos aprofundar em kernel
space com o novo LIDS, isso fica para outro artigo.
Este código realmente não existe, é um pseudo-código. No caso ele apenas verifica
dentro do arquivo se o binário a ser executado está protegido ou não.
Como sabemos, a maioria das libraries do Linux é carregada usando a função
mmap(), podemos colocar um hook para verificar se a library está protegida
ou não para ser carregada em mm/mmap.c:do_mmap_pgoff().
O exemplo que segue mostra um simples exemplo de como aplicar a função
lids_mmap_tpe_permission():
lids_mmap_tpe_permission(file, protection)
{
int error = 0;
if (!file)
return 0;
if (!(protection & PROT_EXEC))
return 0;
if (!lids_check_base(file->dentry, LIDS_APPEND))
error = -EPERM;
return error;
}
Esse exemplo apenas checa se o arquivo com PROT_EXEC tem seu atributo
de memória protegido. Se o arquivo não está protegido ele retorna uma
mensagem de erro com -EPERM como error code.
Vamos ver agora também um exemplo de como proteger módulos usando a
função lids_module_tpe_permission(module).
Podemos utilizar para verificar módulos em nosso sistema usando seus
famosos symbols information. Para isso setamos a nossa função em
kernel/module.c:sys_init_module(). Vamos ver um exemplo de algoritmo
que verifica integridade de proteção dos nossos módulos:
lids_module_tpe_permission(module)
{
int error = 0;
modpath = get_module_path(module);
if (!lids_check_base(modpath->dentry, LIDS_APPEND))
error = -EPERM;
return error;
}
Depois de pegar o path do módulo corretamente, a função
lids_module_tpe_permission() verifica se o próprio tem seu
path protegido, caso contrário ele emitirá um erro para nós usando -EPERM como
código de erro.
Espero que tenha sido o suficiente para que possamos pelo menos
entender um pouco do que se passa por traz destas funções.
[6] Comentário enviado por mpsnet em 01/06/2004 - 09:38h
Li recentemente seu primeiro artigo sobre o LIDS, e vi uma observação interessante. Pelo que percebi não é muito viável instalar o LIDS em desktop's. A pergunta é !
Não é viavel somente devido as configuraçoes ?
Se for configurado adquadamente ele roda (leve e normalmente) ?
[7] Comentário enviado por y2h4ck em 01/06/2004 - 11:23h
Bom como disse o problema na viabilidade dele e o seguinte ... pense comigo em um cenario:
Voce tem um servidor de emails, so voce tem acesso a ele, oq vc faz
instala o LIDS, configura ele robustamente, e modifica as capacidades do sistema para que somenete determinados binarios possam ter capacidade de SETUID e SETGID... trava o kernel dele e pronto vc estara seguro e podera ter certeza que mesmo um atacante ganhando acesso shell ao seu sistema, ele nao conseguiria elevar os priviegios dele ( a menos que o sistema explorado seja oq tem permissao para essa capacidade ).
Agora esse tipo de proteção vc nao conseguiria na sua estação pq imagine os transtornos que vc teria com os seus programas.
Agora eu uso o lids no meu destop sim ele roda leve e normalmente,
oq vc pode fazer e proteger seus binarios, logs e tudo mais :)
assim alguma miguinho seu que tem acesso na maquina nao vai zuar suas coisas e adicionar usuarios novos ..
Mas vale a pena sentar e deixar ele rodando legal mesmo em seu Desktop.
[11] Comentário enviado por peregrino em 20/12/2004 - 17:49h
Tive alguns problemas para instalar o LidsTools no slackware 10.0, sempre quando tentava compilar o lidstool dava uma mensagem de erro.
cd . && /bin/sh /sistema/source/lids-1.2.2-2.4.28/lidstools-0.5.6/missing --run aclocal-1.6
/sistema/source/lids-1.2.2-2.4.28/lidstools-0.5.6/missing: line 46: aclocal-1.6: command not found
WARNING: `aclocal-1.6' is needed, and you do not seem to have it handy on your
system. You might have modified some files without having the
proper tools for further handling them. Check the `README' file,
it often tells you about the needed prerequirements for installing
this package. You may also peek at any GNU archive site, in case
some other package would contain this missing `aclocal-1.6' program.
make: *** [aclocal.m4] Error 1
Resolvemos esse problema com a seguinte solução, na pasta do lidstools digete os seguintes comandos.
ln -s /usr/bin/autoconf /usr/bin/autoconf-1.6
ln -s /usr/bin/automake /usr/bin/automake-1.6
./configure --prefix=/usr --sysconfdir=/etc/lids
./missing --run aclocal
make
make install
Achamos que seria interessante colocar essa dica no tutorial, falow