Segurança extrema com LIDS: novos recursos
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.
Parte 5: Kernel space
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:
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:
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;
}
{
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;
}
{
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;
}
{
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.
Vamos agora ver algo sobre o TDE.
estou pensando em postar um bom sobre snort.