Существует ли механизм для управления процессом, подобным prctl (), но для разветвленных / exec * () d процессов?

Question

Можно ли сделать эквивалент prctl(PR_SET_DUMPABLE, 0), но для другого процесса, например, дочернего процесса, или процесса, который был exec 'd?Приведенная ниже программа демонстрирует, что флаг dumpable не наследуется процессом, который был execv 'd.

#include <stdio.h>
#include <stdlib.h>
#include <sys/prctl.h>
#include <sys/stat.h>
#include <sys/types.h>
#include <unistd.h>

int main(int argc, char **argv) {
    struct stat st;

    if (argc < 2) {
        fprintf(stderr, "usage: %s PROGRAM [ARGS...]\n", argv[0]);
        return EXIT_FAILURE;
    }

    if (stat("/proc/self/fd", &st)) {
        perror("stat");
        return EXIT_FAILURE;
    }
    printf("before: owner of /proc/self/fd: %d\n", st.st_uid);

    if (prctl(PR_SET_DUMPABLE, 0) == -1) {
        perror("prctl");
        return EXIT_FAILURE;
    }

    if (stat("/proc/self/fd", &st)) {
        perror("stat");
        return EXIT_FAILURE;
    }
    printf("after: owner of /proc/self/fd: %d\n", st.st_uid);

    if (execv(argv[1], argv + 1) == -1) {
        perror("execv");
        return EXIT_FAILURE;
    }
}

$ ./a.out /usr/bin/stat -c 'in execed process: %u' /proc/self/fd
before: owner of /proc/self/fd: 1000
after: owner of /proc/self/fd: 0
in execed process: 1000

Причина, по которой я хочу, заключается в том, что у меня есть программа, которая работает как обычнаяПользователь и читает конфиденциальные данные (пароли) из стандартного ввода, и я не хочу, чтобы другие могли читать эти данные процесса из /proc.Есть ли альтернативный способ сделать это?

Answer 1

Я не хочу, чтобы другие могли читать данные этого процесса из /proc.Есть ли какой-нибудь альтернативный способ сделать это?

Содержимое подкаталогов для каждого процесса в /proc обычно принадлежит эффективному uid и эффективному gid соответствующего процесса.Единственное задокументированное условие, в котором это отличается, - это когда атрибут dumpable процесса имеет значение, отличное от 1.

Причина, по которой я хочу это, заключается в том, что у меня есть программа, котораязапускается как обычный пользователь и считывает конфиденциальные данные (пароли) из стандартного ввода

Если рассматриваемая программа работает как обычный пользователь , вы можете выбрать ,тогда проще всего выбрать целевого пользователя с частной первичной группой.Для доступа /proc это должно быть примерно так же, как установка процесса без дампа или запуск его с правами root.Может быть, лучше, если процесс хочет иметь возможность читать из своей собственной записи /proc.Это тоже вполне естественно.Однако он не служит для первичной цели отключения флага dumpable, т. Е. Не позволяет процессу выгружать ядро.

Если сама программа находится подваш контроль , тогда вы можете просто изменить его, чтобы сделать соответствующий вызов prctl().Я полагаю, что это не ваш случай.

В противном случае программа не может быть изменена и должна запускаться произвольными пользователями .Согласно документации prctl() , существует четыре способа, кроме вызова prctl(), чтобы заставить флаг dumpable процесса быть отключенным:

• Изменен эффективный идентификатор пользователя или группы процесса.

• Изменен идентификатор пользователя или группы файловой системы процесса (см. Учетные данные (7)).

• Процесс выполняет (execve (2)) программу set-user-ID или set-group-ID, что приводит к изменению либо действительного идентификатора пользователя, либо эффективного идентификатора группы.

• Процесс выполняет (execve (2)) программу с файловыми возможностями (см. Возможности (7)), но только в том случае, если полученные разрешенные возможности превышают уже разрешенные для процесса.

Все они описывают ситуации, в которых управление доступом по-разному влияет на процесс, чем на обычные процессы, запускаемые одним и тем же пользователем, что напоминает мое первоначальное предложение организовать соответствующий контроль доступа простоуправление пользователем, от которого работает программа.В конце концов, кого волнует, запустит ли случайный пользователь программу и сможет ли она получить секреты, которые они сами ввели?Проблема возникает только в том случае, если другие люди могут быть обмануты в разглашении секретов программы.Но если вы рассматриваете эту альтернативу, то вы уже отклонили простой вариант.

Поскольку программа в конечном счете запускается непривилегированным пользователем, изменяя свои действующие учетные данные или учетные данные файловой системы, даже через программу-оболочку,сама по себе не является жизнеспособной альтернативой.Таким образом, вам остается сделать SUID или SGID программы или назначить ей возможности, на которые вы можете полагаться, отличные от обычных пользовательских.Обратите внимание, что цель SUID / SGID, если вы идете таким образом, не обязательно должна быть root ;это просто должно отличаться от собственного пользователя.Это, однако, снова возвращает к назначенному идентификатору для запуска программы.

Опция capabilites требует, чтобы ваша система, конечно, поддерживала возможности.Если это не так, то SUID / SGID - ваш единственный оставшийся вариант.Оба из них управляются атрибутами, прикрепленными к двоичному файлу программы в файловой системе, поэтому они не требуют изменения самой программы.