LINUX.ORG.RU

Эксперименты с SUID, SGID, /usr/bin/passwd, /etc/shadow

 , , ,


0

1

Привет.

Operating System: Ubuntu 22.04.2 LTS
Kernel: Linux 5.19.0-45-generic

Поставил файлу /etc/shadow группу root и все права для группы.

----rwx--- 1 root root ... /etc/shadow
-rwxr-sr-x 1 root root ... /usr/bin/passwd

У файла /usr/bin/passwd убрал SUID и добавил SGID, ожидая что результат работы утилиты passwd будет таким же как и до изменений. На деле, натыкаюсь на ошибку:

user@Ubuntu1:~$ passwd
Changing password for user.
Current password: 
New password: 
Retype new password: 
passwd: Authentication token manipulation error
passwd: password unchanged

Почему так происходит и как заставить утилиту работать с установленным SGID и отсутствующим SUID?


Для того чтобы система приняла вводимый пароль, у файла /etc/shadow должны быть минимальные права 0040 и/или 0004. Если же «r» отсутствует у группы и других пользователей (rwx-wx-wx), получаем такой результат:

user@Ubuntu1:~$ passwd
Changing password for user.
Current password: 
Current Password: 
passwd: Authentication token manipulation error
passwd: password unchanged

Т.е. ошибка появляется уже на этапе ввода текущего пароля. До ввода нового не доходим. Полагаю, что если у файла shadow отсутствуют нужные права, мы должны увидеть сообщение - Permission denied. Но в данном случае предлагается дважды ввести пароль (независимо от того верно мы вводим его или нет). Почему это происходит?


3й вопрос вытекает из второго. Почему в первой строке ввода «password» с маленькой буквы, а во втором «Password:» - с большой? Откуда тянется текст «Current password:» и «Current Password:»?



Последнее исправление: Welder (всего исправлений: 2)

Для начала проверь запуск passwd в неубранным suid битом. А ещё запуск passwd от рута. Возможно, он просто видит некорректные права на shadow (вручную проверяет) и отказывается с ним работать.

А ещё сделай strace (сначала запусти passwd который неsuid уже, потому во втором окне рутом подключись strace -p к нему, потом вводи что-то).

firkax ★★★★★
()
Последнее исправление: firkax (всего исправлений: 1)

Вангую, что нужны права на запись в каталог /etc т.к. сначала создается файл-бекап, а изменения пишутся в новый файл...

vel ★★★★★
()

Почему так происходит и как заставить утилиту работать с установленным SGID и отсутствующим SUID?

GNU/Linux — свободное ПО, исходники открыты. Скачай исходники passwd и pam и копайся в них. В passwd всего 5 маленьких исходников, около 1500 строк. Сам запрос пароля делается в pam, там и ищи строчки. Если найдёшь почему второй промпт отличается от первого, расскажешь.

debugger ★★★★★
()

firkax

С установленным SUID всё работает у обычного юзера.
От рута passwd работает даже при таких куцых правах:

---------- 1 root root  1758 июн 18 21:34 /etc/shadow  
---x------ 1 root root 59976 ноя 24  2022 /usr/bin/passwd  

Отойду от темы. Мне непонятно следующее.
С одной стороны, полное отсутствие прав у файла shadow и возможность успешного выполнения passwd от рута, говорит о том что даже бесправный рут может все.
С другой стороны, руту необходимо право u+x на /usr/bin/passwd для работы passwd. Если убрать это право, получим результат

root@Ubuntu1:~# passwd
-bash: /usr/bin/passwd: Permission denied

Если у кого есть ссыль на мануал где объясняется в каких случаях даже руту нужны права, а в каких рут может обойтись вообще без них, скиньте плз

Возможно, он просто видит некорректные права на shadow (вручную проверяет)

Я верно понял что в системе где-то глубоко могут быть зашиты настройки что shadow может правиться только пользователем root (а не группой root) что бы там в правах не было указано?

За strace отдельное спасибо. Примерно понятно куда копать.


vel

Вангую, что нужны права на запись в каталог /etc

Не помогло


debugger

Скачай исходники passwd и pam и копайся в них.

Ок


Всем спасибо за ваше время и ответы!

Welder
() автор топика
Ответ на: комментарий от Welder

Если у кого есть ссыль на мануал где объясняется в каких случаях даже руту нужны права, а в каких рут может обойтись вообще без них

https://unix.stackexchange.com/questions/412234/how-do-file-permissions-work-...

Pinkbyte ★★★★★
()
Ответ на: комментарий от Welder

С одной стороны, полное отсутствие прав у файла shadow и возможность успешного выполнения passwd от рута, говорит о том что даже бесправный рут может все.

Рут игнорирует наличие rw в правах. А вот x это не совсем право, это скорее флаг что файл действительно исполняемый - и его рут не игнорирует.

Я верно понял что в системе где-то глубоко могут быть зашиты настройки что shadow может правиться только пользователем root (а не группой root) что бы там в правах не было указано?

Нет, это в программе passwd может быть проверка: некорректные права на shadow - пишем ошибку и выходим. Некорректные не всмысле что их не хватает, а всмысле что они небезопасные. ssh вроде например так же отказывается работать с приватными ключами, если у них лишние доступы на чтение имеются для кого-то кроме владельца. Что именно там passwd проверяет я не знаю, потому и посоветовал strace чтобы увидеть что он смотрел перед выдачей ошибки.

firkax ★★★★★
()
Последнее исправление: firkax (всего исправлений: 2)
Ответ на: комментарий от firkax
openat(AT_FDCWD, "/etc/nshadow", O_WRONLY|O_CREAT|O_TRUNC, 0666) = 4
umask(077)                              = 077
openat(AT_FDCWD, "/etc/shadow", O_RDONLY) = 5
newfstatat(5, "", {st_mode=S_IFREG|0640, st_size=846, ...}, AT_EMPTY_PATH) = 0
fchown(4, 0, 43)                        = 0
fchmod(4, 0100640)                      = 0
lseek(5, 0, SEEK_CUR)                   = 0
newfstatat(5, "", {st_mode=S_IFREG|0640, st_size=846, ...}, AT_EMPTY_PATH) = 0
read(5, "root:$5$uEJrU/jL82ZP$JOFD9rR"..., 4096) = 846
newfstatat(4, "", {st_mode=S_IFREG|0640, st_size=0, ...}, AT_EMPTY_PATH) = 0
lseek(5, 0, SEEK_CUR)                   = 846
read(5, "", 4096)                       = 0
close(5)                                = 0
write(4, "root:$5$uEJrU/jL82ZP$JOFD9rR"..., 893) = 893
fsync(4)                                = 0
close(4)                                = 0
rename("/etc/nshadow", "/etc/shadow")   = 0

Явно нужны права на запись в /etc, которых для группы root там нет.

vel ★★★★★
()