Как определить, как и почему изменились двоичные разрешения sudo
У меня есть система, которая уже много лет работает нормально на Ubuntu 20.04 (да, случаются перезагрузки — я не имею в виду непрерывную работу). Большая часть работы в этой системе выполняется через командную строку (на самом деле почти исключительно через ssh), и довольно часто используется sudo.
Сегодня днем мне нужно было что-то увидеть в папке /var/log, и я, как обычно, набрал
sudo tail /var/log/syslog
Мне вернули сообщение:
/usr/bin/sudo must be owned by uid 0 and setuid bit set
(формулировка может быть неточной.) Когда я выполнил команду «ls -l /usr/bin/sudo», к своему ужасу я увидел, что разрешения были rwxr-xr-x (или 755). Он принадлежал пользователю root:root, но бит setuid не был установлен.
С тех пор я исправил это, загрузившись в режим восстановления и изменив его с помощью:
chmod u+s /usr/bin/sudo
Но у меня вопрос: как я могу определить, как и почему это произошло? Разрешения для файлов в системе не должны просто меняться, поэтому я подозреваю, что произошло обновление программного обеспечения или что-то зловещее - или, возможно, ошибка пользователя с моей стороны. Обновление программного обеспечения кажется маловероятным, поскольку я предполагаю, что это вызовет во вселенной рябь, которую я не смогу пропустить. Также ОЧЕНЬ маловероятно, что это сделал я (единственный человек, имеющий доступ к системе, поскольку она находится у меня дома и защищена двумя довольно хорошими брандмауэрами), но я с готовностью признаю, что я человек и мог бы я так и сделал, я полагаю. Но я так не думаю!
Единственная связанная резервная копия, которая у меня есть для /usr/bin, — это не резервная копия на уровне файлов, а резервная копия системы, поэтому я не могу легко проверить резервные копии, чтобы узнать, как долго разрешения sudo были проблемой. (Недолго, я могу это с уверенностью сказать.) Я сразу же начну разработку решения для резервного копирования «системных каталогов». Теперь, когда лошадь сбежала, я запру дверь сарая.
Есть идеи, что я могу сделать, чтобы определить, как и почему возникла эта проблема? Что беспокоит меня почти так же, как и очевидное, так это то, что могут быть и другие вещи, затронутые подобным же образом, о которых я еще не знаю.
В связи с этим: доступен ли сейчас какой-либо аудит, который можно запустить, чтобы убедиться, что разрешения являются такими, какими они должны быть? (У меня есть несколько других систем Ubuntu локально, но они используют Ubuntu 22.04 - и одну систему Darwin (Mac). Поэтому я не думаю, что сравнение аудита между ними реалистично...
РЕДАКТИРОВАТЬ
По предложению @waltinator я запустил sudo Journalctl /usr/bin/sudo. Я обнаружил, что эти два обновления произошли 10 ноября, и sudo больше не использовался до сегодняшней проблемы. Вот изображение, показывающее сокращенный журнал:
Вот важная часть этого, неформатированная:
Так что похоже, что произошло обновление программного обеспечения, которое выглядит раздражающе подозрительным.

