Sobrecarga do FAPolicyD retardando um servidor

Question

Permitir listar programas executados está entre os recursos de segurança mais eficazes. Sem ele, uma conta de usuário comprometida poderia executar qualquer carga arbitrária. Ou os usuários instalam programas em seu diretório inicial que não deveriam. Embora seja um recurso opcional que você decide ativar ou não.

A inspeção de todas essas chamadas do sistema de arquivos prejudica o desempenho. Embora a sobrecarga possa ser minimizada otimizando as regras e o banco de dados.

Meça se o desempenho é aceitável do ponto de vista do usuário. Um objetivo focado no tempo de resposta, algo como "99,9% das chamadas de API do aplicativo serão concluídas em menos de 1 segundo", detectará problemas reais, não apenas tendências na utilização de recursos.

Primeiro, para obter algumas informações básicas sobre o fapolicyd, observe a introdução do desempenho deo LEIA-ME:

DESEMPENHO

Quando um programa abre um arquivo ou chama execve, esse thread precisa esperar que o fapolicyd tome uma decisão. Para tomar uma decisão, o fapolicyd precisa pesquisar informações sobre o processo e o arquivo que está sendo acessado. Cada chamada de sistema que o fapolicyd precisa fazer torna o sistema mais lento.

Para acelerar as coisas, o fapolicyd armazena em cache tudo o que procura, para que o acesso subsequente use o cache em vez de pesquisar tudo do zero. Mas o cache é tão grande. Você está no controle disso, no entanto. Você pode aumentar os caches de assunto e objeto. Quando o programa terminar, ele exibirá algumas estatísticas de desempenho como esta em /var/log/fapolicyd-access.log ou na tela:
Permissive: false
q_size: 640
Inter-thread max queue depth 7
Allowed accesses: 70397
Denied accesses: 4
Trust database max pages: 14848
Trust database pages in use: 10792 (72%)

Subject cache size: 1549
Subject slots in use: 369 (23%)
Subject hits: 70032
Subject misses: 455
Subject evictions: 86 (0%)

Object cache size: 8191
Object slots in use: 6936 (84%)
Object hits: 63465
Object misses: 17964
Object evictions: 11028 (17%)
Neste relatório, você pode ver que a fila de solicitações internas atingiu o máximo de 7. Isso significa que o daemon tinha no máximo 7 threads/processos em espera. Isso mostra que ele ficou um pouco atrasado, mas estava lidando com as solicitações muito rapidamente. Se esse número for grande, como mais de 200, pode ser necessário aumentar o q_size. Observe que se você ultrapassar 1.015, talvez seja necessário informar ao systemd para permitir mais de 1.024 descritores. No arquivo fapolicyd.service, você precisará adicionar LimitNOFILE=16384 ou algum número maior que sua fila.

Outra estatística que vale a pena observar é a relação entre acertos e despejos. Quando uma solicitação não tem onde colocar informações, ela tem que despejar alguma coisa para abrir espaço. Isso é feito por um cache LRU que determina naturalmente o que não está sendo usado e disponibiliza sua memória para reutilização.

Nas estatísticas acima, a taxa de acerto dos assuntos foi de 95%. O cache de objetos não teve tanta sorte. Para isso, obtemos uma taxa de acerto de 79%. Isso ainda é bom, mas poderia ser melhor. Isso sugeriria que, para a carga de trabalho desse sistema, o cache poderia ser um pouco maior. Se o número usado para o tamanho do cache for um número primo, você terá menos rotatividade de cache devido a colisões do que se tivesse um denominador comum. Alguns números primos que você pode considerar para o tamanho do cache são: 1021, 1549, 2039, 4099, 6143, 8191, 10243, 12281, 16381, 20483, 24571, 28669, 32687, 40961, 49157, 57347, , etc.

Além disso, deve ser mencionado que quanto mais regras na política, mais regras ela terá que iterar para tomar uma decisão. Quanto ao impacto no desempenho do sistema, isso depende muito da carga de trabalho. Para um cenário típico de desktop, você não notará que ele está em execução. Um sistema que abre muitos arquivos aleatórios por curtos períodos de tempo terá mais impacto.

Outra opção de configuração que pode afetar o desempenho é a configuração de integridade. Se estiver definido como sha256, cada falha no cache do objeto fará com que um hash seja calculado no arquivo que está sendo acessado. Uma compensação seria usar a verificação de tamanho em vez do sha256. Isto não é tão seguro, mas é uma opção se o desempenho for problemático.

do_stat_report = 1na configuração para ativar o relatório de estatísticas e reinicie o fapolicyd se não o tiver feito recentemente. Analise /var/log/fapolicyd-access.log e observe os padrões de quais PIDs estão abrindo quais arquivos.

Observe a proporção de “acertos” para “erros”. Uma taxa de acertos mais alta é melhor, pois o acesso ao banco de dados na memória é muito mais rápido do que o acesso e o processamento do sistema de arquivos. Aumente obj_cache_sizea configuração para o número de arquivos que seu sistema possui de uma só vez. Um possível limite superior é o número de inodes usados no sistema de arquivos de dados, a partir da df -isaída. O que pode ser excessivo, mas se você tiver memória, por que não armazenar em cache algumas centenas de milhares de entradas.

Revise a configuração em fapolicyd.conf. integrityvalores diferentes de noneou sizecalcularão a soma de verificação e terão sobrecarga. Especialmente se você tiver muitas falhas no processamento de novos arquivos, isso pode consumir uma quantidade significativa de CPU. q_sizedeve ser maior que a "profundidade máxima da fila" no relatório de acesso, mas duvido que o tamanho da fila precise ser aumentado.

Revise as regras, em compilado.rules de regras.d. RHEL e Fedora preenchem arquivos confiáveis do rpm, não permitem a execução de arquivos desconhecidos, não permitem o truque ld.so e permitem a maioria das aberturas. Se você modificar as regras, pense no impacto no desempenho de fazer mais coisas enquanto o syscall aberto está aguardando.

E, como sempre, você pode traçar um perfil do que exatamente está acontecendo durante a solução de problemas. perf topimprimirá quais funções estão na CPU e é ainda melhor quando o debuginfo está instalado. O pacote bcc-tools possui alguns scripts interessantes: opensnoop e execsnoop para listar chamadas abertas e exeve em tempo real.

Em última análise, cabe a você decidir quais controles implementar para permitir apenas a execução de programas não autorizados. A lista de permissões imediatamente na chamada exec, como fapolicyd, é obviamente muito poderosa. Uma alternativa menos abrangente poderia ser restringir o acesso ao shell: não permitir shells interativos às pessoas e bloquear permissões de diretórios pessoais. Ou, se um sistema de arquivos de dados não tiver nenhum programa, considere montá-lo noexec. Uma boa auditoria de segurança não trataria a lista de verificação como imutável, mas listaria os controles alternativos em vigor e por quê.

Answer 1

Permitir listar programas executados está entre os recursos de segurança mais eficazes. Sem ele, uma conta de usuário comprometida poderia executar qualquer carga arbitrária. Ou os usuários instalam programas em seu diretório inicial que não deveriam. Embora seja um recurso opcional que você decide ativar ou não.

A inspeção de todas essas chamadas do sistema de arquivos prejudica o desempenho. Embora a sobrecarga possa ser minimizada otimizando as regras e o banco de dados.

Meça se o desempenho é aceitável do ponto de vista do usuário. Um objetivo focado no tempo de resposta, algo como "99,9% das chamadas de API do aplicativo serão concluídas em menos de 1 segundo", detectará problemas reais, não apenas tendências na utilização de recursos.

Primeiro, para obter algumas informações básicas sobre o fapolicyd, observe a introdução do desempenho deo LEIA-ME:

DESEMPENHO

Quando um programa abre um arquivo ou chama execve, esse thread precisa esperar que o fapolicyd tome uma decisão. Para tomar uma decisão, o fapolicyd precisa pesquisar informações sobre o processo e o arquivo que está sendo acessado. Cada chamada de sistema que o fapolicyd precisa fazer torna o sistema mais lento.

Para acelerar as coisas, o fapolicyd armazena em cache tudo o que procura, para que o acesso subsequente use o cache em vez de pesquisar tudo do zero. Mas o cache é tão grande. Você está no controle disso, no entanto. Você pode aumentar os caches de assunto e objeto. Quando o programa terminar, ele exibirá algumas estatísticas de desempenho como esta em /var/log/fapolicyd-access.log ou na tela:
Permissive: false
q_size: 640
Inter-thread max queue depth 7
Allowed accesses: 70397
Denied accesses: 4
Trust database max pages: 14848
Trust database pages in use: 10792 (72%)

Subject cache size: 1549
Subject slots in use: 369 (23%)
Subject hits: 70032
Subject misses: 455
Subject evictions: 86 (0%)

Object cache size: 8191
Object slots in use: 6936 (84%)
Object hits: 63465
Object misses: 17964
Object evictions: 11028 (17%)
Neste relatório, você pode ver que a fila de solicitações internas atingiu o máximo de 7. Isso significa que o daemon tinha no máximo 7 threads/processos em espera. Isso mostra que ele ficou um pouco atrasado, mas estava lidando com as solicitações muito rapidamente. Se esse número for grande, como mais de 200, pode ser necessário aumentar o q_size. Observe que se você ultrapassar 1.015, talvez seja necessário informar ao systemd para permitir mais de 1.024 descritores. No arquivo fapolicyd.service, você precisará adicionar LimitNOFILE=16384 ou algum número maior que sua fila.

Outra estatística que vale a pena observar é a relação entre acertos e despejos. Quando uma solicitação não tem onde colocar informações, ela tem que despejar alguma coisa para abrir espaço. Isso é feito por um cache LRU que determina naturalmente o que não está sendo usado e disponibiliza sua memória para reutilização.

Nas estatísticas acima, a taxa de acerto dos assuntos foi de 95%. O cache de objetos não teve tanta sorte. Para isso, obtemos uma taxa de acerto de 79%. Isso ainda é bom, mas poderia ser melhor. Isso sugeriria que, para a carga de trabalho desse sistema, o cache poderia ser um pouco maior. Se o número usado para o tamanho do cache for um número primo, você terá menos rotatividade de cache devido a colisões do que se tivesse um denominador comum. Alguns números primos que você pode considerar para o tamanho do cache são: 1021, 1549, 2039, 4099, 6143, 8191, 10243, 12281, 16381, 20483, 24571, 28669, 32687, 40961, 49157, 57347, , etc.

Além disso, deve ser mencionado que quanto mais regras na política, mais regras ela terá que iterar para tomar uma decisão. Quanto ao impacto no desempenho do sistema, isso depende muito da carga de trabalho. Para um cenário típico de desktop, você não notará que ele está em execução. Um sistema que abre muitos arquivos aleatórios por curtos períodos de tempo terá mais impacto.

Outra opção de configuração que pode afetar o desempenho é a configuração de integridade. Se estiver definido como sha256, cada falha no cache do objeto fará com que um hash seja calculado no arquivo que está sendo acessado. Uma compensação seria usar a verificação de tamanho em vez do sha256. Isto não é tão seguro, mas é uma opção se o desempenho for problemático.

do_stat_report = 1na configuração para ativar o relatório de estatísticas e reinicie o fapolicyd se não o tiver feito recentemente. Analise /var/log/fapolicyd-access.log e observe os padrões de quais PIDs estão abrindo quais arquivos.

Observe a proporção de “acertos” para “erros”. Uma taxa de acertos mais alta é melhor, pois o acesso ao banco de dados na memória é muito mais rápido do que o acesso e o processamento do sistema de arquivos. Aumente obj_cache_sizea configuração para o número de arquivos que seu sistema possui de uma só vez. Um possível limite superior é o número de inodes usados no sistema de arquivos de dados, a partir da df -isaída. O que pode ser excessivo, mas se você tiver memória, por que não armazenar em cache algumas centenas de milhares de entradas.

Revise a configuração em fapolicyd.conf. integrityvalores diferentes de noneou sizecalcularão a soma de verificação e terão sobrecarga. Especialmente se você tiver muitas falhas no processamento de novos arquivos, isso pode consumir uma quantidade significativa de CPU. q_sizedeve ser maior que a "profundidade máxima da fila" no relatório de acesso, mas duvido que o tamanho da fila precise ser aumentado.

Revise as regras, em compilado.rules de regras.d. RHEL e Fedora preenchem arquivos confiáveis do rpm, não permitem a execução de arquivos desconhecidos, não permitem o truque ld.so e permitem a maioria das aberturas. Se você modificar as regras, pense no impacto no desempenho de fazer mais coisas enquanto o syscall aberto está aguardando.

E, como sempre, você pode traçar um perfil do que exatamente está acontecendo durante a solução de problemas. perf topimprimirá quais funções estão na CPU e é ainda melhor quando o debuginfo está instalado. O pacote bcc-tools possui alguns scripts interessantes: opensnoop e execsnoop para listar chamadas abertas e exeve em tempo real.

Em última análise, cabe a você decidir quais controles implementar para permitir apenas a execução de programas não autorizados. A lista de permissões imediatamente na chamada exec, como fapolicyd, é obviamente muito poderosa. Uma alternativa menos abrangente poderia ser restringir o acesso ao shell: não permitir shells interativos às pessoas e bloquear permissões de diretórios pessoais. Ou, se um sistema de arquivos de dados não tiver nenhum programa, considere montá-lo noexec. Uma boa auditoria de segurança não trataria a lista de verificação como imutável, mas listaria os controles alternativos em vigor e por quê.

Sobrecarga do FAPolicyD retardando um servidor

Responder1

DESEMPENHO

informação relacionada