Зафиксировать setuid и setgid биты в/usr?
Я сделал что-то глупое:
chown -R root:root /usr
chmod -R g-w /usr
По-видимому, лучшая вещь, которую я могу сделать, переустанавливают систему. Однако моя система хорошо работает до сих пор - там что-нибудь сразу опасно не фиксация этого ASAP? У меня есть Ubuntu 18.04 (никакое Интернет-соединение), она просто используется в качестве локального NAS.
Причина я сделал это, происходила из-за предупреждения при выполнении обновлений:
WARN: uid is 0 but '/usr' is owned by 1000
WARN: /usr is group writable!
Я спросил, и кто-то на форуме, предложенном вышеупомянутые команды с "им, совершенно безопасен". Урок извлечен: не доверяйте людям в Интернете, даже если они звучат полностью убежденными.
Причина, по-видимому, почему /usr была перезаписываемая группа, и не принадлежавший корню из-за моего определенного DIY-Nas Ubuntu (Odroid):
drwxrwxr-x 10 odroid odroid 4096 Apr 12 2018 usr
Возможно, я не должен был использовать -R рекурсивная опция. Это не имеет значения теперь.
Последние несколько часов, я просмотрел различные сообщения для обнаружения то, что я сделал. Это похоже на выполнение любого chown на /usr повреждения setuid и setgid биты, таким образом, я должен был бы вручную выдержать сравнение с существующей системой для восстановления всех тех, после того как я имею, фиксируют владение снова. Для фиксации sudo команда, я уже сделал это:
chown root:root /usr/bin/sudo && chmod 4755 /usr/bin/sudo
Помимо этого, я больше не вижу проблем. Когда я вхожу в систему интерфейса Ubuntu, я получаю предупреждение разрешения из некоторого программного обеспечения Bluetooth, но это не immidiatly релевантный. Я понимаю, что существует некоторое программное обеспечение в/usr, который имеет группу кроме root (см. список здесь, например), по причинам безопасности - но там будут какие-либо действительно отрицательные эффекты на мою nas-систему, особенно связанную с вещами обработки/архива файла, например, поврежденными или недоступными файлами?
Обратите внимание, что я создал новую учетную запись stackexchange, потому что я слишком смущен.. так или иначе, большое спасибо за предложения!
2 ответа
Я думаю, что Вы были удачливы, потому что Вы просто удалили "перезаписываемый" бит для групп. Это не будет влиять на SETGID или биты SETUID. Если они были установлены прежде, они все еще установлены. Команда chmod -R 777 /usr с другой стороны, сброс все биты к rwx при удалении любых других битов одновременно, включая s биты. Поэтому люди, которые вышли chmod -R 777 /usr обычно вынуждаются сделать переустанавливание.
Возможно, наблюдения, которые я сделал в своей системе, могут помочь Вам. Я выполнил некоторых find команды для наблюдения, какие файлы и каталоги были бы затронуты командами, которые Вы дали. Вот результаты:
# Find all files and directories NOT owned by user root:
find usr -not -user root -ls
3407926 52 -rwsr-sr-x 1 daemon daemon 51464 Feb 20 2018 usr/bin/at
# Find all files and directories NOT owned by group root:
find usr -not -group root -ls
3418319 4 drwxrwsr-x 3 root staff 4096 Jan 5 2018 usr/local/lib/python3.6
3418322 4 drwxrwsr-x 2 root staff 4096 Jan 5 2018 usr/local/lib/python3.6/dist-packages
3419229 4 drwxrwsr-x 4 root staff 4096 Nov 13 20:03 usr/local/lib/python2.7
3419230 4 drwxrwsr-x 2 root staff 4096 Jan 26 2018 usr/local/lib/python2.7/dist-packages
1049153 4 drwxrwsr-x 2 root staff 4096 Nov 13 20:03 usr/local/lib/python2.7/site-packages
3544477 4 drwxrwsr-x 2 root staff 4096 Jan 5 2018 usr/local/share/fonts
3418324 4 drwxrwsr-x 3 root staff 4096 Jan 5 2018 usr/local/share/emacs
3544479 4 drwxrwsr-x 2 root staff 4096 Jan 5 2018 usr/local/share/emacs/site-lisp
3416934 372 -rwsr-xr-- 1 root dip 378600 Jun 12 19:20 usr/sbin/pppd
3410196 40 -rwxr-sr-x 1 root mail 39000 Apr 3 2018 usr/sbin/ssmtp
3408208 12 -rwxr-sr-x 1 root utmp 10232 Mär 11 2016 usr/lib/x86_64-linux-gnu/utempter/utempter
3419827 12 -rwxr-sr-x 1 root tty 10232 Aug 4 2017 usr/lib/mc/cons.saver
3428536 16 -rwxr-sr-x 1 root mail 14336 Jul 31 16:14 usr/lib/evolution/camel-lock-helper-1.2
3416858 44 -rwsr-xr-- 1 root messagebus 42992 Nov 15 2017 usr/lib/dbus-1.0/dbus-daemon-launch-helper
1183416 4 drwxrwsr-t 2 root lpadmin 4096 Nov 8 2017 usr/share/ppd/custom
3410118 44 -rwxr-sr-x 1 root mlocate 43088 Mär 1 2018 usr/bin/mlocate
3408029 16 -rwxr-sr-x 1 root tty 14328 Jan 17 2018 usr/bin/bsd-write
3414379 356 -rwxr-sr-x 1 root ssh 362640 Nov 5 12:51 usr/bin/ssh-agent
3410676 32 -rwxr-sr-x 1 root tty 30800 Jul 26 18:20 usr/bin/wall
3409008 72 -rwxr-sr-x 1 root shadow 71816 Jan 25 2018 usr/bin/chage
3416771 24 -rwxr-sr-x 1 root shadow 22808 Jan 25 2018 usr/bin/expiry
3407926 52 -rwsr-sr-x 1 daemon daemon 51464 Feb 20 2018 usr/bin/at
3409356 40 -rwxr-sr-x 1 root crontab 39352 Nov 16 2017 usr/bin/crontab
# find objects that have the group-writable bit set and are owned by user=root but group!=root:
find usr -perm -0020 -user root -not -group root -ls
3418319 4 drwxrwsr-x 3 root staff 4096 Jan 5 2018 usr/local/lib/python3.6
3418322 4 drwxrwsr-x 2 root staff 4096 Jan 5 2018 usr/local/lib/python3.6/dist-packages
3419229 4 drwxrwsr-x 4 root staff 4096 Nov 13 20:03 usr/local/lib/python2.7
3419230 4 drwxrwsr-x 2 root staff 4096 Jan 26 2018 usr/local/lib/python2.7/dist-packages
1049153 4 drwxrwsr-x 2 root staff 4096 Nov 13 20:03 usr/local/lib/python2.7/site-packages
3544477 4 drwxrwsr-x 2 root staff 4096 Jan 5 2018 usr/local/share/fonts
3418324 4 drwxrwsr-x 3 root staff 4096 Jan 5 2018 usr/local/share/emacs
3544479 4 drwxrwsr-x 2 root staff 4096 Jan 5 2018 usr/local/share/emacs/site-lisp
1183416 4 drwxrwsr-t 2 root lpadmin 4096 Nov 8 2017 usr/share/ppd/custom
Конечно, Ваш пробег может варьироваться, варьировались, но я уверен, что Вы только "повредили" горстку файлов. Подавляющее большинство объектов ниже /usr принадлежат root:root и обычно имейте также rwxrwxr-x или rwxr-xr-x. Удаление g-w бит действительно не причиняет вред, потому что он удаляет записываемый бит для группы root но (по крайней мере, в моей стандартной системе) единственный член той группы является пользователем root так или иначе и у него есть доступ для записи через полномочия пользователя (который Вы не изменили), и действительно не нуждается в доступе для записи через состав группы.
Btw, мой /usr самостоятельно имеет следующие атрибуты:
drwxr-xr-x 10 root root 4096 Jan 5 2018 usr/
Обновление
OP упоминает, что он столкнулся с ошибкой
sudo: /usr/bin/sudo must be owned by uid 0 and have the setuid bit set
после издания chmod g-w и chown root:root и должен был зафиксировать его с chmod 4755 /usr/bin/sudo. Как оказалось, chown g-w действительно НЕ изменяется, setuid укусил, но chown root:root сделал. Это, по-видимому, очищает те SETUID (и по-видимому также SETGID и ЛИПКИЙ) биты. Мне это - неожиданное поведение, но я вполне уверен существует объяснение и/или причина.как бы то ни было. Я выполнил другого find команда для наблюдения, который из моих файлов ниже /usr имейте один или несколько SETUID, SETGID и ЛИПКОГО набора битов:
find usr -perm /7000 -printf '%M\t%u:%g\t%p\n'
drwxrwsr-x root:staff usr/local/lib/python3.6
drwxrwsr-x root:staff usr/local/lib/python3.6/dist-packages
drwxrwsr-x root:staff usr/local/lib/python2.7
drwxrwsr-x root:staff usr/local/lib/python2.7/dist-packages
drwxrwsr-x root:staff usr/local/lib/python2.7/site-packages
drwxrwsr-x root:staff usr/local/share/fonts
drwxrwsr-x root:staff usr/local/share/emacs
drwxrwsr-x root:staff usr/local/share/emacs/site-lisp
-rwsr-xr-- root:dip usr/sbin/pppd
-rwxr-sr-x root:mail usr/sbin/ssmtp
-rwxr-sr-x root:utmp usr/lib/x86_64-linux-gnu/utempter/utempter
-rwsr-sr-x root:root usr/lib/xorg/Xorg.wrap
-rwxr-sr-x root:tty usr/lib/mc/cons.saver
-rwsr-sr-x root:root usr/lib/snapd/snap-confine
-rwxr-sr-x root:mail usr/lib/evolution/camel-lock-helper-1.2
-rwsr-xr-- root:messagebus usr/lib/dbus-1.0/dbus-daemon-launch-helper
-rwsr-xr-x root:root usr/lib/openssh/ssh-keysign
-rwsr-xr-x root:root usr/lib/policykit-1/polkit-agent-helper-1
-rwsr-xr-x root:root usr/lib/eject/dmcrypt-get-device
drwxrwsr-t root:lpadmin usr/share/ppd/custom
-rwxr-sr-x root:mlocate usr/bin/mlocate
-rwxr-sr-x root:tty usr/bin/bsd-write
-rwsr-xr-x root:root usr/bin/traceroute6.iputils
-rwsr-xr-x root:root usr/bin/gpasswd
-rwxr-sr-x root:ssh usr/bin/ssh-agent
-rwsr-xr-x root:root usr/bin/passwd
-rwsr-xr-x root:root usr/bin/pkexec
-rwsr-xr-x root:root usr/bin/sudo
-rwxr-sr-x root:tty usr/bin/wall
-rwsr-xr-x root:root usr/bin/chfn
-rwxr-sr-x root:shadow usr/bin/chage
-rwsr-xr-x root:root usr/bin/arping
-rwxr-sr-x root:shadow usr/bin/expiry
-rwsr-sr-x daemon:daemon usr/bin/at
-rwxr-sr-x root:crontab usr/bin/crontab
-rwsr-xr-x root:root usr/bin/chsh
-rwsr-xr-x root:root usr/bin/newgrp
Этот список не очень длинен, но он все еще содержит некоторые файлы, которые я считал бы крайне важным. Особенно те, которые в последней трети, как passwd, crontab, и т.д., и конечно sudo.
Я думаю, что вышеупомянутый ответ от @PerlDuck объясняет большинство решающих вещей. После работы через каждый файл вручную, я думаю, что удалил самую большую путаницу. Если бы этот компьютер был бы выставлен Интернету, я переустановил бы сразу же - теперь у меня есть еще некоторое время.
Так или иначе я хочу добавить ссылку к полному списку полномочий значения по умолчанию Linux здесь: https://www.vidarholen.net/contents/junk/ubuntu_permissions.html Это также помогло мне восстановить много дополнительных полномочий файла.