Re: sudo ws root
Покотиленко Костик -> debian-russian@lists.debian.org @ Wed, 10 Dec 2008 19:11:28 +0200:
ПК> Скажи прямо, почему угробить сервер (вариант со взломом) - хрен с
ПК> ним, а получить пользователя на компе, который бэкапы хранит -
ПК> недопустимо?
Данные в локалке - ценнее.
ПК> Я почему-то считаю, что в рамках нормальной рабочей жизни сервера,
ПК> производить соединения сервер->куда-нибудь безопаснее, чем
ПК> от-куда-нибудь->сервер, хотя и ловлю себя на мысли, что не могу
ПК> объяснить почему.
В размышлениях о безопасности так нельзя. Интуиция у человека, который
не занимается ею несколько лет профессионально, не работает совсем. У
профессионала - работает, но хреново. Т.е. когда профессионал чует
жопой проблему, он делает стойку. Когда он не чует - он считает, что он
чего-то не заметил. А на сравнение интуиция не работает и у
профессионала.
>> >> Если "работающая" - это не оправдание усложнения, то что может быть оправданием?
>>
>> ПК> Оправдание. Только если есть несколько вариантов сделать систему
>> ПК> "работающей", почему бы не выбрать тот, который: тянет меньше
>> ПК> последствий, предрасполагает к дисциплине, потенциально менее опасен?
>>
>> Ну, для начала ты все же говорил о неоправданном _усложнении_. Впрочем,
>> sudo еще и больше предрасполагает к дисциплине, и менее опасен. Если
>> таки проанализировать всю модель угроз, а не те полтора следствия,
>> которые кто-то случайно заметил.
ПК> Давай анализировать.
>> ПК> При всём при этом sudo *может* быть более простым вариантом в
>> ПК> первоначальной настройки, если не принимать во внимание последующее
>> ПК> обслуживание.
>>
>> И в обслуживании тоже. Чтобы отобрать у человека права на конкретной
>> машине, мне достаточно вычистить его из sudoers. Если у него там su,
>> т.е. знание рутового пароля - мне надо поменять пароль и быстро сообщить
>> его всем, кому его положено знать. Если это более простой вариант, то
>> что такое более сложный?
ПК> Вопрос про su не стоит, su - это рут, на нём и ответственность. Sudo -
ПК> это недо-рут, и ответственность на нём [какая на нём ответственность?].
sudo с ALL - это рут. На нем и ответственность. Что сделано - в логе,
если не было злого умысла, как правило, можно восстановить, кто что
делал.
sudo на конкретную команду - недорут. Ответственность за факт
выполнения этой команды - на человеке, которому дано на это право (если
это робот - на авторе робота), ответственность за то, что эта команда
делает больше, чем задумано - на админе. Факт выполнения - в логе. Все
очень четко.
ПК> Давая команду под sudo, какую ответственность ты налагаешь? Боюсь,
ПК> что никакую, ибо облом держать таблицу ответственностей с галочками
ПК> напротив каждой исполняемой команды.
Таблица ответственности - ты не поверишь, все тот же файл /etc/sudoers.
Там все написано. И все действия в соответствии с оной таблицей
запротоколированы.
>> Если мне надо дать возможность (плюс-минус любому) юзеру передернуть,
>> допустим, принт-сервер, я пишу скрипт и пишу в sudoers
>>
>> %users (ALL) = NOPASSWD: /that/script
>>
>> Покажи мне более простое и не более опасное решение.
ПК> По моему проще разобраться, и сделать так чтобы не надо было
ПК> передёргивать.
Такое решение, опять же, может оказаться и более сложным, и более
опасным, и вообще велосипедом с квадратными колесами. Ну, принт-сервер
- дело такое, его может быть надо передергивать, если драйвера принтера
кривые (разобраться, говоришь? попробуй...). А вот, скажем, апач свои
конфиги перечитывает только по пинку, которого ему без рутовых
полномочий не дашь. Веб-программисту пинать апач, натурально, положено.
И положить/поднять тоже. Чем будем заменять sudo? suid-бинарником?
Велосипед с квадратными колесами типичный. Т.е. написать его без дыр
сложнее, особенно если с протоколированием, а уж информация о том, кому
что таким образом разрешено, канет в Лету немедленно, ибо отдельную
табличку ответственности тебе вести облом, а неотдельную без поллитры по
файловой системе не соберешь...
Вы все еще не хотите sudo? Тогда мы пингуем вас...
--
Artem Chuprina
RFC2822: <ran{}ran.pp.ru> Jabber: ran@jabber.ran.pp.ru
ожидания по умолчанию приводят к обломам по определению.
-- http://apraxina.livejournal.com/301026.html
Reply to: