Re: sudo ws root
Покотиленко Костик -> debian-russian@lists.debian.org @ Wed, 10 Dec 2008 10:47:01 +0200:
>> >> > Как бы админ не хитрил с таймаутами, если в sudoers разрешен ALL, то
>> >> > никакого выигрыша от неиспользования root password мы не получим.
>> >>
>> >> Получим. Если у нас имеется несколько юзеров, которым разрешено sudo
>> >> ALL, то при увольнении одного из них нужно только deluser сделать.
>> >> А если бы использовалось su, то пришлось бы менять рутовый пароль и всем
>> >> остальным админам заучивать новый.
>>
>> ПК> Народ, объясните мне пожалуйста зачем в Линуксе может понадобиться
>> ПК> временное превышение полномочий, как тут кто-то недавно сказал??? Я
>> ПК> вообще ни ситуации такой представить не могу ни смысл самого понятия не
>> ПК> могу понять. Кроме конечно того, что это такой себе мега-костыль.
>>
>> Пример. У меня есть сервер в Интернете, и машина в локальной сети,
>> которая его бэкапит. В автопилоте. Она, натурально, идет туда по ssh
>> юзером backup по ключу и запускает собственно команду бэкапа, сливающую
>> результат в этот ssh. По sudo без пароля. Ровно эту команду и никакую
>> другую.
>>
>> Предложи другой способ это сделать. Без необходимости открывать доступ
>> снаружи на бэкапящую машину и, следовательно, в локальную сеть.
>> Бэкапящая машина еще много для чего используется, и защищена она в
>> результате не в пример слабее того сервера.
ПК> Просто: бэкап на сервере делает ПО от рута в место доступное backup с
ПК> соответствующими правами. ПО на машине в локальной сети просто этот
ПК> бэкап слизывает под пользователем backup без всяких повышений
ПК> привилегий.
1. Диск на сервере не резиновый. Места под бэкапы там нет. Слова
"сливающую результат в этот ssh" в моем письме были по делу, а не для
красного словца.
2. "Обратно-инкрементные" бэкапы (то, что дает rdiff-backup или
rsnapshot) по такой схеме делать невозможно.
>> ПК> Я понимаю так, что если тебе иногда надо выполнять команды с другими
>> ПК> привилегиями - меняй привилегии с подтверждением их обладания (su), в
>> ПК> остальных случаях права правильно надо настраивать. Иначе отслеживать у
>> ПК> кого какие привилегии РЕАЛЬНО могут быть очень тяжело, эвристический
>> ПК> анализ нужен: Вася может рутом выполнять некоторые команды, Петя имеет
>> ПК> ssh доступ к Васе по ключам без пароля, пол офиса Васи иногда сидит за
>> ПК> компом Васи..., и, РЕАЛЬНО рутом выполнять некоторые команды уже может
>> ПК> пол страны.
>>
>> Похрен. Яйца отрывать будем Васе. Вместе с записями в sudoers.
>> Остальное - его проблемы.
ПК> Понятно, что ответственность лежит на Васе, но в целом такая система
ПК> *неоправданно* сложнее.
>> За моим компом пол-офиса может сидеть. Но не под моим логином. У них
>> на нем свои логины есть.
ПК> Не все такие правильные как ты.
Без использования sudo Вася либо может выполнить от рута любую команду
(и следовательно, любую команду может выполнить пол-офиса, ибо если Вася
пускает пол-офиса сидеть под своим аккаунтом, то его пароль эти
пол-офиса тоже знают), либо никакую, в том числе нужную. Такая система,
конечно, проще. Но неработоспособна.
А в нормальной системе Васе, под аккаунтом которого сидит пол-офиса,
дают sudo только на выполнение команд, на которые можно дать sudo всему
офису. То есть когда по техническим причинам привилегия нужна, а по
смыслу - нет. Причем с NOPASSWD, ибо нафига?
А остальные команды обычно покрываются ALL, и разрешаются тем людям,
которые знают, как обращаться с аккаунтом. В результате система
получается очень простая, хотя и ненулевой сложности, зато работающая.
Если "работающая" - это не оправдание усложнения, то что может быть оправданием?
--
Artem Chuprina
RFC2822: <ran{}ran.pp.ru> Jabber: ran@jabber.ran.pp.ru
Чем отличается свобода от независимости?
Независимость - это когда за тебя не платят.
А свобода - когда за тебя не думают.
Reply to: