O link simbólico se torna ilegível após prctl (PR_SET_DUMPABLE, 0);

Question

Eu estava depurando kcheckpass em Archlinux . (Porque não consegui fazer o login com kcheckpass )

De alguma forma, acredito que esse problema específico não esteja em kcheckpass .

int
main(int argc, char **argv)
{
#ifdef HAVE_PAM
  const char    *caller = KSCREENSAVER_PAM_SERVICE;
#endif
  const char    *method = "classic";
  const char    *username = 0;
#ifdef ACCEPT_ENV
  char      *p;
#endif
  struct passwd *pw;
  int       c, nfd, lfd;
  uid_t     uid;
  time_t    nexttime;
  AuthReturn    ret;
  struct flock lk;
  char fname[64], fcont[64];

  // disable ptrace on kcheckpass
#if HAVE_PR_SET_DUMPABLE
  prctl(PR_SET_DUMPABLE, 0);

Antes da execução da primeira linha: prctl(PR_SET_DUMPABLE, 0);

ls /proc/$(pidof kcheckpass)/exe  -al
lrwxrwxrwx 1 wuyihao wuyihao 0 Jan 16 16:16 /proc/31661/exe -> /cker/src/build/kcheckpass/kcheckpass

E depois de executá-lo:

ls /proc/$(pidof kcheckpass)/exe  -al
ls: cannot read symbolic link '/proc/31661/exe': Permission denied

O mesmo com /proc/31661/root e /proc/31661/cwd

Não vejo nenhuma conexão entre coredump e permissão de leitura de /proc/$PID/exe

UPDATE

Exemplo mínimo reproduziu este problema:

#include <sys/prctl.h>
#include <stdio.h>
int main(){
    prctl(PR_SET_DUMPABLE, 0);
    return 0;
}

UPDATE2 kcheckpass e o exemplo mínimo test são ambos:

-rwsr-xr-x 1 root root

    

Answer 1

Quando você remove o atributo dumpable, um monte de /proc/<pid>/ arquivos e links se torna ilegível por outros processos, até mesmo de propriedade do usuário.

A prctl manpage diz:

Processes that are not dumpable can not be attached via ptrace(2) PTRACE_ATTACH; see ptrace(2) for further details.

If a process is not dumpable, the ownership of files in the process's /proc/[pid] directory is affected as described in proc(5).

E a proc manpage diz:

/proc/[pid]

Each /proc/[pid] subdirectory contains the pseudo-files and directories described below. These files are normally owned by the effective user and effective group ID of the process. However, as a security measure, the ownership is made root:root if the process's "dumpable" attribute is set to a value other than 1.

E, finalmente, a ptrace manpage diz:

Ptrace access mode checking

Various parts of the kernel-user-space API (not just ptrace() operations), require so-called "ptrace access mode" checks, whose outcome determines whether an operation is permitted (or, in a few cases, causes a "read" operation to return sanitized data).

(...)

The algorithm employed for ptrace access mode checking determines whether the calling process is allowed to perform the corresponding action on the target process. (In the case of opening /proc/[pid] files, the "calling process" is the one opening the file, and the process with the corresponding PID is the "target process".) The algorithm is as follows:

(...)

4. Deny access if the target process "dumpable" attribute has a value other than 1 (...), and the caller does not have the CAP_SYS_PTRACE capability in the user namespace of the target process.