[devel] Понижение прав с root не работает в alt-p8-rootfs-systemd

Alexey Sheplyakov asheplyakov на basealt.ru
Пн Апр 20 17:44:42 MSK 2020


On Sat, Apr 18, 2020 at 06:37:55PM +0300, Mikhail Novosyolov wrote:

> [root на pay2 /]# strace -f su - user -c /bin/bash 2>&1 | grep bin/bash
> execve("/bin/su", ["su", "-", "user", "-c", "/bin/bash"], 0x7ffccf65b4a8 /* 30 vars */) = 0
> [pid 37104] execve("/bin/bash", ["-bash", "-c", "/bin/bash"], 0x12fa9a0 /* 17 vars */) = -1 EAGAIN (Ресурс временно недоступен)

Единственная ситуация, когда exec* возвращает EAGAIN -- превышение лимита
RLIMIT_NPROC. Подробности описаны в `execve() and EAGAIN` в man execve [1]

Кратко: когда-то давно seteeuid, setresuid со товарищи возвращали ошибку при
превышении лимитов ресурсов (тем UID, на который пытались переключиться).
Тем самым создавая предпосылки для дыр имени sendmail setuid [2]. Разработчики
ядра решили, что сброс привилегий всегда должен работать, и перенесли проверку
RLIMIT_NPROC из set*[ug]id в exec*. С тех пор exec* в случае превышения числа
процессов^W потоков возвращает EAGAIN.

[1] http://man7.org/linux/man-pages/man2/execve.2.html
[2] https://seclists.org/bugtraq/2000/Jun/98

# strace -f -e setuid,execve su -l user -s /bin/true
execve("/bin/su", ["su", "-l", "user", "-s", "/bin/true"], 0x7ffd053a22c8 /* 31 vars */) = 0
strace: Process 5089 attached
[pid  5089] +++ exited with 0 +++
--- SIGCHLD {si_signo=SIGCHLD, si_code=CLD_EXITED, si_pid=5089, si_uid=0, si_status=0, si_utime=0, si_stime=0} ---
setuid(0)                               = 0
strace: Process 5090 attached
[pid  5090] setuid(1000)                = 0
[pid  5090] execve("/bin/true", ["-true"], 0x1de9c40 /* 18 vars */) = -1 EAGAIN (Resource temporarily unavailable)
su: exec failed
[pid  5090] +++ exited with 1 +++
+++ exited with 1 +++

А теперь уберем лимиты:

# mv /etc/security/limits.d /etc/security/limits.d.NONONO

И попробуем еще раз

# strace -f -e setuid,execve su -l user -s /bin/true
execve("/bin/su", ["su", "-l", "user", "-s", "/bin/true"], 0x7ffd7883da48 /* 31 vars */) = 0
strace: Process 5151 attached
[pid  5151] +++ exited with 0 +++
--- SIGCHLD {si_signo=SIGCHLD, si_code=CLD_EXITED, si_pid=5151, si_uid=0, si_status=0, si_utime=0, si_stime=0} ---
setuid(0)                               = 0
strace: Process 5152 attached
[pid  5152] setuid(1000)                = 0
[pid  5152] execve("/bin/true", ["-true"], 0x1135c40 /* 18 vars */) = 0
[pid  5152] +++ exited with 0 +++
+++ exited with 0 +++

Замечу, что в обоих случаях собственно сборс привилегий (setuid(1000))
прошел успешно.

> Не. Дело не в ulimit.

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

1) выводом strace -f -e setuid,execve su -l user -s /bin/true

2) выводом sudo -u user -i ulimit -a (в этом chroot'е)

3) содержимым /etc/security/limits.conf /etc/security/limits.d/*.conf

4) если Ваш UID в хост системе тоже 1000, то и выводом
   ps -T -u `whoami` | wc -l (в host системе)

> В соседнем контейнере с запуском от UID=1000 нет проблем. Это именно в контейнере что-то не то.

В контейнере или chroot'е? (А еще точнее, UID namespace есть?)
И там ровно те же настройки (limits.d/*.conf и прочий PAM)?
А запускаете одновременно оба chroot'а?



Подробная информация о списке рассылки Devel