SELinux - forma canônica de aplicar automaticamente um contexto na criação de arquivos

Question

Meu entendimento atual é que você tem que usar manualmente restorecon para aplicar o contexto desejado a um arquivo ou diretório recém-criado, a menos que esteja satisfeito com o contexto que ele herda de seu diretório pai.

Eu estou querendo saber se é possível aplicar automaticamente um contexto na criação com base em seu caminho sem ter que executar restorecon .

Eu pesquisei um pouco no Google e descobri este post de Dan Walsh, onde ele menciona restorecond , que usa inotify para mude o contexto na criação. Ele também aponta o problema óbvio com isso (condição de corrida). Esta é a única maneira de resolver automaticamente o problema de reconfiguração no caso de um filho não herdar seu contexto do diretório pai?

Um problema é que restorecond parece não manipular entradas da mesma forma que /etc/selinux/targeted/contexts/files/file_contexts , ou seja, não há regexes e não funciona recursivamente, portanto /etc/selinux/restorecond.conf não pode conter algo como

/var/www(/.*)?/logs(/.*)?

ou

/var/www/*

ou até mesmo

/var/www/*/logs

Existe uma maneira de contornar esse problema?

EDITAR:

Como por @ resposta de Michael, isso deve funcionar OOTB se existir uma regra, mas não:

# rm -rf /var/www/foo
# semanage fcontext -a -t httpd_log_t '/var/www/foo/logs'
# grep '/var/www.*logs' /etc/selinux/targeted/contexts/files/file_contexts*
/etc/selinux/targeted/contexts/files/file_contexts:/var/www(/.*)?/logs(/.*)?    system_u:object_r:httpd_log_t:s0
/etc/selinux/targeted/contexts/files/file_contexts.local:/var/www/foo/logs    system_u:object_r:httpd_log_t:s0
# matchpathcon /var/www/foo/logs
/var/www/foo/logs       system_u:object_r:httpd_log_t:s0
# mkdir -p /var/www/foo/logs
# touch /var/www/foo/logs/quux
# ls -alZ /var/www/foo/logs*
drwxr-xr-x. root root unconfined_u:object_r:httpd_sys_content_t:s0 .
drwxr-xr-x. root root unconfined_u:object_r:httpd_sys_content_t:s0 ..
-rw-r--r--. root root unconfined_u:object_r:httpd_sys_content_t:s0 quux
# restorecon -vR /var/www/foo
restorecon reset /var/www/foo/logs context unconfined_u:object_r:httpd_sys_content_t:s0->unconfined_u:object_r:httpd_log_t:s0
restorecon reset /var/www/foo/logs/quux context unconfined_u:object_r:httpd_sys_content_t:s0->unconfined_u:object_r:httpd_log_t:s0

    

Answer 1

O kernel faz o seguinte procedimento para determinar qual será o tipo de arquivo de um arquivo recém-criado.

• Existe na política uma regra de transição de arquivos específica. Então aplique isso.
• Faça com que o arquivo recém-criado adquira o tipo do diretório pai.

Na grande maioria dos casos, novos arquivos herdam o tipo de diretórios pai. Às vezes isso não é desejável - portanto, um redator de política pode criar regras baseadas nas condições de quem está fazendo a rotulagem e para onde fazer a transição para outro tipo.

Isso é controlado na política com a instrução type_transition , embora normalmente um gravador de políticas chame a macro filetrans_pattern .

No kernel, essas decisões não são baseadas em caminhos, mas em tipos (embora exista uma pequena exceção em políticas mais recentes).

Uma regra normalmente é assim:

type_transition httpd_t var_log_t:file httpd_var_log_t;

Neste exemplo, a regra afirma isso. Se o processo / usuário que executa a criação do arquivo for httpd_t e o diretório no qual o objeto está sendo criado for var_log_t e o objeto for classificado como file , o novo arquivo deverá ser rotulado como httpd_var_log_t . / p>

Isso, obviamente, tem várias limitações, um bom exemplo disso é a condição quando você cria arquivos .htaccess no apache (em / var / www / html). Neste exemplo, a política padrão de criar um tipo de arquivo com o mesmo tipo de seu diretório pai aplica-se, mas, na realidade, o tipo adequado desse arquivo é httpd_sys_htacess_t , e não o padrão httpd_sys_content_t .

Este foi um problema conhecido por vários anos e acabou sendo resolvido permitindo que os redatores de políticas especifiquem o nome do arquivo ao qual a transição se aplica na política - infelizmente, esses recursos não estão disponíveis no EL6.

No seu caso específico - como você mencionou, há algumas soluções envolvendo o restauro. Além disso, você deve idealmente dividir seus dados em diferentes tipos, colocando-os em subdiretórios separados, nos quais o subdiretório é um tipo adequadamente rotulado. Se isso ainda não for possível, e o restorecond não for possível - a única solução é uma correção posterior da execução da restauração no arquivo após sua criação.

Mesmo o 'mais recente' chamado filetrans tem problemas porque no final ele não suporta globbing ou regex, o que limita severamente sua funcionalidade a arquivos especificamente bem-nomeados (como .htaccess).

No momento, não existe nenhum mecanismo no kernel tão flexível quanto restorecon e suas expressões regulares para rotular corretamente os arquivos corretamente nesse grau.

    

Answer 2

O problema de rotulagem correta na criação de arquivos foi tratado no Fedora 16 com um recurso chamado transição do nome do arquivo (embora você pode encontrá-lo também como "transições de arquivo nomeadas"), cuja definição basicamente declara que:

With File Name Transitions Features, policy writers can write rules that take into account the file name, not the file path. This is the basename of the file path. Since the kernel knows at the time of object creation the label of the containing directory, the label of the process creating the object and the objects Name. we can now write a policy rule that states, if an unconfined_t process creates a file named resolv.conf in a directory labelled etc_t, the file should get labelled resolv.conf.

Sabe-se que a maneira como um objeto é rotulado no momento da criação pode variar dependendo do processo de criação do objeto ( cp vs mv é um bom exemplo). Além disso, a maneira padrão de rotular um objeto seria por herança: o objeto obtém o rótulo do diretório pai.

Embora isso seja conveniente, nem sempre é correto, e o administrador do sistema deve corrigir a situação manualmente usando (uma combinação de) restorecon + restorecond + semanage fcontext -a -t .

Este é o problema que as transições de arquivos de nome tentam corrigir, permitindo que

[...] policy writers have the ability to overwrite this by writing a rule in policy that states, if a process with type a_t creates a object of class "file" in a directory labelled b_t, the object will get created c_t.

Obviamente, as transições de arquivo nomeadas não existem para locais personalizados. Você pode encontrar os já existentes com, por exemplo:

# sesearch -ASCT -s unconfined_t | grep Found
...
Found XX named file transition filename_trans:
...

Assim, para resolver o seu problema, você precisa saber de antemão qual usuário (usuário do SELinux) criará o arquivo / diretório e onde, e então escreverá uma política personalizada incluindo uma transição de arquivo. Há alguns exemplos na página wiki do Projeto Fedora que eu relacionei acima.

    

Answer 3

Isso não é um problema, você está apenas se aproximando da direção errada.

Se você quiser seus próprios contextos de arquivos, basta criar seus próprios usando semanage fcontext . Isso faz aceitar expressões regulares.

Aqui está um exemplo comum, usado para realocar o diretório do qual o Apache exibe os arquivos :

semanage fcontext -a -t httpd_sys_content_t "/volume1/web(/.*)?"

Sinta-se à vontade para adaptar isso às suas próprias necessidades.