LINUX.ORG.RU

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


0

1

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

★★★★

Последнее исправление: Shushundr (всего исправлений: 9)

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

Когда ты делаешь что-то через sudo, то ты делаешь это root. И да, если ты не дашь пользователю права sudo, а администрирование будешь выполнять отдельным пользователем с sudo или просто от root, то это повысит безопасность, по идее.

Ну а если тебе интересна изоляция приложений в пределах одного пользователя, то есть firejail, например. Или можешь вообще QubesOS поставить, там приложения разбиты на группы по виртуалкам.

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

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

Вот именно. Я бы хотел дать возможность пользователям самостоятельно устанавливать приложения без админских прав.

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

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

Она есть по умолчанию — в хомяк пусть ставят (для удобства, бинарники в ~/.local/bin). А для установки в систему нужен рут.

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

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

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

бинарники в ~/.local/bin

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

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

Тогда надо использовать sandbox. Я лично использую для всего не-опенсорсного (в основном это игры) firejail. С помощью firejail --private=/path/to/directory каждому приложению даётся свой ограниченный хомяк, а доступа в настоящий хомяк пользователя оно больше не имеет. Также по умолчанию отключен доступ в инет (--net=none) и некоторые другие возможности, которые тем или иным программам явно не нужны.

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

Что за хрень ты несешь? Ну то есть да, по умолчанию обычно sudo на всё, но это никак не мешает тебе настраивать его на ограниченный набор команд, это работает. Конечно, при этом нужно следить, чтобы не дать лишнего.

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

Конечно, при этом нужно следить, чтобы не дать лишнего.

Правильно ли я понял, что ты предлагаешь настроить sudo так. чтобы пользователь смог пользоваться системным пакетным менеджером? Это плохая идея с точки зрения безопасности, так как не будет проверки - какие именно программы будут установлены пользователем в систему. Если бы он ставил в свой хомяк это были бы его проблемы. А проблемы системы - это другое! Любопытный школьник используя такую дырень без проблем снесёт всё нахрен!

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

Если набор приложений ограничен, их можно и в основную систему поставить. Весь смысл как раз в неограниченности. Кто их, пользователей, знает?

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

Я предлагал устанавливать не в ОС. Я предлагал дать пользователю два логина (аккаунта), чтобы под одним он устанавливал, а под другим работал.

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

А под первым аккаунтом пользователя не надо программы запускать кроме пакетного менеджера.

Мне не ясно, в чём тут «принципиальная невыполнимость».

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

Интересно. Но хотелось бы обойтись минимальными (желательно встроенными) средствами.

Встроенными не получится, а firejail и так достаточно минимален. Нет, есть, конечно, ещё bwrap (bubblewrap), но он очень заморочен в использовании для обычного юзера.

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

Я предлагал устанавливать не в ОС. Я предлагал дать пользователю два логина (аккаунта), чтобы под одним он устанавливал, а под другим работал.

Если пользователь (физически/биологически) при этом один, это никак не решает проблему, а лишь усложняет её. Всё равно он установит что хочешь и запустит что хочешь. Потому что друг от друга приложения никак в этом случае не изолированы. Это придётся по юзеру на каждое приложение делать, то есть по сути переизобретать sandbox’инг, но только на уровне ФС (без всего остального).

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

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

Если бы всё было так, как ты говоришь, то в Linux не делили бы пользователя UID=1000 и ROOT.

Но делят. Наверное это полезно.

Всё равно он установит что хочешь и запустит что хочешь.

Но это запущенное будет иметь другую степень доверия, по сравнению с целым пользователем. И уж тем более по сравнению с админом.

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

UID=1000 не имеет доступа к файлам вне своего хомяка (ну и /tmp и т.п. до кучи). То, что sudo по умолчанию настроено так, что юзер может получить этот доступ, сделано для удобства (причём в первую очередь на десктопе), и предполагается, что пользователю доверяется безоговорочно, и он сам будет следить за тем, чтобы не понаустанавливать малвари. В твоём случае у нас этого допущения нет. Далее, в этом случае данные программ пишутся в хомяк пользователя, а не в систему. В случае с непонятным рандомным софтом, этот самый софт нередко любит писать туда, куда сам установлен (игры порой так делают), что добавляет проблем такой реализации.

Нет, можно конечно сделать так, чтобы от одного пользователя программы ставились в хомяк этого пользователя, другой пользователь имел доступ к этому другому хомяку только на чтение, и так запускал. Только вот приложения эти, «юзерские» всё равно будут иметь доступ к данным друг друга и всё равно не будут иметь доступ к системным — что с одним юзером, что вот так с двумя, то есть потенциальная уязвимость остаётся, если предполагается, что юзер может запускать рандомный треш. Проблему полностью решает сэндбокс. Можно, конечно, попытаться его переизобрести встроенными средствами, но по сути ты просто возьмёшь и сам напишешь аналог существующего, только хуже. Лучше взять готовое решение.

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

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

Именно это я и предлагал с самого начала. Рад, что удалось разъяснить мою идею.

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

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

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

Проблему полностью решает сэндбокс.

нет. Если бы это было так, что в Linux вместо рутового аккаунта был бы сандбокс.

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

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

Как и в случае отсутствия этого псевдоадминского аккаунта. Проблема остаётся локальной для юзера и в систему не переходит.

Если бы это было так, что в Linux вместо рутового аккаунта был бы сандбокс.

Неверно. Нарушена логика и причинно-следственная связь.

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

Как и в случае отсутствия этого псевдоадминского аккаунта. Проблема остаётся локальной для юзера и в систему не переходит.

Это так. Но возникает ещё один класс проблем, которые моё решение призвано решить.

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

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

Если вирусы не распространяются за счёт ограничения - это одна ситуация. Если бесконтрольно распространяются - другая (более тяжелая).

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

Это так. Но возникает ещё один класс проблем, которые моё решение призвано решить.

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

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

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

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

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

Да, ты тоже это понял. Хорошо. Лучше какая-то защита, чем никакой.

Полностью эта проблема решается сэндбоксом. Альтернативно можно её решить с помощью AppArmor или SELinux. Но сэндбокс гораздо проще в использовании и администрировании, да и просто в понимании.

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

Я соглашусь с тем, что добавить сандбокс не помешает. Потом, после, в новом отдельном топике. Ждите.

А в этом топике я всё ещё хочу два уровня админов.

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

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

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

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

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

Да, ты тоже это понял. Хорошо. Лучше какая-то защита, чем никакой.

Нет. Точнее не всегда. Зачастую иллюзия защиты при отсутствии полноценной защиты хуже, чем полное отстутствие попыток защититься и осознание уязвимости.

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

Для обучения — сколько угодно. Тут главное не считать это обеспечением безопасности, потому что прикрыта, грубо говоря, лишь одна из потенциальных целей для примерно одной атаки. А поскольку в итоге всё равно нужен будет просто сэндбок, при котором этот костыль не нужен, то практического применения данный подход не имеет. Но чисто в качестве обучалки — почему бы нет.

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

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

Почему тогда Root не выпиливают из Linux. Заменили бы на sandbox. Тем более, что AppArmor, SELinux и всё вышеперечисленное уже в линуксе есть.

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

Исключительно, чтобы осознание было лучше защиты.

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

Почему тогда Root не выпиливают из Linux. Заменили бы на sandbox.

Во-первых legacy и совместимость. Во-вторых, здесь немного разные задачи и разный уровень «защиты». root нужен не для обеспечения безопасности и защиты от «вирусов», и даже разные юзеры не совсем для этого. Тут надо углубляться в историю создания unix и пермишенов в них, но о вирусах тогда никто не думал, делая такой дизайн, думали просто о доступе одних юзеров к данным других. Плюс каждому юзеру свой конфиг, и т.д. AppArmor и SELinux, во-первых, были созданы намного позже и никак не относятся к POSIX, во-вторых, созданы для решения других задач (на сей раз действительно касающихся именно безопасности).

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

Зачем? Какую задачу это решает ценой потери совместимости и единообразности (переучиваться)?

Многое в GNU/Linux сделано так, как сделано, а не как-то иначе, чисто по историческим причинам. Не забывай об этом.

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

Вообще не аргумент.

Нет. Это очень сильный аргумент в мире POSIX-совместимых систем. Хорошо это или нет — вопрос отдельный (я не утверждал ни того ни другого), но это факт. Именно совместимость и legacy определяют очень многое, в том числе и в Linux (как ядре) и GNU/Linux (как семействе POSIX-совместимых ОС) и подавляющем большинстве конкретных дистрибутивов в частности.

Прошлое в прошлом, будущее - нет.

Это философия, имеющая мало отношения к тому, как по фактически происходит разработка и поддержка ПО и дистрибутивов GNU/Linux. По факту прошлое оказывает очень сильное влияние на настоящее и будущее.

Ты в праве считать, что это «неправильно», и надо всё сломать и построить заново. Спорить с этим я не буду. Скажу лишь, что попытки такие были, в том числе Plan 9, который был очень хорош в плане пересмотра некоторых концепций в лучшую сторону. Но ни одна из них, к сожалению, не выстрелила. Кроме DOS/Windows, которые отказались от совместимости по совсем иным причинам и, к ещё большему сожалению, как раз выстрелили.

Можешь попробовать сделать свой дистр с сэндбоксом и шлюпками. Без рута, с другим FHS (или вообще как-то иначе), другим набором стандартным утилит (более современным и упорядоченным), и т.д. Но перелопачивать придётся очень много. В том числе и в части прикладного софта, ожидающего стандартного поведения. А главное, сложно будет продвинуть его в массы, потому что само по себе избавление от legacy не решает почти ничьих практических проблем. Тут нужны энтузиасты с горящими глазами, готовые пилить для самостоятельного использования и «ради искусства».

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

Тут нужны энтузиасты с горящими глазами, готовые пилить для самостоятельного использования и «ради искусства».

Именно поэтому их надо осаживать на форумах. Ибо нефиг.

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

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

Первый логин называется root. Искренне Ваш К.О.

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

Я так в заголовке топика и написал. Хочу два разных вида рутов. Один рут - совсем рут, а второй рут - не совсем рут и слегка пользователь. А третий - совсем пользователь

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

При помощи ACL это всё можно накостылять:

  • Пользователь 1 может писать и читать свой хомяк, но не может что-либо исполнять из него, в хомяк пользователя 2 доступа не имеет.
  • Пользователь 2 может писать и читать свой хомяк, но не может что-либо исполнять из него, но может читать и исполнять что-либо из хомяка пользователя 1.
  • Оба пользователя не имеют возможности исполнять утилиты для правки ACL.

Конечно, это костыли, и никакого GUI к ним не будет.

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

Вот, вот, можете же писать по теме!

никакого GUI к ним не будет.

При таком агрессивном неприятии - конечно не будет. Вместо этого надо мотивировать на свершения.

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

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

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

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

Например заводите юзера-инсталлятора для которого через sudo открыт доступ к пакетному менеджеру.

Это отлично. Мой вопрос был в том, можно ли настроить sudo таким образом, чтобы обычный пользователь получал доступ к возможностям пользователя-инсталлятора. И делал в нём всё что хочет в рамках дозволенного пользователю-инсталлятору (но не руту всей системы).

Это важно, если пользователь захочет потренироваться в выполнении разных команд командной строки, вроде rm -rf / и т.п.

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

Вместо этого надо мотивировать на свершения.

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

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

надо мотивировать на свершения

Бггг, если хотите мотивировать на свершения, научитесь сначала себя нормально вести.

Пока что Вы мотивируете в основном на троллинг себя любимого - вот это у Вас прям офигенно получается!:-)

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

AntonI ★★★★★
()