LINUX.ORG.RU

Можно ли сделать два вида админов?


0

1

Я бы хотел дать возможность пользователям самостоятельно устанавливать приложения без админских прав. Устанавливать приложения пользователи будут туда, куда у них хватит прав (в первом приближении в свою домашнюю директорию, см. ниже).

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

Для того, чтобы такого не происходило, во втором приближении, я хочу сделать пользователю дополнительный аккаунт, чтобы права на приложения были не такие как права у пользователя. Т.е. хочу два разных вида рутов. Один рут - совсем рут, а второй рут - не совсем рут и слегка пользователь. А третий - совсем пользователь.

Обозначим аккаунты буквами А - администратор, У - учитель, С - студент.

Можно ли настроить пользователю sudo таким образом, чтобы ему давались права на этот второй аккаунт, а не на аккаунт администратора?

Есть пять областей:

а) то, что установлено рутом для себя, и доступно руту (rw)

б) то, что установлено рутом для учителя (или учителем для себя через sudo), и доступно руту (rw) и учителю (r)

в) то, что наредактировано учителем для себя, и доступно руту (rw) и учителю (rw)

г) то, что установлено учителем для учеников (или учениками для себя через sudo), и доступно руту (rw), учителю (rw) и ученикам (r)

д) то, что ученики делают сами (rw)

Учитель не может читать файлы, установленные рутом лично руту (область «а»). И ученик не сможет читать файлы, установленные себе учителем (область «в»).

Итого, у учеников доступ к области «д» на запись, и к области «г» на чтение.

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

Нужно настроить sudo так, чтобы ученик мог ставить софт в область «г», но не мог ставить софт в область «б». К руту с учителем это, кстати, тоже относится.

Какой символ в таком случае должен использоваться в качестве подсказки bash вместо ‘#’ и ‘$’ ? Кажется, можно сделать ‘#’, ‘¤’ и ‘₽’ (первый - сидеть за решеткой, если что-то испортит, второй - обозначает универсальность, а третий - это локализованная версия доллара).

★★★★

Последнее исправление: Shushundr (всего исправлений: 9)
Ответ на: комментарий от t184256

напечатает при нем что-то, что поставит ученику произвольный софт в хомяк?

Таково право, дарованное ему админом школы. Почему бы и не поставить что попало? Виноват будет именно второй.

Только ставит учитель ученику не в хомяк. А себе в специальную директорию, доступную ученикам на чтение. По аналогии с тем как рут ставит софт не в хомяк учителю, а рядом в систему, но учителю этот софт доступен на чтение.

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

Его, негра, проблемы нас тут почти не волнуют.

безо всякого дополнительно

Меня интересует техническая возможность разграничить права между учеником и учителем по аналогии с тем, как они разграничиваются между учителем и админом.

Shushundr ★★★★
() автор топика
Последнее исправление: Shushundr (всего исправлений: 3)
Ответ на: комментарий от Shushundr

Таково право, дарованное ему админом школы

Таково право, дарованное ему физическим доступом.

Только ставит он не ученику в хомяк. А себе в специальную директорию, доступную ученикам на чтение.

Меня интересует техническая возможность разграничить права между учеником и учителем по аналогии с тем, как они разграничиваются между учителем и админом.

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

В чем теперь вопрос?

t184256 ★★★★★
()
Последнее исправление: t184256 (всего исправлений: 1)
Ответ на: комментарий от t184256

физическим доступом

Физический доступ неполный. Возможно системный блок опечатан, или вообще находится за стеной в соседней комнате.

Таким образом, учитель не сможет получить права рута. У ученика такая же проблема с правами учителя.

Несмотря на то, что ученик имеет физический доступ к клавиатуре.

учитель ставит софт сам

Учитель выполняет команды из сессии ученика, повышая привелегии (при указании пароля). Это не то же самое, что «сам», это другой вход. Вопрос в том, как это организовать. Root для этого написал программу sudo, а что написал учитель? Сможет ли он воспользоваться sudo для выполнения других целей, не таких как у рута?

Shushundr ★★★★
() автор топика
Последнее исправление: Shushundr (всего исправлений: 2)
Ответ на: комментарий от Shushundr

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

Это не то же самое, что «сам», это другой вход. Вопрос в том, как это организовать.

su учитель. sudo не при чем.

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

не относящаяся к твоей задаче #3.

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

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

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

перестань гнать пургу

su придумали, чтобы повышать привилегии от пользователя A к пользователю B при предоставлении пароля пользователя B.

sudo придумали, чтобы повышать привилегии от пользователя A к пользователю B при предоставлении пароля пользователя A.

В своём безудержном галопе по задачам ты прискакал к задаче, решением которой является su учитель, и теперь пытаешься приделать к ней sudo «чтобы было», апеллируя, как это ни комично, к «удобству». Хватит позориться.

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

sudo придумали, чтобы повышать привилегии от пользователя A к пользователю B при предоставлении пароля пользователя A.

Я бы ещё добавил, чтобы повышать их ограничено — только на определённые команды.

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

Мне нужно, чтобы ученик мог установить себе редкий софт и не испортил всю систему. Если бы sudo такое умел, всё бы у ученика получилось. Мой вопрос был в том, умеет так sudo или нет. Не обязательно раздувать три страницы флейма и ударяться в обвинения с примесью ненависти.

Возможно я где-то отклонился от исходной мысли, раз тема пришла к su. Но вопрос как был про sudo, так и остался.

Shushundr ★★★★
() автор топика
Последнее исправление: Shushundr (всего исправлений: 1)
Ответ на: комментарий от Shushundr

Не обязательно раздувать три страницы флейма

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

Мне нужно, чтобы ученик мог установить себе редкий софт

Только что софт ставил учитель и себе.

Возможно я где-то отклонился от исходной мысли

you_dont_say.png

Я бы предложил тебе создавать под новые задачи новые треды, но жалко людей.

Пытайся придумать задачу от твоего решения с sudo молча.

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

Я бы предложил тебе создавать под новые задачи новые треды

Да я и так неплохо справляюсь с созданием большого количества тредов.

Удручает, что данный конкретный тред не помог.

Shushundr ★★★★
() автор топика
Последнее исправление: Shushundr (всего исправлений: 2)
Ответ на: комментарий от t184256

софт ставил учитель и себе.

Есть пять областей:
а) то, что установлено рутом для себя, и доступно руту (rw)
б) то, что установлено рутом для учителя, и доступно руту (rw) и учителю (r)
в) то, что установлено учителем для себя, и доступно руту (rw) и учителю (rw)
г) то, что установлено учителем для учеников, и доступно руту (rw), учителю (rw) и ученикам (r)
д) то, что ученики делают сами (rw)

Ты почему-то делаешь вывод, что если учитель может установить себе программы в область «в», то у ученика тоже есть возможность использовать область «в».

Но учитель не может читать файлы, установленные рутом лично руту (область «а»). И ученик не сможет читать файлы, установленные себе учителем (область «в»).

Итого, у учеников доступ к области «д» на запись, и к области «г» на чтение.

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

Shushundr ★★★★
() автор топика
Последнее исправление: Shushundr (всего исправлений: 2)
Ответ на: комментарий от t184256

Пытайся придумать задачу от твоего решения с sudo

Нужно настроить sudo так, чтобы ученик мог ставить софт в область «г», но не мог ставить софт в область «в».

К руту с учителем это, кстати, тоже относится.

Shushundr ★★★★
() автор топика
Последнее исправление: Shushundr (всего исправлений: 1)
Ответ на: комментарий от t184256

Вижу у тебя нет слов.

Пытайся придумать задачу

Ученик не ломает софт учителя, потому что не может.

Ученик может ставить себе что попало без разрешения.

Учитель может поставить ученику что нужно, правом данным ему свыше.

Рут тоже, учитель не ломает софт руту. Учитель может ставить себе что захочет.

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

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

Shushundr ★★★★
() автор топика
Последнее исправление: Shushundr (всего исправлений: 3)

sudo тут ни при чём. Достаточно правильно настроить права на директории. Только зачем запрещать кому-то что-то запускать - непонятно, ведь запускаться всё будет с правами того, кто это запустил, и испортить сможет только себе.

Так что, просто создаёшь директорий /home/shared_progs (или /usr/shared_progs, с правами rwxr-xr-w и владельцем-учителем, он туда ставит что хочет, а остальные могут читать и запускать оттуда что угодно.

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

Он не решает почти никаких проблем, и создаёт кашу (про права доступа) в голове у тех кто им пользуется. Все его корректные применения умеет дублируют функционал программы su.

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

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

Моя схема с sudo позволит им ещё и устанавливать туда что попало. Это полезно для креативности.

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

Что значит «устанавливать»? Что, откуда? Право установить туда вирус тоже есть? Как отличишь установку вируса от невируса?

Я об этом и писал - sudo поражает мозги своих пользователей, в том числе лишает их понимания термина «барьер безопасности», совершенно обязательного к рассмотрению при планировании прав.

firkax ★★★★★
()
Последнее исправление: firkax (всего исправлений: 3)
Ответ на: комментарий от firkax

Право установить туда вирус тоже есть?

Да.

Как отличишь установку вируса от невируса?

Установку вируса проводит пользователь по собственной воле. Имеет право.

Но если он этого не делает, то сам-по-себе вирус установиться не сможет.

С root в linux в принципе такая же ситуация. Вроде бы вирусы себе мало кто ставит.

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

Но если он этого не делает, то сам-по-себе вирус установиться не сможет.

Сможет, конечно. Повторю - изучи понятие «барьера безопасности». Всякие рассуждения типа «юзер сможет, вирус не сможет» - чушь. Оперировать надо строгими понятиями (списками прав доступа для uid/gid, ограничениями chroot или контейнеров). На вирусе не написано, что он вирус, когда он занимается вредительством, он точно так же воспользуется выданными правами. И выкинь sudo.

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

понимания термина «барьер безопасности»

Барьер есть. Он состоит из ACL, в которых устанавливаемым программам прописывается владелец У(читель), а выполнение производится из под аккаунта С(тудент).

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

В Linux с root такая же история и все говорят «не сиди под рутом», как будто бы это помогает.

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

Если на руте нет барьера (рут-пароля, например) то «не сиди под рутом» помогает только от случайного повреждения системных файлов. И даже если пароль есть, но логинишься в него ты не отдельной сессией, а через su, то вирус может его украсть из терминала, когда ты будешь его писать, и дальше пользоваться.

firkax ★★★★★
()
Последнее исправление: firkax (всего исправлений: 1)
Ответ на: комментарий от Shushundr

Вирус не знает паролей и запустить sudo сам не сможет.

Вирус знает всё, что происходит в сессии пользователя. И запустить может всё, что может запустить пользователь.

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

вирус может его украсть из терминала, когда ты будешь его писать

Дануневерю. В xorg-server конечно есть косяки, но это другая проблема и тема для другого топика про Qubes OS.

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

Это не xorg, он может внедриться в gnome-terminal (или любой другой), запущеный от того же юзера. Или подставить тебе фейковое su/sudo, которое сохраняет пароль куда надо. Пойми, если от твоего uid запущен вирус, то уже ни в чём нельзя быть уверенным, вся сессия в его власти. Итоги зависят исключительно от изобретательности автора.

firkax ★★★★★
()
Последнее исправление: firkax (всего исправлений: 2)
Ответ на: комментарий от firkax

он может внедриться в gnome-terminal (или любой другой), запущеный от того же юзера.

Не может. У него нет права записи в исполняемые файлы. Потому что исполняемые файлы установлены под учётной записью У, а выполнение происходит под учётной записью С.

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

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

если от твоего uid запущен вирус, то уже ни в чём нельзя быть уверенным, вся сессия в его власти.

Аутентификация пользователя проводится до начала сессии, сессия в этот момент ещё не существует. Откуда власть-то?

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

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

Откуда оно возьмётся, если его установкой занимается админ?

Вирус его запустит вместо настоящего. Причём способов много. Например - сделать в ~/.bashrc алиас sudo = «$HOME/.virus/fake_keylogger_sudo». Или поставить в конце .bashrc запуск $HOME/.virus/fake_bash и в нём вообще творить что угодно по своим правилам. А можно не ставить, а внедриться в уже запущеный настоящий процесс баша и подредактировать ему поведение (но это если автор вируса - хакер и знает ассемблер).

firkax ★★★★★
()
Последнее исправление: firkax (всего исправлений: 2)
Ответ на: комментарий от firkax

Не неси чушь. Вот тебе реальный пример использования sudo в моей админской практике: мы отвечали на серверах за Linux, а другие люди за Docker. И мы выдавали им sudo на управление Docker и права на просмотр системных логов. Таким образом, они могли полноценно рулить своим ПО и следить за ним, но не могли сломать Linux.

И это единственный вариант поддерживать Linux, на котором крутится ПО, что требует root прав. Иначе — только передавать поддержку полностью, потому что никто в здравом уме не будет отвечать за то, что могут сделать с Linux другие.

Прекрати уже мыслить категориями админов локалхоста и мелких контор. Linux всё же для крупного энтерпрайза делается.

Vsevolod-linuxoid ★★★★★
()
Последнее исправление: Vsevolod-linuxoid (всего исправлений: 4)
Ответ на: комментарий от Vsevolod-linuxoid

1) докер не нужен как и sudo

2) ну ладно, если по производственной необходимости от него некуда деться - то выдача на него прав делается нативно его же функционалом безо всяких sudo

Но надо учитывать, что это дыра в безопасности (вне зависимости от способа выдачи прав).

не могли сломать Linux

Могли, разумеется.

Чтобы выдать права правильно - нужно было делать над докером обёртку (можно сразу suid-root чтобы два раза не делать), которая разрешала бы более-менее безопасные действия, но не давала бы создавать --privileged или --cap-add контейнеры (а может и ещё что-то, там слишком много всякого разного).

Прекрати уже мыслить категориями админов локалхоста и мелких контор. Linux всё же для крупного энтерпрайза делается.

Что за бредоярлыки?

firkax ★★★★★
()
Последнее исправление: firkax (всего исправлений: 2)
Ответ на: комментарий от firkax

выдача на него прав делается нативно его же функционалом безо всяких sudo

Я допускаю, что ошибся, просвети — как? Ты его с Podman не путаешь? Того да, можно использовать без root, одна из ключевых фич.

Могли, разумеется.

Чтобы выдать права правильно - нужно было делать над докером обёртку (можно сразу suid-root чтобы два раза не делать), которая разрешала бы более-менее безопасные действия, но не давала бы создавать –privileged или –cap-add контейнеры

Сейчас уже не помню точно, но кажется у них не было прав на все действия от Docker, только на ограниченный список команд.

Vsevolod-linuxoid ★★★★★
()
Последнее исправление: Vsevolod-linuxoid (всего исправлений: 3)
Ответ на: комментарий от Vsevolod-linuxoid

Чтобы были права на докер, достаточно иметь права на подключение к его сокету. Все его cli утилиты только отправляют команды в него, сами по себе они никаких прав не требуют. У сокета g+w права и группа docker, соответственно надо добавить юзера в эту группу, чтобы выдать ему доступ. Но, повторюсь, с точки зрения безопасности это эквивалентно выдаче полных рут-прав.

Сейчас уже не помню точно, но кажется у них не было прав на все действия от Docker, только на ограниченный список команд.

Доступ к docker run достаточен чтобы запустить привилегированный контейнер. Доступ к docker-compose - тоже (достаточно privileged: true в yaml-конфиге прописать). Так что без подробного анализа запроса (а не только регулярки по тексту командной строки) не обойтись.

firkax ★★★★★
()
Последнее исправление: firkax (всего исправлений: 3)
Ответ на: комментарий от firkax

Если можно добиться того, что проверить и сделать безопасными операции в докере, то с пакетным менеджером тоже можно что-нибудь такое сделать. Например посадить его в chroot, как выше рекомендовали. Конечно, пакетному менеджеру можно любой скрипт в виде билда скормить, но всё что там будет выполняться, будет выполняться под аккаунтом У(чителя), и не будет влиять на работу аккаунта А(администратора), потому что уж учитель-то не будет вводить свой другой пароль для sudo, и поэтому не получится его (пароль) перехватить.

Shushundr ★★★★
() автор топика
Последнее исправление: Shushundr (всего исправлений: 1)