Depurar um binário setuid como não raiz

Question

Eu tenho um sistema do CentOS 7. Eu preciso anexar meu GDB a um aplicativo já em execução, mas obter o (aparentemente usual) "ptrace: Operação não permitida". erro. Executar o GDB como root evita o erro, mas prefiro não recorrer a isso.

Eu pesquisei o problema e encontrei várias respostas dizendo que você simplesmente precisava modificar /proc/sys/kernel/yama/ptrace_scope com o valor 0 ou ir para uma correção permanente em relação ao arquivo /etc/sysctl.d/10-ptrace.conf ...

Bem, aparentemente todo mundo acha que você está usando o YAMA, o que parece não ser o caso aqui. No entanto, ainda não consegui encontrar o que fazer na minha situação.

Eu verifiquei e parece que meu sistema está configurado com o SELinux, mas não está ativado. As configurações de inicialização do meu Kernel incluem o sinalizador selinux=0 e o comando

grep CONFIG_SECURITY /boot/config-'uname -r'

lê

# CONFIG_SECURITY_DMESG_RESTRICT is not set
CONFIG_SECURITY=y
CONFIG_SECURITYFS=y
CONFIG_SECURITY_NETWORK=y
CONFIG_SECURITY_NETWORK_XFRM=y
# CONFIG_SECURITY_PATH is not set
CONFIG_SECURITY_SECURELEVEL=y
CONFIG_SECURITY_SELINUX=y
CONFIG_SECURITY_SELINUX_BOOTPARAM=y
CONFIG_SECURITY_SELINUX_BOOTPARAM_VALUE=1
CONFIG_SECURITY_SELINUX_DISABLE=y
CONFIG_SECURITY_SELINUX_DEVELOP=y
CONFIG_SECURITY_SELINUX_AVC_STATS=y
CONFIG_SECURITY_SELINUX_CHECKREQPROT_VALUE=1
# CONFIG_SECURITY_SELINUX_POLICYDB_VERSION_MAX is not set
# CONFIG_SECURITY_SMACK is not set
# CONFIG_SECURITY_TOMOYO is not set
# CONFIG_SECURITY_APPARMOR is not set
# CONFIG_SECURITY_YAMA is not set

Por fim, getsebool deny_ptrace retorna getsebool: SELinux is disabled .

Pelo que entendi, nenhum LSM está atualmente habilitado no meu sistema, ainda assim eu recebo as limitações do ptrace. Eu estou aqui sem noção sobre onde procurar a seguir, ou o que até mesmo causa a limitação de ptrace neste momento.

O fato de o bit setuid estar definido no arquivo executável pode causar esse problema? O gdb e o aplicativo são lançados usando o mesmo usuário, sem privilégios de superusuário especificamente adicionados a ambos. ps -eouid,comm também mostra ambos como tendo o mesmo uid. Apenas o aplicativo é executado usando o bit setuid e o arquivo pertence a root: root.

    

Answer 1

A depuração de um programa que tenha privilégios efetivamente fornece ao depurador os mesmos privilégios. Portanto, independentemente de quaisquer configurações de segurança, a depuração de um programa que tenha privilégios extras deve exigir que o depurador tenha pelo menos todos esses privilégios. Por exemplo, um programa setuid tem os privilégios do usuário original e do usuário de destino, portanto, o depurador precisa ter os privilégios de ambos os usuários. Na prática, isso significa que o depurador deve ser raiz. No Linux, é suficiente dar ao depurador o recurso CAP_SYS_PTRACE (isso não reduz os privilégios efetivos do depurador, mas significa que o depurador não irá, por exemplo, sobrescrever acidentalmente arquivos de outro usuário).

Geralmente, é mais conveniente depurar o programa durante a execução sem privilégios extras. Ajustar permissões de arquivos, caminhos e assim por diante de acordo. Se você precisar depurar o programa em condições reais com os privilégios, o depurador precisará ser executado como root. No Linux, isso pode ser root em um namespace de usuário que contém os dois usuários envolvidos.