Зачем нужен sudo?

к сожалению практика сильно отличается от всех тэорий :)

а еще какие разграничения в su есть ??
я прост читал и пользовал ыг эдак лет десять назад.

Предлагаю перейти от детской ссоры

• ты дурак
• нет, ты
• я первый сказал, что ты дурак

к более-менее авторитетным источникам по безопасности

CIS benchmark для RHEL 9 (в benchmark для debian 12 то же самое)

5.3.7 Ensure access to the su command is restricted (Automated)

Profile Applicability:
* Level 1 - Server
* Level 1 - Workstation


Description:
The su command allows a user to run a command or shell as another user. The
program has been superseded by sudo, which allows for more granular control over
privileged access. Normally, the su command can be executed by any user. By
uncommenting the pam_wheel.so statement in /etc/pam.d/su, the su command will only
allow users in a specific groups to execute su. This group should be empty to reinforce
the use of sudo for privileged access.


Rationale:
Restricting the use of su , and using sudo in its place, provides system administrators
better control of the escalation of user privileges to execute privileged commands. The
sudo utility also provides a better logging and audit mechanism, as it can log each
command executed via sudo , whereas su can only record that a user executed the su
program.


Audit:
Run the following command and verify the output matches the line:

  # grep -Pi
  '^\h*auth\h+(?:required|requisite)\h+pam_wheel\.so\h+(?:[^#\n\r]+\h+)?((?!\2)
  (use_uid\b|group=\H+\b))\h+(?:[^#\n\r]+\h+)?((?!\1)(use_uid\b|group=\H+\b))(\
  h+.*)?$' /etc/pam.d/su

  auth required pam_wheel.so use_uid group=<group_name>

Run the following command and verify that the group specified in <group_name> contains
no users:

  # grep <group_name> /etc/group
  <group_name>:x:<GID>:

There should be no users listed after the Group ID field.


Remediation:
Create an empty group that will be specified for use of the su command. The group
should be named according to site policy.


Example:
  # groupadd sugroup

Add the following line to the /etc/pam.d/su file, specifying the empty group:
  auth required pam_wheel.so use_uid group=sugroup


Additional Information:
NIST SP 800-53 Rev. 5:
* AC-3
* MP-2

• Если кто не в курсе, CIS benchmark - это те требования, которые применяются в банковской сфере. И по которым проходят аудит PCI DSS

• В более старых документах (cis benchmark по rhel7) ещё разрешалось использовать su, то в последних версиях - нет

ЧСХ, текст ссылается на документ NIST. Честно признаюсь, документы NIST 800-й серии не читал, я все же не безопасник, а админ

• Для фанатов импортозамещения, есть лаконичные рекомендации ФСТЭК https://fstec.ru/dokumenty/vse-dokumenty/spetsialnye-normativnye-dokumenty/metodicheskij-dokument-ot-25-dekabrya-2022-g

легко видеть, что ФСТЭК взял их более старых верссий CIS benchmark

Итого. Ни в одном источнике я не увидел рекомендаций использовать su вместо sudo. Только наоборот

Restricting the use of su , and using sudo in its place, provides system administrators better control of the escalation of user privileges to execute privileged commands. The sudo utility also provides a better logging and audit mechanism, as it can log each command executed via sudo , whereas su can only record that a user executed the su program.

С интересом ознакомлюсь с другими источниками информации.

• лучше официальными
• или от признанных экспертов в области информационной безопасности. Будет плюсом, если другие эксперты не насовали автору рекомендаций полную панамку за его точку зрения :)

sudo cast annulen rtxtxtrx MagicMirror token_polyak hbars Wapieth pfg l0stparadise firkax mogwai Bfgeshka vbr Psilocybe Khnazile AS frunobulax thesis ya-betmen MrCookie anc ptah_alexs mord0d neumond asdpm anonymous_sama Dr64h s-warus

Никого не забыл?

Никогда не сдавал на сертификат красношапки, так что отмолчусь.

О других не слышал

Я ни в коем случае не эксперт и даже не профессиональный админ, но мне сама постановка вопроса «использовать su вместо sudo» кажется некорректной. Они для разных задач предназначены. Если бы было «su вместо sudo -s», то тут ещё можно сравнивать, но я обычно использую первое, так как печатать короче, а разграничивать привилегии особо не с кем.

Даже интересно, зачем меня кастанули

Все, кто отметились в топике :)

Ну, кроме анонимуса

очень интересный документ, но мне до админских сертификаций как до луны…
su пользовался, но очень давно, сейчас большинство инструкций идет через sudo. да и насколь знаю sudo реализует всю функциональность su и добавляет поверх еще них кучу удобных.
подожду реакции firkax он уж своим вспыхнувшим весь небосвод осветит.

Твоя практика дефективна, смирись с этим и перестань её тут всем впаривать в качестве образца.

Предлагаю перейти от детской ссоры
к более-менее авторитетным источникам по безопасности

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

или от признанных экспертов в области информационной безопасности. Будет плюсом, если другие эксперты не насовали автору рекомендаций полную панамку за его точку зрения :)

Это выходит что истина определяется голосованием. Такой подход считаю ложным.

Истина может определяться наличием/отсутствием аргументов по делу и опровержений к ним (авторство аргументов и опровержений не должно играть роль, надо только проверять их логичность), свои аргументы против sudo я уже привёл, а в ответ ничего кроме «ну мы так привыкли» по сути не услышал.

su можно сравнить с sudo -s

su -c можно сравнить с sudo

но мне сама постановка вопроса «использовать su вместо sudo» кажется некорректной

Постановка чуть более подробная, а именно: 1) использовать su там где функционал между утилитами дублируется, 2) не использовать ничего и признать за опасную практику там где в su соответствующего функционала нет, перейти к другой идеологии работы в этом месте

Итак, в левом углу ринга в красных трусах сборная команда безопасников - CIS, NIST, NSA

В правом углу ринга в синих трусах firkax

Даже не знаю, на кого ставить :)

su -c можно сравнить с sudo

Нет. То есть совсем нет. Ни по удобству, ни по фичам.

свои аргументы против sudo я уже привёл, а в ответ ничего кроме «ну мы так привыкли» по сути не услышал.

Вообще-то наоборот

Тебе привели аргументы, потом ткнули носом в международный стандарт по безопасности, а ты на все отвечаешь «Авторитетным источником считаю себя»

Если завернуть в алиас, то будет почти тот же sudo, но да без фич.

Главное, что пароль не будет запоминать. Без этого даже на локалхосте хреново жить.

В sudo это timestamp_timeout

     timestamp_timeout
                       Number of minutes that can elapse before sudo will ask
                       for a password again.  The timeout may include a frac-
                       tional component if minute granularity is insufficient,
                       for example 2.5.  The default is 15.  Set this to 0 to
                       always prompt for a password.  If set to a value less
                       than 0 the user's time stamp will not expire until the
                       system is rebooted.  This can be used to allow users to
                       create or delete their own time stamps via 'sudo -v'
                       and 'sudo -k' respectively.

Например, отключить можно так:

Defaults        env_reset, timestamp_timeout=0

Стандарт это всего лишь чьё-то коллективное мнение, и аргументом он является только для личностей с сильным стадным инстинктом. Аргументов же по фактам приведено не было, по крайней мере таких которые я бы не опроверг.

ФЕДЕРАЛЬНАЯ СЛУЖБА ПО ТЕХНИЧЕСКОМУ И ЭКСПОРТНОМУ КОНТРОЛЮ
МЕТОДИЧЕСКИЙ ДОКУМЕНТ
РЕКОМЕНДАЦИИ ПО БЕЗОПАСНОЙ НАСТРОЙКЕ ОПЕРАЦИОННЫХ СИСТЕМ LINUX
Утвержден ФСТЭК России
25 декабря 2022 г.

В документе есть такое:

К системным файлам-описаниям очередей cron относятся следующие файлы (могут присутствовать не всегда, в зависимости от операционной системы и ее настроек):
/etc/crontab;
/etc/cron.d (директория и файлы внутри нее);
/etc/cron.hourly (директория и файлы внутри нее);
/etc/cron.daily (директория и файлы внутри нее);
/etc/cron.weekly (директория и файлы внутри нее);
/etc/cron.monthly (директория и файлы внутри нее).

Ну, другого импортозамещения nist у нас нет :)

Так что лучше обратиться к первоисточнику

Приятно видеть, что на лоре ещё чтут традиции настоящей клоунады. Ирси с батарейкиным улыбаются, глядя на тебя

Толсто!

Итак, в левом углу ринга в красных трусах сборная команда безопасников - CIS, NIST, NSA

В правом углу ринга в синих трусах firkax

Но в посте на который вы ответили он прав. su можно сравнить с sudo -s

В том посте два тезиса. Первый про поведение su и sudo. Второй - ну, как обычно

Покажите ссылку на первоисточник.

Стандарт это всего лишь чьё-то коллективное мнение, и аргументом он является только для личностей с сильным стадным инстинктом.

В гранит и в копилку мемов, немедленно!

https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final

А вообще от https://www.nist.gov/cybersecurity-framework и до обеда

Для менее стойких (вроде меня) - cis benchmark для подходящей ОС

https://learn.cisecurity.org/benchmarks

Где там что-то про cron ?

Не знаю. Вы хотите об этом поговорить?

будет забавно, если он еще и в банке работает, наверное, поэтому после Сбера просят не беспокоить

Не работает он в банке, 100%. И в этом топике, и в других это заметно. Вероятно, школота. В широком смысле

ну такой документ мало кому интерестен кроме хацкеров, которые по этим данным могут определить дристр, которые на серваках у них там где-то

Вот источник от признанного мною эксперта:

http://www.stolyarov.info/books/asm_unix#comment-938

Если вы из-под аккаунта с одними полномочиями осуществляете доступ к аккаунту с другими полномочиями, то с точки зрения безопасности компрометация первого автоматически влечёт компрометацию второго. Из этого следует, что в сеансе работы нельзя повышать полномочия. Понижать можно, повышать нельзя. Вообще нельзя, понимаете? Никаким способом. В этом плане sudo вообще попадает под категорический запрет, а su остаётся в системе (без suid-бита) для понижения полномочий при возникновении такой потребности. «Вместо» них пользоваться нельзя ничем, ssh root@localhost тоже делать нельзя. Если нужны права root’а, в систему следует изначально зайти под root’ом. Если машина локальная, то переключиться на текстовую консоль и на ней зайти. Если удалённый доступ, то ssh root@remote-host, только следует при этом понимать, что тот аккаунт, под которым вы работаете на своей рабочей станции и из-под которого делаете этот вот ssh root@somewhere, охранять надо аки зеницу ока, уж во всяком случае браузеры под ним гонять нельзя совершенно точно.

А уж как надо беречь root на такой станции — ну, можно не объяснять. Почему-то часто встречаются админы, которые уверены, что аккаунты серверов надо беречь сильно-сильно, а аккаунты на личных машинах «типа фиг с ними». Ну так вот они заблуждаются: компрометация любого аккаунта означает компрометацию всего, к чему из-под него осуществляется доступ. Компрометация личного админского ноута означает компрометацию всех серверов, которые он админит.

Не знаю.

Ну то есть 4.2

Вы хотите об этом поговорить?

Кастанули меня вы.

ну такой документ мало кому интерестен кроме хацкеров, которые по этим данным могут определить дристр, которые на серваках у них там где-то

Не уверен, что даже хацкеры по этим данным определят дистр :) Тут потомки ванги требуются. :)

ssh root@localhost тоже делать нельзя.
...
Если удалённый доступ, то ssh root@remote-host
На локалхост низя, а на удаленный можно. Он вообще здоровый?

Столярову главное не говорить, что виджеты в Windows 11 крутятся на JS, что в кедах весь рабочий стол, виджеты на нем, всплывающие окошечки — это QML, подмножество JS, а в Gnome все расширения написаны на сим б-гомерзком языке… У него только от этой инфы мир перевернется… Пока он там боролся с JavaScript на сайтах, подлый враг прорвался в тыл

В приведенной цитате автор вообще запрещает и su, и sudo

Да ещё и

сли удалённый доступ, то ssh root@remote-host,

Его квалификация уже понятна

Это не клоунада, я серьёзно. Считать что-то за истину потому что кто-то так решил - это идиотизм. Ты, как я понял, проповедуешь такой подход, что говорит о тебе плохо.

Вполне адекватные заявления. Но есть один недосмотр: он считает, что админы серверов имеют пониженные полномочия на своих не-рут аккаунтах, и повышают их с помощью su. Это не так. По факту у них подразумеваются рут-полномочия, но для правильного (добровольного) учёта логинов, а так же для небольшого осложнения жизни подбирателям паролей (если логин по паролю) они логинятся не сразу под рутом, а сначала представляются системе под своим персональным идентификатором. В такой схеме su описанного вреда не наносит.

Он просто не учёл все аспекты, а так логика понятна: если считать что разделение на аккаунты делается исключительно ради разделения уровней доступа, то рут действительно выше всех остальных аккаунтов в той же системе и не должен быть для них доступен. А вот аккаунт в другой системе, пусть и юзерский, может иметь более высокий уровень доступа чем рут на сервере, поэтому он к серверному руту обратиться может.

Повторюсь, эта логика делается в допущении (неверном), что аккаунты на сервере нужны только для разделения доступов.

su и существование root пользователя имеет или имело смысл так как для root резервировалось некоторое количество inode, дискрепторов, и место на разделе, по той же причине домашняя папка /root находится вне папки /home, тоесть пользователь root мог войти на зависшей машине и прибить программу исчерпавшую дискрепторы и тп.
С появлением ехт4 эта проблема почти исчезла. А с появлением mariadb и pg8 необходимость исчезла совсем.
Если ты на машине один единственный пользоватлель и администратор то смысла особого в sudo нету, но я всёравно многие команды вроде sudo poweroff и sudo reboot делаю без парольными, да и скрипт обновить систему для престорелого (80лет) академика сделал без парольным и вынес на доклет (чтобы долго и муторно не объяснять вводить пароль для обновы версии скайпа).
А вот при работе в организации отдельный пароль для root это зло в квадрате. Пароль должен быть один у пользователя и его должен знать только пользователь. Появился админ, добавил пользователя, уволился - удалил, в отпуск ущел перевёлся - заблокировал. Есть радиус, есть лдап оно на роутеры и на всякие dokuwiki притянется.
А говорить мамкину хакеру под давлением руководства, рутовский пароль от системы, чтобы, потом после выкачивания порнухи, и увольнения, генерировать запоминать новый, ну нафиг.

океюшки сударыня :) коль дефективна, дык не вопрос
только вот расскажи как с помощью su дозволить пользователю запуск только одной команды, к примеру, перезапуск системного демона systemctl restart aaa.service и более никаких действий с повышением прав.
в sudo это делается элементарно. а каково будет твое решение данной проблемы.

В третий наверно раз за эту тему повторю: знание рут-пароля не должно позволять делать su кому попало. Первый фильтр - это наличие юзера в группе wheel (ну или доступ к физической консоли - единственному месту, откуда должно быть можно логиниться рутом напрямую). Если юзер есть в группе wheel, то, для небольшого (очень небольшого, но всё же) повышения надёжности, имеется рут пароль.

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

Это не для того чтобы рут смог залогиниться, а чтобы syslog мог продолжать писать логи, а какой-то другой важный демон делать что-то ещё, если кто-то сожрал место на диске. Залогиниться и прибить процесс/потереть лишние файлы же можно и при диске, забитом в ноль. С дескрипторами да, они и логин испортят.

по той же причине домашняя папка /root находится вне папки /home

Нет, она там затем чтобы в аварийном режиме при неподмонтированном home у рута всё работало.

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

Это вообще непонятно к чему. Если руководство хочет чтобы ты дал кому-то админ права, то ему будет совершенно плевать, какими техническими средствами ты будешь их выдавать (рут пароль или добавление юзера в sudoers, впрочем аккаунт ему и так и так придётся создавать). Ты почему-то не первый в этой теме с подобными наивными рассуждениями.

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

С помощью sudo - тоже не надо. И в очередной раз повторю, что выдавать доступ опираясь на текстовый анализ команды (это именно то, чего делает дефективное sudo) - это фу. Не надо выдавать доступ к строке «systemctl restart aaa.service», надо выдавать доступ к действию «перезапустить сервис aaa». А юзер, обращающийся за этим перезапуском, даже знать не должен, что там внутри - systemctl, init-скрипт, отправка демону сигнала или ещё чего. Команда может выглядеть как-то так: restart-aaa, и представлять из себя например setuid-root бинарник с правами 4710 и группой allow-restart-aaa, делающий нужное действие. А того юзера соответственно надо в эту группу добавить.

Иными словами: юзер не должен «запускать что-то там с повышенными правами», он должен «обращаться к системному сервису».

Не надо выдавать доступ к строке «systemctl restart aaa.service»

Иными словами: юзер не должен «запускать что-то там с повышенными правами», он должен «обращаться к системному сервису».

Кто сказал?

Команда может выглядеть как-то так: restart-aaa, и представлять из себя например setuid-root бинарник с правами 4710 и группой allow-restart-aaa, делающий нужное действие. А того юзера соответственно надо в эту группу добавить.

На каждую команду писать по суидному бинарю?

Кто сказал?

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

На каждую команду писать по суидному бинарю?

Что за «каждая команда»? Он хочет (правда, непонятно зачем) дать одному юзеру-неадмину возможность перезапуска одного сервиса через шелл.

Приведи пример. Желательно с описанием зачем это вообще нужно.