tl;dr: логиниться под рутом на удаленный сервер, чтобы тискать демонов и срать в их конфиги — хорошо это или плохо?
______
Пстач, рассуди спор. Есть один сервер на дебиане, суды на нем по-дефолту не стоит.
И есть два человека. Одному (мне) очень комфортно редактировать конфиги, устанавливать пакеты и перезапускать демонов под рутом. Второй же сидеть под рутом как огня боится, поскольку в первой ссылке по любому запросу в гугле пишут, что так делать нельзя.
Он утверждает, что нужен ограниченный пользователь + дырявая суда. Но я, кажется, чего-то не понимаю. Какой смысл, если, блядь, sudo придется писать чуть ли не ровно перед каждой командой? Пересобрать/перезапустить нгинкс, подпилить конфиги, накатить пару пакетов, сирануть в кронтаб.. В общем почти все, кроме заливки файлов по сфтп в папку вебсервера.
И этот же человек хотел сделать себе автозаполнение пароля, потому что пароли не нужны и должны умереть, есть сохранялки пассвордов, но просто перепечатывать из них каждый раз тяжело "и вообще оно генерирует ключ/сертификат при первом входе через путти, могло бы по нему узнавать". Точность цитаты не гарантирую, но было сказано что-то такое. Он кстати уже ищет замену путти с возможностью сохранения пассворда. Замечательня мысль.
Итак, я понимаю, что если я пользователь обычного ПК, пришел за компьютер посмотреть на нянкота, послушать музыку в браузере или сделать отчет в экселе то рут мне не нужен и лучше под ним не сидеть. Но если я иду на сервер с целью поправить конфиги, передёрнуть демона или не дай бог залезть в /etc/sysctl.conf то почему бы не зайти сразу под рутом и не ебаться с судой? Если появляется возможность перехватить мой пароль для рута — что тогда мешает с тем же успехом так же перехватить пасс от юзера + пасс от суды? не понимат. Имея админский доступ к MySQL я же не дропаю все таблицы, как только зайду? Вот и $ rm -rf / под рутом писать не собираюсь.
Давай пстач, подсказывай. Я всегда думал, что sudo придумали для того, чтобы в редкие моменты необходимости установки пакетов/смены настроек, %другая причина% на домашних компиках не надо было релогиниться, а все сделать из под своей учетки
25 comments
recommend
bookmark
subscribe
Всегда так делаю, всё норм.
если открыт доступ по ssh для рута, то есть шанс что могут тупо сбрутить пароль (имя юзера еще узнать надо, а рут везде есть). и да, пароли действительно не нужны, для авторизации по ssh давно есть ключи.
Олсо, судо может больше, чем просто временный su. Он ещё может отдельные команды запускать без пароля, переключать юзеров без пароля же и т.п. вещи для безопасной автоматизации. Я вообще свой пароль на сервер в интернетах не помню, логинюсь по ключу, а если не из дома, то можно по цепочке серверов, сначала на тот, на котором я пароль помню, а с него по ключу на нужный.
denyhosts стоит для этого, порой даже меня банит
define "так". рут или суда?
Рут.
Вопрос был — «хорошо это или плохо?», логично, что «так» — это хорошо.
Зайду с другой стороны.
Самая правильная конфигурация — это такая конфигурация, где рут используется по-минимуму. Есть простое правило — никакой прикладной сервис не должен быть запущен под рутом и быть доступен руту, в крайнем случае рут запускает только корневой демон, а все остальное принадлежит юзеру специальному. Фор экзампл: конфигами и демоном нгинкса управляет юзер nginx, мускулом mysql, пыховский fsgi поднимает спец юзер fsgi и тд. При такой конфигурации рут становится почти не нужен и судо тут ой как кстати: sudo -u nginx.
А если у вас все-подряд делает рут и доступно только руту — тут судо да, только мешать будет.
На серверах все конфиги может править только рут, сервисы запускать и перезапускать — только рут. Понятно, что они после запуска дропают права до нужного юзера, но запускаются всё равно всегда под рутом. Смысл тогда логиниться под юзером, если он нихуя не может сделать в серверных условиях?
На системном уровне да, но он используется реже. На прикладном нужно грамотно раздать гранты на конфиги нужным юзерам. В хорошей конфигурации рут логан нужен.лишь для правки чего то глубоко системного, ну и старт сервисов. Хотя и последнее возможно от имени юзерам, смотря что за сервис и как работает.
А уж про ссх логан рутом я говорить даже не буду.
В дебиане по дефолту у всех конфигов владелец рут, если даже каждым конфигом будет владеть тот юзер, от которого работает конкретный сервис, это лишь добавит гемора, если же ими будет владеть обычный юзер — безопасности не прибавится практически, да и при обновлении системы придётся опять човнить всё подряд. Олсо «логан» — это что? Logun, типа как wogun?
вчера ебался с этим 2 часа. В итоге для одного нгинкса надо было открыть /var/run/nginx.pid, доступ к конфигам и к /etc/init.d/nginx как минимум. Но тут он ругнулся нга то, что скидывать процесс на другого пользователя все равно может только суперпользователь, так что хуй.
Можно конечно оставлять права у пользователя запустившего и делать твои nxginx, fcgi и mysql пригодными для логина, логиниться под каждым, чтобы запустить конкретный сервис. Ерунда какая-то
Вау, ты узнал, что установить произвольный uid/gid может только рут? Поздравляю! Лол. sudo обладает suid-битом, и именно это даёт ему возможность запускать под нужным uid'ом запускать дочерний процесс. Причём, это возможно и без авторизации, если ты в sudoers пропишешь NOPASSWD для нужных бинарей. Так что либо suid, либо sudoers, чтобы не логиниться под рутом постоянно. Решать тебе. Помни только, что suid, скорее всего, слетит после апдейта.
Это кпк слово меняет, зараза.
А никто и не говорит, что будет просто. Конфиги из пакетов всегда такие, но это еще не повод. Ограничение прикладных сервисов нужно по хорошему. Ежели запускать все от рута то любая уязвимость прикладного уровня может весьма сказаться на общей целостности системы. Да, разграничение прав требует более деликатного подхода. В вашем распоряжении стики бит, наследование прав, ацл и тд.
Алсо, в некоторых энтерпрайз осях такой подход прямо предоставлен и умолчательный.
Есть ещё SELinux и AppArmor. Может, лучше в их сторону смотреть, если уж параноить?
запускаются — да, но не вертятся под ним. Все, что относится к серверу вертится на www-data.
Или речь о том, что дыра может находиться между запуском и скидыванием пользователю?
Может, но там обычно только загрузка конфигов, а может, и она уже под юзером идёт. Не копал.
ну в целом да, вчера я в это уткнулся, на десктопе у меня питух ОС, откуда мне знать основы *nix'а
Если делать красиво и аккуратно — то делать красиво и аккуратно. Вышеперечисленное хорошо, но при бардаке больше проблем может вызвать. Была у меня как то приблуда, которой политика запрещала уид 0 для файлов, например.
Да и вопрос был про судо. Если разграничить по уму — судо ой как нужен. Ежели нет — то толку мало от него.
#oiszog/13 У нгинкса уже под юзерским uid конфиги подгружаются, например. После старта init скрипта.
На правильно настроенном сервере для администрации демонов рут не нужен, они могут запускаться от пользователя.
какой конфиг пожмакать, чтобы авторизацию по сертификату запретить?
в смысле хочу избавиться от варианта логина без пароля только по сертификату
забейте