Почему su world исполняемый?

У меня есть безголовый сервер, который удаленно подключен к нескольким пользователям. Ни один из других пользователей не находится в файле sudoers, поэтому они не могут получить root через sudo. Однако, поскольку разрешения на suэто -rwsr-xr-xнет ничего остановить их от попыток перебора пароля суперпользователя.

Можно утверждать, что если пользователь знает пароль root, он все равно может поставить под угрозу систему, но я не думаю, что это так. OpenSSH настроен с PermitRootLogin noи PasswordAuthentication no, и никто из других пользователей не имеет физического доступа к серверу. Насколько я могу судить, разрешение на выполнение в мире /usr/bin/su- единственная возможность для пользователей, пытающихся получить root на моем сервере.

Что еще удивляет меня тем, что это даже не кажется полезным. Это позволяет мне бегать suнапрямую, а не делать это sudo su, но это вряд ли неудобство.

Я что-то пропускаю? Является ли мир исполнять разрешение suтолько по историческим причинам? Есть ли недостатки в удалении этого разрешения, с которым я еще не сталкивался?

Единственное, чего не хватает в ответе ilkkachu, это то, что повышение прав до root - это только одно конкретное применение su. Общая цель su - открыть новую оболочку под учетной записью другого пользователя. Этим другим пользователем может быть root(и, возможно, чаще всего), но suего можно использовать для предположения любой идентичности, которую может аутентифицировать локальная система.

Например, если я вошел в систему как пользователь jim, и я хочу исследовать mikeсообщенную проблему , но которую я не могу воспроизвести, я мог бы попытаться войти в систему как mikeи выполнить команду, которая доставляет ему проблемы.

13:27:20 /home/jim> su -l mike
Password:(I type mike's password (or have him type it) and press Enter)
13:27:22 /home/mike> id
uid=1004(mike) gid=1004(mike) groups=1004(mike)
13:27:25 /home/mike> exit  # this leaves mike's login shell and returns to jim's
13:27:29 /home/jim> id
uid=1001(jim) gid=1001(jim) groups=1001(jim),0(wheel),5(operator),14(ftp),920(vboxusers)

Использование -lопции suприводит к симуляции полного входа в систему (на manстранице).

Выше необходимо знать mikeпароль пользователя, однако. Если у меня есть sudoдоступ, я могу войти как mikeдаже без его пароля.

13:27:37 /home/jim> sudo su -l mike
Password:(I type my own password, because this is sudo asking)
13:27:41 /home/mike>

Таким образом, причина, по suкоторой вы видите права доступа к исполняемому файлу, заключается в том, что suэто универсальный инструмент , доступный всем пользователям системы.

Исторически (для не-GNU юнитов) это не было или, по крайней мере, проверялось вручную, находились ли вы в группе под названием «wheel» su. Версия GNU suне воспроизводила эту функциональность из-за идеологии RMS об управлении доступом в то время:

Why GNU `su' does not support the `wheel' group
===============================================

   (This section is by Richard Stallman.)

   Sometimes a few of the users try to hold total power over all the
rest.  For example, in 1984, a few users at the MIT AI lab decided to
seize power by changing the operator password on the Twenex system and
keeping it secret from everyone else.  (I was able to thwart this coup
and give power back to the users by patching the kernel, but I wouldn't
know how to do that in Unix.)

   However, occasionally the rulers do tell someone.  Under the usual
`su' mechanism, once someone learns the root password who sympathizes
with the ordinary users, he or she can tell the rest.  The "wheel
group" feature would make this impossible, and thus cement the power of
the rulers.

   I'm on the side of the masses, not that of the rulers.  If you are
used to supporting the bosses and sysadmins in whatever they do, you
might find this idea strange at first.

Вы можете найти намного больше по этому вопросу, прибегая к помощи "колесной группы RMS" или подобным.

Однако, поскольку разрешения на suэто -rwsr-xr-xнет ничего остановить их от попыток перебора пароля суперпользователя.

Да. Предполагая, что вы используете обычную систему Linux, pam_unix.soмодуль задерживает неудачную попытку аутентификации на ~ две секунды, но я не думаю, что есть что-то, чтобы остановить одновременные попытки.

Неудачные попытки регистрируются, конечно:

Aug 16 22:52:33 somehost su[17387]: FAILED su for root by ilkkachu

Брут-форсирование пароля должно быть заметно в журналах, если у вас есть какая-либо система для их мониторинга. И если вы не доверяли локальным пользователям, возможно, вам следует. Ненадежные локальные пользователи также могут пытаться использовать любые локальные эксплойты для повышения привилегий, и они гораздо более распространены, чем удаленное повышение привилегий.

Что еще удивляет меня тем, что это даже не кажется полезным.

Конечно, это полезно, это позволяет вам подняться root, если вы знаете пароль.

Это позволяет мне бегать suнапрямую, а не делать это sudo su, но это вряд ли неудобство.

sudo suнесколько избыточно. Нет необходимости использовать две программы, предназначенные для запуска программ от имени другого пользователя, одной вполне достаточно. Просто используйте sudo -iили sudo -s(или sudo /bin/bashт. Д.), Если вы хотите запустить shell.

Я что-то пропускаю? Является ли мир исполнять разрешение на Су только по историческим причинам?

Смотри выше. Ну, не все системы имеют sudoв качестве альтернативы, я не уверен, если вы считаете это историческим.

Есть ли недостатки в удалении этого разрешения, с которым я еще не сталкивался?

Не совсем, нет, насколько я знаю. Я думаю, что некоторые системы suнастроены так, что wheelзапускать его могут только члены определенной группы (" "). Вы можете сделать то же самое, sudoесли хотите ( chown root.sudousers /usr/bin/sudo && chmod 4710 /usr/bin/sudo).

Или вы можете просто удалить одну или обе программы, если они вам не нужны. Хотя в Debian и suидет loginпакет, поэтому, вероятно, не стоит удалять пакет целиком. (И спаривание, loginи suподобное вместе кажутся историческими.)

У вас уже есть несколько хороших ответов, но есть одна часть вашего сообщения, к которой они не обращаются.

Насколько я могу судить, разрешение на выполнение в мире для / usr / bin / su - единственная возможность для пользователей, пытающихся получить права root на моем сервере.

Это опасное предположение. Если вы установили хороший пароль для пользователя root, то в большинстве случаев более вероятно, что успешное повышение привилегий будет связано с использованием ошибки в ядре или двоичного файла setuid (вы, конечно, также можете удалить setuid немного от них, но passwdэто setuid, и если вы хотите обеспечить высокий уровень безопасности, вы также должны предложить это своим пользователям, и отказ в предоставлении им возможности сменить пароль не совместим с этим).

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

Если вы обеспокоены тем, что кто-то может взломать пароль root, вы можете просто отключить его. (сделать хеш недействительным, чтобы ни один пароль не мог ему соответствовать)

Я не знаю о консенсусе, но я бы подумал, что возможность войти в систему как root напрямую сама по себе является проблемой безопасности.

Другие ответы верны: «su» позволяет вам войти в учетные записи, отличные от root.

Одно замечание о "sudo su", хотя. Это фактически позволяет вам войти в систему под учетной записью root, не зная пароль root. Вам необходимо знать пароль учетной записи, с которой вы запускаете sudo, а также указывать эту учетную запись в файле sudoers.