chmodding arquivos com um contexto de segurança do SELinux / ACL

Question

Ok, tenho um monte de bash & python scripts que eu escrevi, todos apenas relaxando juntos em um grande diretório. Bem, na verdade existem subdiretórios separados, mas eles estão todos aninhados neste diretório principal. Então, para argumentar, a estrutura do diretório é algo como isto:

find . -type d

.
./scripts/sh
./scripts/sh/a
./scripts/sh/b
./scripts/sh/c
./scripts/py
./scripts/py/x
./scripts/py/y
./scripts/py/z

De qualquer forma, tentei tornar toda a coleção de scripts executáveis, tudo de uma só vez com find e chmod :

find . -type f -exec chmod +x {} +

Normalmente, é tudo o que tenho que fazer, mas notei que o +x ainda estava indefinido. Todas as permissões ainda são assim:

ls -l ./scripts/py/z

-rw-rw----.  1 root 1015  801 May  7 12:00 script_name.py

Supostamente. O caractere . (seguindo os sinalizadores de permissão) implica em algum tipo de contexto de segurança do SELinux, com uma lista de controle de acesso ou similar. Eu verifiquei com getfacl , realmente não sabendo o que lool para; primeiro é um diretório, o segundo é um dos arquivos de script:

getfacl -acp ./scripts/py/z &&
getfacl -acp ./scripts/py/z/*

user::rwx
group::rwx
other::--x

user::rw-
group::rw-
other::---

Eu experimentei as seguintes opções setfacl , sem sucesso:

setfacl --help | grep 'remove'

  -x, --remove=acl        remove entries from the ACL(s) of file(s)
  -X, --remove-file=file  read ACL entries to remove from file
  -b, --remove-all        remove all extended ACL entries
  -k, --remove-default    remove the default ACL

Então, em uma situação em que a autoridade de usuários root não é respeitada, e sudo não é útil, eu tenho que perguntar; Como devo recuperar o controle de acesso de meus próprios arquivos?

Migrado de security.stackexchange.com

    

Answer 1

Os contextos de ACLs e SELinux são totalmente diferentes. Há um bom tutorial aqui para o CentOS

Para ver se o SELinux é realmente o que está bloqueando seu acesso, use sestatus

$ sestatus
SELinux status:                 enabled
SELinuxfs mount:                /sys/fs/selinux
SELinux root directory:         /etc/selinux
Loaded policy name:             targeted
Current mode:                   enforcing
Mode from config file:          enforcing
Policy MLS status:              enabled
Policy deny_unknown status:     allowed
Max kernel policy version:      28

Enforcing no meu resultado diz que o SELinux está bloqueando ativamente os acessos fora de contexto.

Defina temporariamente o SELinux como permissivo usando # sudo setenforce Permissive

$ sudo setenforce Permissive
[sudo] password for trogdor: 
$ sestatus
SELinux status:                 enabled
SELinuxfs mount:                /sys/fs/selinux
SELinux root directory:         /etc/selinux
Loaded policy name:             targeted
Current mode:                   permissive
Mode from config file:          enforcing
Policy MLS status:              enabled
Policy deny_unknown status:     allowed
Max kernel policy version:      28

O modo permissivo ainda alertará sobre violações de contexto do SELinux, mas não as bloqueará. Esta é uma boa maneira de verificar se o SELinux é realmente o problema. Se foi, e agora tudo funciona, defina o SELinux como Enforcing com sudo setenforce Enforcing . (como um aparte muda para o SELinux com setenforce não sobreviverá a reinicialização).

Se o SELinux é o problema, você deve encontrar o contexto correto que os scripts devem ter, ou talvez seja uma correção simples com um booleano.

Se você está no seu diretório home, pode ser tão simples quanto configurar um booleano do SELinux. Para ver booleanos, há uma descrição do aqui do aqui , mas percebo que o exemplo user_exec_content abaixo não está listado lá, é mais conveniente ferramenta para descrições booleanas é semanage boolean -l

# getsebool -a | grep exec
...
user_exec_content --> off
...

#sudo semanage boolean -l
...
user_exec_content              (off  ,   off)  Allow user to exec content
...

O primeiro fora mostra seu estado atual, que está atualmente desativado; o próximo mostra o padrão, o que significa que ele ainda estará desativado após a reinicialização ou a nova marcação do sistema de arquivos.

Nesse caso, use #setsebool -P user_exec_content on O sinalizador -P torna permanente a mudança booleana nas reinicializações

Se é um problema de contexto, bons contextos são muito mais agradáveis de se trabalhar porque são mais intuitivos. Parece ser uma tentativa, erro e experiência sobre o que realmente faz com os boleanos do SELinux, por exemplo, nenhuma ideia do que user_exec_content realmente faz.

Use o sinalizador -Z com ls para visualizar o contexto de seus arquivos, por exemplo. ls -alZ.

$ ls -alZ
-rwxrwxr-x. trogdor trogdor unconfined_u:object_r:user_home_t:s0 backup.sh

Aqui user_home_t é o contexto do backup.sh. Digamos que você tenha outro diretório que tenha os contextos corretos para executar scripts, você pode espelhar esse contexto no diretório ./scripts usando:

# chcon -R --reference /onethatworks ./scripts

Para verificar novamente a alteração, use ls -alZ ./scripts

restorecon -Rv ./scripts 

deve reclassificar o sistema de arquivos, re-rotulando todos os arquivos e diretórios recursivamente para os contextos atualizados. Neste caso, é apenas o diretório de scripts e seu conteúdo.

Se isso funcionar, as alterações feitas aqui não sobreviverão à reinicialização e você poderá usar o seguinte para tornar a alteração permanente.

# semanage fcontext -a -s system_u -t <context_that_worked> "./scripts(/.*)?

Outra opção para gerenciar o SELinux é instalar o policycoreutils-gui para que você tenha acesso a uma configuração do selinux digitando # system-config-selinux . Ao filtrar usando 'script', descobri que muitos scripts usam bin_t como seu contexto. Você também pode alterar o modo de execução com ele. Meus scripts no meu diretório home são executados com sucesso com user_home_t , mas eu suspeito que você esteja em outro lugar se você está tendo esses problemas.