Чем страшна команда sudo?

НИКОГДА! не надо давать возможность юзерам получать серьезный доступ к системе.

Админы усложняют жизнь себе и другим. Можно создать группу, и юзеров сунуть в эту группу. Дать им возможность выполнять определенные команды через sudo.

Админы люди не особо разговорчивые и с комплексами в основном. Ты убеди начальство в своей правоте и админам надают по рогам. =)

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

по теме: man изменение идентификаторов пользователя и группы

#include <unistd.h>

int setuid(uid_t uid);
int setgid(gid_t gid);

и man как работает тот самый man :)

PS это если я правильно понял о чём Вы спрашиваете

и да, систему ставить всё равно под sudo придётся, но тут уж если одмины быка включат - по рогам им, потому как инсталлировать софт под sudo - это нормально

О серьёзном доступе речи не идёт. Более того, речь идёт о том, чтобы дать возможность пользователю, от имени которого работает агент, запускать ограниченный набор команд он имени ограниченного набора пользователей, через sudo. И всё.

Набор команд относится к выполнению ресурсоёмких задач на высокопроизводительных ресурсах.

О серьёзном доступе речи не идёт.

root - это достаточно серьёзно, серьёзнее некуда :)

Что вы имеете в виду - про root? Команда sudo будет вызываться не root пользователем, выполнять другие команды тоже не для root.

Что вы имеете в виду - про root?

ровно вот это:

Команда sudo будет вызываться не root пользователем

выполнение sudo означает что пользователь получит привилегии суперпользователя (root), пусть это и кратковременно, но не есть гуд

>выполнение sudo означает что пользователь получит привилегии суперпользователя (root), пусть это и кратковременно, но не есть гуд

man sudo

/-u

выполнение sudo означает что пользователь получит привилегии суперпользователя (root), пусть это и кратковременно, но не есть гуд

имелось ввиду через судо выполнять программы от имени нужного пользователя

 -u user     The -u (user) option causes sudo to run the specified command as a user other than root.

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

Костыли используются потому, что: на ресурсе постоянно крутится одна программа, запущенная от имени выделенного пользователя - программа агент. Агент получает указание от сервера - запустить на ресурсе задачу от имени такого-то пользователя. Запуск от имени такого пользователя, потому что потом система биллинга выставит счёт за использование ресурса именно этому пользователю. Но сам пользователь никуда не заходит. Он запустит на сервере свой комплексный эксперимент.

имелось ввиду через судо выполнять программы от имени нужного пользователя

эм да, не все буквы в серёдке осилил :)

sudo + автомонтирование флэшек есть
осталось дело за малых монтировать без noexec и собственно придумать автозапуск всего найденого на ней %)

sudo + автомонтирование флэшек есть осталось дело за малых монтировать без noexec и собственно придумать автозапуск всего найденого на ней %)

Это вы про бубунту?

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

Ну, а на рабочем компьютере - да, в целях безопасности лучше su -c. Тогда желающему что-то взломать придется узнавать два пароля.

имхо sudo == дыра! просто воритища!

Дыра, если неправильно настроена. Но если никому не позволять ALL=ALL и указывать полные пути (чтобы не подменили на свое что-нибудь) все будет ОК.

зачем настраивать ещё и ненужный велосипед?

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

Немного удивлен, судя по всему проект серьезный, а аргументы на уровне «кривая архитектура», «дыра» и т.д. Вам дали какие-то конкретные факты, почему использование sudo недопустимо?

В том то и дело, что аргументов не было. Сначала они просто посмеялись над нами, мол вы всё со своим sudo? Не будет этого и всё тут.

Аргументы были только из разряда: ресурсы также используются серьёзными промышленными предприятиями в коммерческих целях и они по договору должны быть в курсе любых подобных изменений в настройках ОС. И они (админы) дескать не знают, как они это будут объяснять таким партнёрам.

Мы не можем себе пока уяснить - чем плохо использование sudo и какие могут быть ещё варианты. Проблема в том, что мы, разработчики системы, не являемся профи или экспертами в области Linux. Со своей колокольни проблем не видим. Вот поэтому и спрашиваю. Параллельно ищу эксперта, который бы дал свою оценку.

А заюзать policykit никак?

Вот тезисы, которые нужно обсудить с админами, которые выступают против судо:

1) Программа агент должна порождать процесс, меняя свой uid на нужный и запускать задачу на выполнение.

2) агент запускается не под рутом. 3) для смены uid нужны права рута.

sudo - реальное решение, достаточно безопасное. Другие решения могут быть даже большими костылями.

Либо всю задачу ставить иначе (переделывать систему).

>Админы усложняют жизнь себе и другим.

ну должны же они хоть как-то оправдывать свою зарплату :)

Только не забудьте, чтобы перечень команд для sudoer'ов не содержал шеллы и программы, из которых можно вывалиться в шелл (vim, например).

Позиция админов как раз понятна.

sudo придется настраивать и поддерживать им. Им же надо будет следить, чтобы ваш агент не получил дополнительных прав. Для них это потенциальный гемор, который будет вылезать каждый раз при обновлении вашего софта.

К тому же, если организация серьезная, то ко всем бизнес-приложениям, требующим повышенных прав, проявляется пристальное внимание. Это заполнение специальных форм, продумывание compensating controls, и т.д.

Конечно же они хотят, чтобы вы сделали все сами и обошлись стандартными правами.

При этом наш сервер будет иметь сертификаты пользователей, чтобы коннектиться к ресурсам от их имени.

Лучше не иметь ключи пользователей, а положить каждому пользователю в ~/.ssh/authorized_keys ваш public-ключ агента.

А почему этого нельзя сделать без sudo?

Чего этого? Запускать задачу от имени какого-либо пользователя? Потому что агент работает не под рутом и setuid он делать поэтому не может. Как иначе можно запустить процесс от имени другого пользователя? Без sudo?

>Потому что агент работает не под рутом и setuid он делать поэтому не может. Как иначе можно запустить процесс от имени другого пользователя? Без sudo?

Ну, например, запускать агента как оболочку у нужного пользователя. Типа пользователь логинится на центральный сервер, а тот уже от имени пользователя авторизуется на считающей машине, запускает ему шеллом агента, а тот в свою очередь запускает считающие программы. Через pam такое можно сделать и это не будет такой дырой в системе безопасности, если софт на центральном сервере и агент грамотно написаны.

Работа системы несколько сложнее, чем просто постановка задач на ресурсах. Для одного эксперимента используется множество ресурсов. Соответственно агенты с разных ресурсов обмениваются друг с другом данными. Используется специальный протокол p2p для обмена данными и командами.

Когда на ресурсе работает лишь один агент, то всё проще. Нужно открыть ему на ресурсе и на файерволе один порт. В плане безопасности используется TSL, соответственно каждому агенту выдаётся свой сертификат X.509. Администрирование, мониторинг, обновление, поддержка одного агента, как одного процесса, гораздо проще, нежели если для каждого пользователя будет запускаться свой агент, на своих портах, читать общие настройки, писать свои логи и т.д.

Предложенный вариант мы уже рассматривали и отмели, как сложную в разработке, тяжёлую в поддержке и неудобную в развитии архитектуру.

А можно подробнее объяснить, почему вы считаете, что при текущем подходе есть «такая дыра в системе безопасности»? Ведь sudo будет выполнять только агент, ПО, к которому априори есть определённое доверие. Выполнять эту команду он будет для ограниченного набора пользователей и команд. В чём «такая дыра»?

Буду очень благодарен за ответ.

а почему никто не сказал про выполнение через ssh + ключи? вполне себе безопасно и ненадо никаких sudo/su.

>Ведь sudo будет выполнять только агент, ПО, к которому априори есть определённое доверие. Выполнять эту команду он будет для ограниченного набора пользователей и команд.

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

А как вы при помощи ssh ограничите для юзера root-доступ только n-ным количеством программ?

> А как вы при помощи ssh ограничите для юзера root-доступ только n-ным количеством программ?

ТС же пишет:

О серьёзном доступе речи не идёт. Более того, речь идёт о том, чтобы дать возможность пользователю, от имени которого работает агент, запускать ограниченный набор команд он имени ограниченного набора пользователей

т.е. от рута ничего запускаться не должно.

Дело в том, что при помощи ssh можно сделать

он имени ограниченного набора пользователей

Но вот с

запускать ограниченный набор команд

как быть?

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

> как быть?

если это действительно нужно - то запихнуть всех нужных пользователей в группу, например, restricted и выставить соотв. пермишены на файлах.

Но они в этом случае все равно смогут запускать все, расположенное в директориях /bin, /usr/bin и т.п.

> если для каждого пользователя будет запускаться свой агент, на своих портах, читать общие настройки, писать свои логи и т.д.

Возможен ли случай, когда при старте системы запускается демон агент (от непривилегированного пользователя) и ничего не делает, а пользователи могут к нему подключаться и выполнять действия?

Вообще на самом деле зачем нужен рут? Кроме общих логов. На нужные файлы устройств можно права дать.

> Но они в этом случае все равно смогут запускать все, расположенное в директориях /bin, /usr/bin и т.п.

вот на них и раздать пермишены. а еще есть acl.

Это вызовет бурю «радости» у «одминов организации».

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

одмины такие одмины... Я правильно понял что вместо sudo они предлагают делать ssh another@localhost «my_cool_programs arg1 ...»? :)

Да, как вариант это они тоже предлагают делать.