LINUX.ORG.RU
ФорумAdmin

Странности в правах процессов

 ,


0

1

Давно админю Linux, но только когда решил закрыть доступ к /etc для other, то обнаружил такую странную вещь: есть программы, которые при запуске переводят свой процесс в изолированный определённым пользователем и группой. Что я имею ввиду: например если от пользователя root выполнить sudo, то при закрытом доступе к /etc для other - комманда sudo сообщит: sudo: unable to stat /etc/sudoers: Permission denied sudo: no valid sudoers sources found, quitting sudo: unable to initialize policy plugin Так вот если на /etc назначить пользователя daemon, то sudo выполнится без проблем, видимо внутри sudo происходит переключение на daemon. А теперь внимание: если на /etc назначить пользователя root и группу daemon2, далее пользователя daemon добавить в группу daemon2, то sudo сообщит: sudo: unable to stat /etc/sudoers: Permission denied ... То есть sudo без разницы в каких группах находится daemon, хоть в той, которая имеет доступ к /etc... То же самое происходит, если на /etc/ назначить группу daemon, при том, что пользователь daemon включён в группу daemon по умолчанию. Я обнаружил, что sudo выполняется от имени daemon и группы plugdev. Подозреваю, что из-за определения группы plugdev блокируются все другие группы. Вопрос к знатокам этого форума: объясните что это всё такое? Где такая работа прав описана в документации по Linux?

Такую же ситуацию я обнаружил с демоном exim4. Он запускает свой основной процесс от root, а потом создаёт несколько процессов от Debian-exim:Debian-exim, которые так-же не могут получить доступ к /etc при том, что на /etc назначена группа daemon2 и пользователь Debian-exim добавлен в эту группу. Получается для Debian-exim группы daemon2 как бы не существует.

Где такая работа прав описана в документации по Linux?

В исходниках конкретного софта, а так же glibc.

Вообще не совсем понятно что именно ты хочешь получить, и главное - зачем. С тем же успехом можно пробовать отобрать у всех доступ на / и жаловаться, что «почему-то» ничего не работает.

Deleted ()
Ответ на: комментарий от Deleted

Вообще не совсем понятно что именно ты хочешь получить, и главное - зачем.

Объясните мне, почему когда процесс запущен от Debian-exim:Debian-exim, то он не имеет доступа к дирректории к которой иметь доступ должен по причине того, что Debian-exim входит в группу, которая назначена этой дирректории? Ответте на такой простой вопрос.

rkm543 ()
Ответ на: комментарий от rkm543

Ответте на такой простой вопрос.

Вопрос на самом деле не простой. Потому что я не телепат и я не знаю, какие именно права на директории и файлы ты поставил, и как именно на это отреагировал exim.

Deleted ()
Ответ на: комментарий от rkm543
$ ls -ld test
drwxr-x--- 2 root test 4096 июн 17 14:55 test

$ sudo -u Debian-exim ls test
ls: невозможно открыть каталог test: Отказано в доступе

$ sudo gpasswd -a Debian-exim test
Добавление пользователя Debian-exim в группу test

$ sudo -u Debian-exim ls test
hello

разбирайся, может что-то не так сделал. смотри strace'ом например за процессом exim'а.

mos ★★☆☆☆ ()
Ответ на: комментарий от Deleted

ну про exim сложно рассказать, проще на примере sudo. Попробуй /etc отключить права для other. Потом под рутом попробуй sudo. Он скажет: unable to stat /etc/sudoers: Permission denied... Я искал методом перебора пользователя и группу с которыми sudo получит доступ к /etc. Оказалось что это daemon:plugdev. Далее я на /etc назначил группу daemon2, дал daemon2 все права на /etc и пользователя daemon добавил в группу daemon2. Что вы думаете, что sudo запустился? Нет. Он снова не получил доступа к /etc. Вот кое-что нашёл: http://www.opennet.ru/cgi-bin/opennet/man.cgi?topic=setgroups&category=2 Если я правильно понял, то в программе можно этим функциями отбрасывать дополнительные группы. Поправьте меня, если это не так.

rkm543 ()
Ответ на: комментарий от mos

разбирайся, может что-то не так сделал. смотри strace'ом например за процессом exim'а.

Так-то будет работать. Всё удивительное происходит в самом sudo, видимо в нём создаётся процесс с правами daemon:plugdev и этот процесс пытается прочитать настройки в /etc. То есть эту ситуацию в bash неимитировать, это надо на СИ писать тестовую прогу.

rkm543 ()
Ответ на: комментарий от rkm543

не понял откуда это всё.

вот, то что описано в ОП

# ls -ld /etc/
drwxr-xr-x 169 root root 12288 июн 17 15:06 /etc/

# chmod o-rx /etc/

# sudo ls /
bin   etc <...>

итого, при убирании прав для ohter на /etc, sudo не подает никаких признаков возмущения.

$ lsb_release -ds

Debian GNU/Linux unstable (sid)

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

вообще, опять же непонятно, что в этом странного - это наоборот, испокон веков так и очень даже естественно. куча юзеров и групп заводится пакетными менеджерами при установке некоторых прог, которым ничего не принадлежит и смысл существования которых как раз в этом. ясен пень, если ты закроешь доступ для other на тот же /etc то всё перестанет работать. представь себе даже твой браузер будет не рад. да и остальные программы, запущенные из-под юзера.

mos ★★☆☆☆ ()
Ответ на: комментарий от mos

а с судо (тем более еще из-под рута) ничего как видим не приключается. проблема скорее всего локальная. хотя основная проблема твоего странного вопроса имхо в том, что ты сделал глобальное изменение и недоумеваешь по поводу локальных реакций на него. кто знает как у тебя всё остальное настроено - можно и sudo заставить офигевать от отбора прав у /etc, было бы желание

mos ★★☆☆☆ ()
Ответ на: комментарий от rkm543

смотри strace'ом например за процессом exim'а.

Попробовал strace, к сожалению в нём недостаточно информации, либо я не умею читать его лог. Видно что sudo инициализирует sudoers подсистему, но потом сразу ошибка. От какого имя:группа он всё делает - не видно.

rkm543 ()

может дело в suid/sgid на sudo?

teod0r ★★★★★ ()
Ответ на: комментарий от mos

итого, при убирании прав для ohter на /etc, sudo не подает никаких признаков возмущения.

Надо для /etc изменить группу с root на любую другую, тогда будет сообщение.

rkm543 ()
Ответ на: комментарий от teod0r

может дело в suid/sgid на sudo?

По умолчанию suid включен, пробовал играться с suid/sgid - безрезультатно.

rkm543 ()
Ответ на: комментарий от mos

а с судо (тем более еще из-под рута) ничего как видим не приключается. проблема скорее всего локальная. хотя основная проблема твоего странного вопроса имхо в том, что ты сделал глобальное изменение и недоумеваешь по поводу локальных реакций на него. кто знает как у тебя всё остальное настроено - можно и sudo заставить офигевать от отбора прав у /etc, было бы желание

Выше написал как заставить его выводить ошибку. По поводу вообще, то я уже вернул безопасность к исходному виду - всё так же.

rkm543 ()
Ответ на: комментарий от mos

Программа sudo запускается от root, при этом дальше работает от daemon:plugdev и одновременно работает от дополнительных групп пользователя root, но при этом права самого пользователя root недоступны. По этому решение для sudo такое: добавить root в группу которая назначена на /etc, далее обязательно перезапустить всю сессию ssh, так-как даже после рестарта bash в groups группы не появляется. После перезапуска сессии sudo работает как надо - через группу daemon2.

rkm543 ()

решил закрыть доступ к /etc для other

зачем? делать нечего?

А sudo выполняется от root. man suid bit

drBatty ★★ ()
Ответ на: комментарий от drBatty

А sudo выполняется от root. man suid bit

оказалось не всё так просто, это решено, теперь пытаюсь понять что нужно для exim4.

rkm543 ()
Ответ на: комментарий от rkm543

в слаке всё именно просто. Но часто есть ещё и PAM…

теперь пытаюсь понять что нужно для exim4.

для начала ему надо, что-бы одмин прекратил заниматься х-й. Каталог /etc/ должен иметь общий доступ на чтение для ВСЕЙ системы, ибо там хранятся ВСЕ настройки этой самой системы. То, что ты делаешь, напоминает ночной горшок с ручкой внутри.

drBatty ★★ ()
Ответ на: комментарий от rkm543

так не честно: ты так и не сказал, зачем тебе запрещать доступ к /etc/ ?

drBatty ★★ ()
Ответ на: комментарий от rkm543

Не хочу, чтобы юзеры видели настройки сервера.

ты делишь на ноль. Шелл должен их и видеть и не видеть одновременно. Не хочешь так? Тогда не давай шелл, или дай особый шелл (например апач выше докрута ничего не видит. Proftpd тоже можно так настроить, я так и делаю).

Впрочем, могу дать идею: запрети ЧТЕНИЕ каталогов. А секретный конфиг называй типа «471e997ce8c23ad558c2935b88814ab3». Тогда демон сможет увидеть и прочитать конфиг 471e997ce8c23ad558c2935b88814ab3, а вот юзер не сможет, ибо списка нет (права 0711).

drBatty ★★ ()

Что я имею ввиду: например если от пользователя root выполнить sudo, то при закрытом доступе к /etc для other - комманда sudo сообщит: sudo: unable to stat /etc/sudoers: Permission denied sudo: no valid sudoers sources found, quitting sudo: unable to initialize policy plugin Так вот если на /etc назначить пользователя daemon, то sudo выполнится без проблем, видимо внутри sudo происходит переключение на daemon. А теперь внимание: если на /etc назначить пользователя root и группу daemon2, далее пользователя daemon добавить в группу daemon2, то sudo сообщит: sudo: unable to stat /etc/sudoers: Permission denied ... То есть sudo без разницы в каких группах находится daemon, хоть в той, которая имеет доступ к /etc... То же самое происходит, если на /etc/ назначить группу daemon, при том, что пользователь daemon включён в группу daemon по умолчанию. Я обнаружил, что sudo выполняется от имени daemon и группы plugdev. Подозреваю, что из-за определения группы plugdev блокируются все другие группы.

Вопрос к знатокам этого форума: объясните что это всё такое?

слишком много свободного времени :-P

Komintern ★★★★★ ()
Ответ на: комментарий от rkm543

Не хочу, чтобы юзеры видели настройки сервера.

Про chroot и контейнеры в ваших краях еще не слышали?

geekless ★★ ()

Просто из опыта администрирования тачек в датацентре - закручивание гаек клиентами в большинстве случаев приводило к реинсталлу.

Лучше ты определись что именно ты скрываешь (только не «хочу скрыть всё»). Возможно, твоя проблема может быть решена меньшей кровью. На крайняк разнеси клиентов по виртуалкам.

true_admin ★★★★★ ()
Ответ на: комментарий от true_admin

Просто из опыта администрирования тачек в датацентре - закручивание гаек клиентами в большинстве случаев приводило к реинсталлу.

правило 95%.

drBatty ★★ ()

Сдается мне вам нужен MAC, а не те костыли, которые вы городите

Pinkbyte ★★★★★ ()
Ответ на: комментарий от Komintern

слишком много свободного времени :-P

в точку. Время кончилось, по этому проблему законсервировал в состоянии когда чувствую что продвинулся на несколько шагов вперёд в знании линукса.

rkm543 ()
Ответ на: комментарий от Pinkbyte

Сдается мне вам нужен MAC, а не те костыли, которые вы городите

крутая вещица, буду помнить

rkm543 ()

Итак, в чём я там продвинулся: запуская exim4 коммандой /sbin/start-stop-daemon --start --exec /usr/sbin/exim4 — -bd -d+all -q30m видно, как он легко меняет uid:gid процессов, при этом обнуляя auxiliary group list, то есть именно тот список, который я так упорно пытался настроить. Взглянув на конфигуратор исходников exim4 я нашёл целую кучу переменных отвечающих за то от какого uid:gid будут те или иные действия. Поразмыслив о том, что движение от дебиан сборки exim к кастомной сборке exim это движение вперёд, это прогресс, это возможности тонкой настройки - я решил собрать exim. За час собрал, но потом не смог его настроить так, чтобы он пересылал исходящую с него почту на внешний smtp. На этом и остановился. Проблему с правами считаю решёной - кроме всяких битов на исполняемые файлы, бывают ещё манипуляции в самом исполняемом файле, которые в полноте могут знать лишь линукс-программисты. Задачу сделать закрытой для юзеров /etc считаю выполнимой, просто для её завершения нужно намного больше времени, но сейчас в принципе всё бы было хорошо, если бы не exim4, задача то уже была вот-вот завершённая: mysql, apache, bind9, иксы и т.д. и т.п. уже работали при полностью закрытом /etc и ряде других системных дирректорий. Задачу законсервировал, /etc открытый, юзеры в песочнице, отложу решение до следующей встречи с проблемой. А сейчас и правда пора работать.

rkm543 ()
Ответ на: комментарий от rkm543

Задачу сделать закрытой для юзеров /etc считаю выполнимой

и как интересно тот же bash, запущенный от пользователя, будет читать /etc/passwd? это необходимо.

Komintern ★★★★★ ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.