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

веб макаке modrewrite в nginx нету и для его имитации конфиг дофига количество раз править приходится и перезапускать, есть ещё парочка фишек, я эту проблему просто решаю lxc контейнер с ssh, а он сам или я ставлю что нужно и какой версии и пущай там резвится, логи ошибки, конфиги всё в его распоряжении. Задача админа не усложнять не замедлять без причин, а сделать чтобы все и всё работа-ло-ли.

Очевидно это моя цитата.

Так ты совсем не авторитет, сорри. Ты такого тут писал, что волосы шевелились. И что mysql только на локалхостах стоит в основном, и что innodb не нужен, только myisam, что апач не нужен, докер не нужен, в общем, сильно закостенел уже.

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

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

У systemd специально для этого есть polkit, не надо ни su, ни sudo.

systemd не везде есть и работает, но посмотреть-изучить надо

Так ты совсем не авторитет, сорри

Я в курсе что для тебя это так. Но транслировать чьи-то мнения я в любом случае не собираюсь, только своё собственное.

Но я не сторонник подхода «наворотить нереальной безопасности и в идеале совсем отбрехаться от задачи»

Я то тут при чём?

и писать велосипеды при наличии промышленного решения.

Если так называемое промышленное решение не выдерживает никакой критики то пользоваться им не надо.

Так а пример то будет? Про «на каждую команду». Ты, как я понимаю, считаешь, что где-то будет очень много таких «команд» и из-за этого придётся делать очень много суидных бинарей и это плохо.

Если так называемое промышленное решение не выдерживает никакой критики то пользоваться им не надо.

Это всего-лишь твои слова, доверху полные когнитивных искажений.

Я то тут при чём?

Так ты, судя по всему, сторонник :)

Так а пример то будет?

Скажем так, есть девелоперские сервера, где нужно выполнять по 2-3 команды на девелопера с привилегиями суперпользователя. Девелоперов много. sudo - промышленное решение, настраивается хорошо, за безопасностью следят.

Ты же предлагаешь навелосипедить суидных бинарей.

Это всего-лишь твои слова, доверху полные когнитивных искажений.

Тут всё чьи-то слова. И, повторюсь, я не считаю чьи-то чужие слова лучше моих. Надо не на авторство смотреть а не содержание.

Что за команды то, пример? А то опять общие слова. Допустим, четырёх девелоперов с их разными командами по 2-3 на каждого придумаешь?

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

Solar Designer как то, 20 лет назад, писал, почему в OWL нет sudo: https://www.openwall.com/lists/owl-users/2004/10/20/6. Врочем, по su он там тоже проехался. Но, если что, я не сторонник не иметь возможности установить и использовать sudo. То есть сам пользуюсь.

И, повторюсь, я не считаю чьи-то чужие слова лучше моих.

Зато я считаю.

Надо не на авторство смотреть а не содержание.

Естественно.

придумаешь

А, понятно, лесом уходишь.

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

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

Насколько я понял, sudo и безрутовость нужны для явной аутентификации пользователя.

В случае, если в системе есть root - то это значит, что под ним могут работать все, кто знает пароль рута. Это может быть, к примеру, и начальник, и админ и подмастерье. И в случае косяка определить кто что сделал не представляется возможным: кто-то зашел под рутом и наворотил дел.

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

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

Вот вообще не смешно.

С появлением ехт4 эта проблема почти исчезла. А с появлением mariadb и pg8 необходимость исчезла совсем.

Каким образом появление новых версий субд могли повлиять на «внезапное» исчезновение проблем?

да, sudo сливает все примененные команды в сислог.
какой пользователь запустил, под каким пользователем исполнялось и т.д.

да я не против альтернатив. больше вариантов - больше выбора.
представь команду альтернативную простому примеру представленному раньше sudo systemctl restart aaa.service

firkax прикладной пример: веб-макаке нужен доступ на перезагрузку веб-сервера, запущенного в системном systemd.
звонить и каждый раз просить сисадмина ?? ни один сисадмин не выдержит, да и не интересны ему такие мелочи.

dместо самодельного setuid-бинарника restart-aaa это извините тоже бааальшая дырка в безопасности, простенький скрипт содержащий sudo systemctl estart aaa.service.
вместо самописного костыля проверенный десятилетиями код sudo.

принцип «KISS - сделай это проще, тупица !!» в своей красе.

представь команду альтернативную простому примеру представленному раньше sudo systemctl restart aaa.service

system restart aaa.service

Каким образом появление новых версий субд могли повлиять на «внезапное» исчезновение проблем?

добавление опций и автоопределение сколько файлов-дискрепторов сервер могёт ещё открыть.

linux как то изначально на дискрепторах не экономил в отличие от freebsd, к примеру вызов fork все дискрепторы дублировал в отличие от bsd, в результате в freebsd дискрепторов и буферов под них гораздо меньше.

PermitRootLogin, очевидно

Ой, прости, сирвира жы в аблаках толька бывают. И они все без IP-KVM. А среди отдела ИТ разделять зоны ответственности… кто таким вообще занимается?

Да, ограничение в sshd спасёт отца русской демократии. Ты прав.

ему знать не надо.

Позволь специалист не будет делегировать безграмотному регистранту с лора, что ему нужно, а что не нужно знать?

Не продемонстрируешь, как ограничить доступ к /usr/bin/systemctl? Так, раз уж мы заговорили про 1С, чтобы, тот же ras для неё, можно было запустить/остановить, а остальные юниты — нет.

Ты и про группы не знал?

Пока что незнание предмета демонстрируешь ты.

У вебиста доступ должен быть только

Кому должен и чем этот долг подтвердить можешь?

Ты же видимо описываешь традиции шаред хостингов с фтп и бардаком.

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

максимум к нескольким кнопкам их публикации

Понятно всё. За сервис от которого бизнес зависит ни разу не отвечал, но насмотрелся на тытрубе «как у больших автоматизировано всё». Ну, живи в мире розовых поней и отсутствия багов, как в твоём продукте, так и в тех, на чём CI/CD построен.

вообще может и дополнительные действия содержать, такие как перегенерация каких-нить кешей или релоады демонов например

Если у него на это право есть, значит в каталоге это право для него описано. А раз описано, какая тебе, собаке, разница нажмёт он кнопочку в гуе или по ssh зайдёт и выполнит команду?

По никам не знаю, но тут надо ещё членов команды Базальта кастовать… я фантазии на тему «sudo небезопасно, надо su» слышал только от них. Ну и от некоторых индивидов в этом топике.

Столяров, конечно, много правильного говорит, но конкретно тут у него с логикой проблема:

Если удалённый доступ, то ssh root@remote-host, только следует при этом понимать, что тот аккаунт, под которым вы работаете на своей рабочей станции и из-под которого делаете этот вот ssh root@somewhere, охранять надо аки зеницу ока, уж во всяком случае браузеры под ним гонять нельзя совершенно точно.

Если скомпрометирована локальная учётка, то разницы ssh user@remote -c "ssh root@localhost" и ssh root@remote никакой нет. У тебя, что ввод с клавиатуры увели, что ключ использованный перехватили.
Если локальная не скомпрометирована, то откуда у злоумышленника доступ к удалённой? Если он тебе «туда» подложил что-то, то та машина уже скомпрометирована, и там уже всё сломано, что хотели сломать, это раз, а два — если под тобой что-то делали, ты, хотя бы косвенно, или по логам sudo сможешь понять что было что-то без тебя. А вот если вы всей командой под рутом ходите, то следить за этим сложно. «ласт логин тогда-то я не делал, наверное, коллега», «эти команды я не вводил — наверное, коллега». Да и под рутом все следы замести легче, чем если у тебя тольо sudo/pkexec есть.

Правильная система — где рутовый шел открыть не может ни кто и никогда, кроме как для rescue mode. Надо 10 команд «от рута» выполнить — делай 10 раз $ sudo …. Естественно, никакого ALL=(ALL:ALL) ALL в sudoers быть не должно.

нееее, не про вариант системного менджера :) а про вариант повышения прав для управления системными демонами через э-э-э-э тобой указанный полкит

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

Я там где прям безопасник только бумажки перекладываю 😁

Если вкратце по нашим онтопичным машинам: су и судо есть но при этом настроен мандатный доступ и стоит спецсофт - особо левое не запустишь, запустишь так не заработает + увидят и зададут вопрос) Плюсом - именно эти машины у нас никак не соединены с публичными сетями.

Насчет сервисов, которые наружу для людей торчат - не уверен на все сто, у нас за последние 3 года почти всё внешнее ушло от наших админов. Знаю что веб администрируется из внутренней сети - то есть для людей на белом ip ничего кроме 80 и 443 не открыто.

Насколько могу судить - очень многое в этой сфере решается организационно, а не только программно.

Интересно какой аудит применяется к sudo.

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

Если тебе надо запустить команду от другого пользователя, не являясь рутом, тебе нужен sudo / doas / run0. Ну или ssh root@localhost.

Речь о том, что в принципе такая задача это задача из разряда «как организовать пронос сумок мимо охраны, не показывая им пропуск». Понятно, что это самый простой способ решить поставленную задачу, но не обязательно правильный с точки зрения безопасности и прочего. Правильный способ это подход systemd, где имеется запущенный от рута процесс, принимающий запросы от пользователя, авторизующий эти запросы и выполняющий. А может и без рута можно обойтись, рут на самом деле нужен для очень малого числа задач.

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

а чем занимается su тоже делает текстовый анализ /etc/passwd и прочих текстовых файлов.

хочу подробнее про мандатный доступ. Ссылку литературу почитать?

левое не запустишь

бинарники подписаны? башь скрипты? поделки на питоне?

если зреть в корень то без разницы :), просто связь с пользователем разная: у sudo stdout/stdin, а у системд так понимаю файловый сокет (??), ну и ssh с ssh-соединением.
процессы исполнители работают от root.
да, можно исполнителей запустить и не под root.

sudo это экзешник с suid. Это очень большая ответственность - держать такой экзешник в системе. Многие баги в sudo превращаются в таких условиях в уязвимость. Если такой экзешник можно не держать в системе, лучше не держать.

При этом sudo сама по себе очень сложная программа и грузит много разных библиотек, т.е. пассаж про баги распространяется и на них.

ssh и systemd из системы убрать не получится, поэтому это обсуждать смысла нет.

su тоже вызывает неограниченное количество библиотек из PAM, поэтому в системе PAM лучше не держать.

ssh и systemd из системы убрать не получится, поэтому это обсуждать смысла нет.

В Docker контейнерах systemd и ssh нету.

su подключается к pam, а дальше происходит непонятно что, скоро /etc/{passwd,shadow} будет заменен на passwdctl, Linux Is No UniX

sudo это экзешник с suid.

Что такое «экзешник» ?

su подключается к pam

А если pam отсутствует то работать не будет?

Тогда не запустится вовсе.

executable file

программа иными словами

su подключается к pam

А если pam отсутствует то работать не будет?

Тогда не запустится вовсе.

Очень смешно. И как же оно у меня столько лет (18 точно) работало? Наверное чудеса.

#!/bin/sh
echo "я не программа что ли?"

Это программа?
А:

#include <stdio.h>
int main(int argc, char * argv[])
{
  printf("Hello LOR\n");
  return 0;
} 

Удивлю, есть разные реализации, из какого пакета твоя? Обычно используют из util-linux, я говорил про нее.

Не очень понимаю, к чему этот вопрос? Если про то, что в линуксе не работает suid бит на скриптах, я в курсе, но какое это отношение имеет к дискуссии - не понимаю.

скомпилированый бинарник, теперь только упакованый в elf формат, раньше были и не упакованые

в скрипт можно упаковать /usr/bin/apt update;/usr/bin/apt -y upgrade и через sudo выполнять такое, а с suid придётся писать и компилировать бинарник.

если бы polkit еще умел брать правила из ldap. пару лет назад рассматривали его как замену sudo, но без ldap грустно

Удивлю, есть разные реализации

Та шо ви говорите...

из какого пакета твоя?

shadow

Обычно используют из util-linux

«Обычно» это где? На «Обычной» планете? Вот например у меня в util-linux её нет, я что-то делаю не так?

То есть, все знают рутой пароль.

Я вам задал вроде бы простой вопрос «Что такое «экзешник» ?» Вы ответили «программа иными словами». Вот теперь я пытаюсь понять что такое «программа» в вашем понимании.

Точно. На машины ходить по ssh ТОЛЬКО по ключу, на машинах получать sudo по паролю.

скомпилированый бинарник, теперь только упакованый в elf формат, раньше были и не упакованые

Тоесть например libz.so.1.2.8 это «экзешник» ?

То есть, все знают рутой пароль.

Ну смотря какой сервер и сколько там админов.
Что там всем делать то. Админ пароль и знает.

библиотека .so это elf формат так что биарник, я вот только не знаю на неё действует ли suid бит?

работу бита suid на скриптах я так предполагаю можно включить патчем файла binfmt_script.c который определяет исполнение файла начинающегося с #!
но почему-то такая возможность исключена. интересно почему, дыра в безопасности ?? :)

также там определены какие файлы являются исполняемыми для ядра линукса.