Chmod 4750 no sistema de arquivos montado com chroot (mas chmod 750 funciona)

Question

Eu estava seguindo o guia de instalação do gentoo . Mas eu fiquei na parte atualizando o mundo definido porque eu não era capaz de instalar o dbus com o emerge. Estava falhando em alterar a permissão SUID de seu binário com uma saída de log a seguir:

chmod 4750 /var/tmp/portage/sys-apps/dbus-1.10.18/image//usr/libexec/dbus-daemon-launch-helper;
...
chmod: changing permissions of '/var/tmp/portage/sys-apps/dbus-1.10.18/image//usr/libexec/dbus-daemon-launch-helper': Permission denied

Então, por exemplo:

Eu montei o sistema de arquivos como o usuário root:

mount /dev/sdb3 /mnt/gentoo

Depois disso eu chroot para ele (como o usuário root também):

chroot /mnt/gentoo /bin/bash
source /etc/profile

E criar um arquivo e tentar alterar suas permissões

touch /hello
chmood 4750 /hello

falha ao dizer "permissão negada".

No entanto, chmod 4750 /mnt/gentoo/hello do sistema de arquivos externo funciona bem.

Por que permissão é negada? Eu também tentei montar com -o suid , mas parece que não funciona.

Então, como fazer chmod 4750 funcionar em diferentes fs?

UPDATE: Quando eu faço a mesma coisa do meu linux mint ele funciona. Do gentoo livecd ele falha.

    

Answer 1

O live do Gentoo que você usou pode estar inicializando um kernel endurecido. Se assim for, você correu para as restrições impostas por um kernel endurecido que dificultou o acesso e a modificação de itens dentro de chroot ambientes. Setuid, GRUB e EFI vêm à mente. O primeiro número 4 na notação de quatro dígitos chmod 4750 refere-se à configuração do bit setuid. A mensagem de erro informa a tentativa sendo negada, pois tem implicações de segurança. Na notação de três dígitos, chmod 750 , a definição dessas permissões funciona, porque nenhum setuid está envolvido.

Esta resposta deve-se a Toralf, Hu e Gucal sobre a discussão relacionada nos fóruns do gentoo .

Então, o que você pode achar útil seguindo estas etapas:

1. Verifique se o kernel em execução atual é "hardenend", geralmente uname -r retorna uma string de 4.8.17-hardened-r2 ou algo assim.

   # uname -r
   4.8.17-hardened-r2
   

2. Verifique se a configuração do seu kernel permite as configurações locais do sysctl, do # zgrep GRKERNSEC_SYSCTL /proc/config.gz - um resultado como este é bom:

   CONFIG_GRKERNSEC_SYSCTL=y
   CONFIG_GRKERNSEC_SYSCTL_ON=y
   

3. Certifique-se de fazer isso e a próxima etapa fora do ambiente chrooted real. Adicione algumas linhas a /etc/sysctl.conf - dado que você provavelmente está dentro de um ambiente chroot temporário, de qualquer forma, isso parece ok, se não adicioná-las a /etc/sysctl.d/local.conf :

   kernel.grsecurity.chroot_deny_chmod = 0 
   kernel.grsecurity.chroot_caps = 0 
   kernel.grsecurity.chroot_deny_mount = 0 
   

4. Última etapa, você executa # sysctl -p para trabalhar nessas alterações. ele repetirá qualquer regra definida na configuração da etapa 3:

   # sysctl -p
   net.ipv4.ip_forward = 0
   kernel.grsecurity.chroot_deny_chmod = 0
   kernel.grsecurity.chroot_caps = 0
   kernel.grsecurity.chroot_deny_mount = 0
   

Em seguida, entre no ambiente chroot novamente (via screen -x se você for como eu) e descubra que emerge precisando alterar as permissões usando SUID funciona como deveria.

(Em uma nota lateral, o Gentoo parou de enviá-los por motivos de disponibilidade restrita de patches. Consulte o artigo sobre o LWN.net Assim, aqueles ambientes vivos equipados com GUI devem ser usados com cuidado e nunca foram um tamanho único.

    

Answer 2

Parece que o mount está adotando o status não gravável do ambiente host (o livecd). Especifique explicitamente um mount de leitura / gravação com o seguinte:

mount -o rw /dev/sdb3 /mnt/gentoo

Certifique-se de umount primeiro.