Бит SUID исчезает из программы

Question

Бит SUID исчезает из программы

У меня есть несколько серверов Debian 11.8, и недавно начало происходить что-то странное. Бит SUID начал пропадать из программы на всех серверах примерно одновременно.

Например, два дня назад примерно одновременно потерял бит SUID на 4 серверах. Затем вчера бит SUID исчез еще на двух серверах.

На всех серверах произошло следующее:

      [Sun Oct  8 06:33:57 2023] systemd[1]: systemd 247.3-7+deb11u4 running in system mode. (+PAM +AUDIT +SELINUX +IMA +APPAR
MOR +SMACK +SYSVINIT +UTMP +LIBCRYPTSETUP +GCRYPT +GNUTLS +ACL +XZ +LZ4 +ZSTD +SECCOMP +BLKID +ELFUTILS +KMOD +IDN2 -IDN
 +PCRE2 default-hierarchy=unified)
[Sun Oct  8 06:33:57 2023] systemd[1]: Detected architecture x86-64.
[Sun Oct  8 06:33:57 2023] systemd[1]: /etc/systemd/system/rc-local.service:11: Support for option SysVStartPriority= ha
s been removed and it is ignored
[Sun Oct  8 06:33:57 2023] systemd-journald[392]: Received SIGTERM from PID 1 (systemd).
[Sun Oct  8 06:33:57 2023] systemd[1]: Stopping Journal Service...
[Sun Oct  8 06:33:57 2023] systemd[1]: systemd-journald.service: Succeeded.
[Sun Oct  8 06:33:57 2023] systemd[1]: Stopped Journal Service.
[Sun Oct  8 06:33:57 2023] systemd[1]: systemd-journald.service: Consumed 5min 10.083s CPU time.
[Sun Oct  8 06:33:57 2023] systemd[1]: Starting Journal Service...
[Sun Oct  8 06:33:57 2023] systemd[1]: Started Journal Service.
[Sun Oct  8 06:33:57 2023] systemd-journald[4157624]: Received client request to flush runtime journal.

После этой записи dmesg программа/usr/lib/qemu/qemu-bridge-helperпотерял бит SUID.

Кто-нибудь знает, что могло случиться? Это сделал systemd? Есть ли у него какая-то мера безопасности, которая сканирует систему и удаляет бит SUID из программ?

Прямо сейчас я решил это, поставивchmod u+s /usr/lib/qemu/qemu-bridge-helperв задание cron, которое выполняется каждую минуту, чтобы, когда это произойдет, я вернул бит SUID обратно.

0

systemd suid

Источник

Peter Krumins 10 окт '23 в 09:46

2 ответа

Другие вопросы по тегам systemd suid

grawity 15 окт '23 в 07:02 2023-10-15 07:02 · Answer 1 · 2023-10-15 07:02

Используйте систему «аудита», чтобы определить, какой процесс может изменять разрешения:

      auditctl -w /usr/lib/qemu/qemu-bridge-helper -p wa

Есть ли у него какая-то мера безопасности, которая сканирует систему и удаляет бит SUID из программ?

Это не так.

       [Sun Oct  8 06:33:57 2023] systemd[1]: systemd 247.3-7+deb11u4 running in system mode. (+PAM +AUDIT +SELINUX +IMA +APPARMOR +SMACK +SYSVINIT +UTMP +LIBCRYPTSETUP +GCRYPT +GNUTLS +ACL +XZ +LZ4 +ZSTD +SECCOMP +BLKID +ELFUTILS +KMOD +IDN2 -IDN +PCRE2 default-hierarchy=unified)
[Sun Oct  8 06:33:57 2023] systemd[1]: Detected architecture x86-64.

Это немного похоже наsystemctl daemon-reexec(он жеtelinit u), выполняемый как часть обновления пакета, возможно, во время обычного запуска автоматических обновлений Debian или какого-либо другого вида cronjob.

symcbean 12 окт '23 в 15:49 2023-10-12 15:49 · Answer 2 · 2023-10-12 15:49

Если применение разрешений вручную временно решает проблему, вы можете исключить опцию монтирования nosuid.

Первое, что я хотел бы проверить, это было ли в это время на хосте какое-либо развертывание/исправление (сообщит вам, в каком пакете он появился, а /var/log/dpkg должен перечислить все изменения).

Кроме мониторинга файла с помощью Auditctl, я не знаю способа узнать точное время изменения разрешений файла. Включение аудита затронутых файлов позволит фиксировать любые будущие происшествия. Знание этого времени было бы полезно для согласования этого события с другими происходящими событиями (входы в систему, задания cron). Как говорит @AaronCopley, причиной может быть чрезмерная/недостаточная компетентность ITSecurity.

На всех серверах произошло следующее

Это похоже на сообщения при запуске. Но у вас проблема на физических хостах? Это придало бы некоторый вес теории обновлений, но странно, что вы не упомянули о перезагрузке.