Comments 66
Не очень понимаю как это ограничивает права пользователя и зачем это вообще может быть нужно?
Разве что для создания ограниченных шелов для младшего ит персонала.
Разве что для создания ограниченных шелов для младшего ит персонала.
Примеры использование:
— дать доступ к системе людям со стороны, что бы не сломали и можно было контроллированно ограничить их действия
— передача настроенной системе пользователям, что бы могли ее использовать и не сломали (ограничить доступ к критическим файлам и директориям)
Данная задача возникает, если мы считаем что пользователь системы может ее сломать)
— дать доступ к системе людям со стороны, что бы не сломали и можно было контроллированно ограничить их действия
— передача настроенной системе пользователям, что бы могли ее использовать и не сломали (ограничить доступ к критическим файлам и директориям)
Данная задача возникает, если мы считаем что пользователь системы может ее сломать)
Проблема в том, что ваш способ вообще ничего не ограничивает. К безопасности он не относиться никаким боком.
Я даже не знаю как корректно объяснить. Это не безопасность. Вы никак не ограничили права пользователя в системе, вы настроили, даже не безопасность, а интерфейс шела, примерно как удалить все ярлыки с рабочего стола и считать, что теперь все в безопасности.
Можно сказать, это один из вариантов UAC или SU( хотя сравнение не корректное, там все таки ограничения безопасности ), чтобы случайно чего-то не поломать, не более того.
Возможно это имеет смысл, чтобы дать не сильно квалифицированному пользователю возможность запустить самостоятельно ping на сервере который стоит у него в помещении и прочитать вывод администратору. Но для таких задач можно например использовать веб странички с небольшим кол-во команд, и вообще не давать пользователю логиниться на сервере.
Любой человек обладающий минимальной квалификацией и имеющий желание выйти из вашего окружения сделает это за несколько минут, ну может не минут, но не более получаса.
Самый простой вариант, ваш zuser может писать, а значит может залить туда произвольный код и выполнить его, не какой шел в данном случае не задействует.
Я даже не знаю как корректно объяснить. Это не безопасность. Вы никак не ограничили права пользователя в системе, вы настроили, даже не безопасность, а интерфейс шела, примерно как удалить все ярлыки с рабочего стола и считать, что теперь все в безопасности.
Можно сказать, это один из вариантов UAC или SU( хотя сравнение не корректное, там все таки ограничения безопасности ), чтобы случайно чего-то не поломать, не более того.
Возможно это имеет смысл, чтобы дать не сильно квалифицированному пользователю возможность запустить самостоятельно ping на сервере который стоит у него в помещении и прочитать вывод администратору. Но для таких задач можно например использовать веб странички с небольшим кол-во команд, и вообще не давать пользователю логиниться на сервере.
Любой человек обладающий минимальной квалификацией и имеющий желание выйти из вашего окружения сделает это за несколько минут, ну может не минут, но не более получаса.
Самый простой вариант, ваш zuser может писать, а значит может залить туда произвольный код и выполнить его, не какой шел в данном случае не задействует.
Согласен, изначально идея была дать оболочку которая ничего не умеет и только после этого добавлять в нее инструменты и тут кроется камень преткновения безопасности — эти инструменты пользователь может использовать для выхода за пределы оболочки.
т.е. Для пользователя создана металлическая коробка и он в нее помещен, но для работы ему нужна болгарка, ты ему ее даешь, и вместо того что бы пилить детали внутри коробки, он начинает пилить саму коробку.
т.е. Для пользователя создана металлическая коробка и он в нее помещен, но для работы ему нужна болгарка, ты ему ее даешь, и вместо того что бы пилить детали внутри коробки, он начинает пилить саму коробку.
Подходит другая аналогия: чтобы защитить сейф, все подходы к банку Вы сделали в виде лабиринта. В итоге сейф унести все равно можно (в том числе — и на вертолете), а вот людям стало жить сложнее.
Практический разговор о безопасности системы надо начинать с big bounty: то есть сколько Вы готовы отдать за дыру в системе. Если разработчик бритая пообещать даже малую сумму, то отсюда неутешительный вывод отрельном положении дел.
И если подытожить — правильнее называть подобное не «ограничение прав», а «защита от дурака». То есть специалист все равно выломает, однако случайный пользователь теперь случайно навредит с меньшей вероятностью.
Иногда нет возможности использовать ansible shell, приходится использовать прямой доступ по ssh для маленького CD. А чтобы компрометация ssh ничего не дала взломщику, можно максимально ограничит аккаунт.
Но согласен, легче всё же просто ограничить доступ пользователя исполнением одного единственного неизменяемого скрипта.
Но согласен, легче всё же просто ограничить доступ пользователя исполнением одного единственного неизменяемого скрипта.
Может быть нужно для изоляции приложений друг от друга, чтобы в случае взлома одного из приложений, был минимальный ущерб для всей системы.
Разве в п.7 должно быть не
?
ln -s /bin/ping /home/zuser/bin/ping?
Костыли в безопасности — самые опасные среди костылей.
Если у юзера есть доступ к чему-то из [man, vim, more, less, awk, zip, tar, git...] то он выходит из ваших ограничений. Если нет, не особо понятно, что он там вообще делает? Мб доступ к шелу можно было заменить одной формой или чем-то подобным?
Если у юзера есть доступ к чему-то из [man, vim, more, less, awk, zip, tar, git...] то он выходит из ваших ограничений. Если нет, не особо понятно, что он там вообще делает? Мб доступ к шелу можно было заменить одной формой или чем-то подобным?
Спасибо за вопрос, он действителен важен.
На сколько я знаю основные атаки заключается в следующем:
— изменить переменную PATH
Для блокировки данной уязвимости мы добавляем alias в файл .bashrc:
alias set=':'
alias uset=':'
alias export=':'
alias typeset=':'
alias declare=':'
alias alias=':'
alias unalias=':'
— переход в полноценную оболочку через скрипт или через утилиты vi, vim, nano, awk и т.д
Так же можно защитится через alias в файле .bashrc:
alias bin=':'
alias sh=':'
alias ln=':'
— также, для дополнительной защиты все команды через которые можно получить доступ к файлу или выполнить скрипты необходимо делать через обертки (п.8, п.9)
Если есть еще варианты взлома, напишите пожалуйста.
На сколько я знаю основные атаки заключается в следующем:
— изменить переменную PATH
Для блокировки данной уязвимости мы добавляем alias в файл .bashrc:
alias set=':'
alias uset=':'
alias export=':'
alias typeset=':'
alias declare=':'
alias alias=':'
alias unalias=':'
— переход в полноценную оболочку через скрипт или через утилиты vi, vim, nano, awk и т.д
Так же можно защитится через alias в файле .bashrc:
alias bin=':'
alias sh=':'
alias ln=':'
— также, для дополнительной защиты все команды через которые можно получить доступ к файлу или выполнить скрипты необходимо делать через обертки (п.8, п.9)
Если есть еще варианты взлома, напишите пожалуйста.
Как-то chroot для этих целей кажется проще и уместнее
Во-первых, уверен, это всё можно обойти, если покопаться повнимательнее.
Во-вторых, а зачем такой урезанный доступ вообще нужен? У меня не получается придумать практических применений для этого.
Как минимум есть одно.
И на первый, и на второй вопрос ответ — учебный курс по администрированию / инфобезу / etc. Отрестриктить так, чтобы фиксить трабл не получилось с помощью service restart / shutdown now / других нетрушных методов (я надеюсь Вы поняли). А если речь идёт о курсе по инфобезу — то за обход защиты от плюсика в карму до автомата (в зависимости от глубины курса, доброты преподавателя, остальной аудитории).
И на первый, и на второй вопрос ответ — учебный курс по администрированию / инфобезу / etc. Отрестриктить так, чтобы фиксить трабл не получилось с помощью service restart / shutdown now / других нетрушных методов (я надеюсь Вы поняли). А если речь идёт о курсе по инфобезу — то за обход защиты от плюсика в карму до автомата (в зависимости от глубины курса, доброты преподавателя, остальной аудитории).
Я, конечно, дико извиняюсь. Но учебный курс teaching to use bad practices это просто bullshit. И если teacher doesn't understand what в информационной безопасности нужно в первую очередь использовать appropriate methods для решения конкретных tasks, то его профпригодность is questionable.
Я am очень sorry, но mixing английские words с russian аналогами is плохая practice сама по itself.
Bad practices — то, что ждёт рядового студента в будущем ежедневно. Если говорить о программировании, например, то переписывание легаси-кода — это то, за что с наибольшей вероятностью прошлый студент покупает хлеб. Быть знакомым с врагом заранее — неплохой вариант, вообще-то.
Так, падажжите… профпригодность is questionable, говорите? То бишь такие вещи придумывают низкоквалифицированные идиоты, которых Вы можете так же тончайше и остроумнейше высмеять, как меня?
Создать по контейнеру на каждого пользователя и пускай творят что хотят до желаемого результата?
Не всегда покатит. Я не спец, но похожий на правду пример «непокатимости» могу привести.
Например, при изучении раздела загрузки ОС — задача на GRUB, нужно изменить ключи загрузки. Тяжело сформулировать конкретную задачу, но можно перекрыть возможность mkinitrd — закрыть простой путь. Да, конкретно в этой задаче содержимое статьи — вряд ли лучший инструмент, достаточно какого-нибудь SELinux, наверное. Но в общем в любом случае задача, в которой инструмент встанет, может всплыть.
Например, при изучении раздела загрузки ОС — задача на GRUB, нужно изменить ключи загрузки. Тяжело сформулировать конкретную задачу, но можно перекрыть возможность mkinitrd — закрыть простой путь. Да, конкретно в этой задаче содержимое статьи — вряд ли лучший инструмент, достаточно какого-нибудь SELinux, наверное. Но в общем в любом случае задача, в которой инструмент встанет, может всплыть.
1. Скорей всего, все можно обойти) По тем способам, которые я знаю мы немного защитились, а по остальным нужно смотреть
2. Примеры использование:
— дать доступ к системе людям со стороны, что бы не сломали и можно было контроллированно ограничить их действия
— передача настроенной системе пользователям, что бы могли ее использовать и не сломали (ограничить доступ к критическим файлам и директориям)
Данная задача возникает, если мы считаем что пользователь системы может ее сломать)
2. Примеры использование:
— дать доступ к системе людям со стороны, что бы не сломали и можно было контроллированно ограничить их действия
— передача настроенной системе пользователям, что бы могли ее использовать и не сломали (ограничить доступ к критическим файлам и директориям)
Данная задача возникает, если мы считаем что пользователь системы может ее сломать)
2) Школьников линуксу учить?
Был у меня похожий заказчик.
Хотел, чтобы люди, работающие по vpn по RDP из дома на 1С-сервере не могли шарить друг с другом файлы и вообще не знали о существовании других пользователей. И чтобы у каждого пользователя минимум прав и отчёты получать кто что сделал.
Намучался уже в самом начале, так что потом вообще отказался от работы. Надеюсь работники тоже отказались работать в таких условиях.
Это я к тому, что безопасность это здорово, но не должна она лишать свободы и комфорта. Надо к работникам относиться как к людям, и не сажать их в клетки.
У вас нету варианта дать человеку виртуалку и пушить работу в гит/вики или вызывать скрипты через веб, например?
Хотел, чтобы люди, работающие по vpn по RDP из дома на 1С-сервере не могли шарить друг с другом файлы и вообще не знали о существовании других пользователей. И чтобы у каждого пользователя минимум прав и отчёты получать кто что сделал.
Намучался уже в самом начале, так что потом вообще отказался от работы. Надеюсь работники тоже отказались работать в таких условиях.
Это я к тому, что безопасность это здорово, но не должна она лишать свободы и комфорта. Надо к работникам относиться как к людям, и не сажать их в клетки.
У вас нету варианта дать человеку виртуалку и пушить работу в гит/вики или вызывать скрипты через веб, например?
А, что они у Вас по RDP сразу в программу 1 С не входят?
Жесткий сценарий входа.
Жесткий сценарий входа.
Задача передать готовую систему, что бы пользователь мог ее контролировать и выполнять минимальные действия. Дело в том, что уровень знания пользователя неизвестен и он может что-то сломать. Искать что он сломал трудоемко, быстро починить можно только откатив систему, что бы минимизировать данные риски решили урезать возможности пользователю.
Я чего-то не понимаю:
а что мешает пользователю дать просто урезанную учетку — не рута. Он же и так мало что сможет. «От дурака» это спасет. А от квалифицированного хакера, который не просто скрипт-кидди и отдельная_виртуалка/chroot/контейнер не факт что защитит.
Не понимаю, если честно, сценарий от которого нужно защититься. Слишком абстрактно.
а что мешает пользователю дать просто урезанную учетку — не рута. Он же и так мало что сможет. «От дурака» это спасет. А от квалифицированного хакера, который не просто скрипт-кидди и отдельная_виртуалка/chroot/контейнер не факт что защитит.
Не понимаю, если честно, сценарий от которого нужно защититься. Слишком абстрактно.
А если не секрет — зачем в этих ограничениях отрублено автодополнение?
Подобный способ (restricted shell) есть также и в AIX, использую данный способ ограничения для некоторых пользователей уже давно.
Чем вам selinux и chroot то не подошло?
Напишите список утилит в вашем /home/user/bin, мы вам сообща напишем, как обойти вашу «защиту».
Вот так обходится ваш блеклист к ls, например(проверил)
Напишите список утилит в вашем /home/user/bin, мы вам сообща напишем, как обойти вашу «защиту».
Вот так обходится ваш блеклист к ls, например(проверил)
ls /\?inОчень интересно, согласен что 100% защиты конечно же нет, но Ваш пример добавим в blacklist.
Спасибо.
Спасибо.
Вы не сможете соcтавить нормальный black-list — слишком много способов. И по мере обновления системы будут появляться новые. Сам способ уже очень кривой.
Согласен, данный способ сделан на коленке в качестве примера. По сути надежный способ нужно продумывать и разрабатывать, это отдельная задача.
Это фигня. Либо вы делаете whitelist либо ничего не делаете.
Существуют миллиарды комбинаций, шел сильно мощная штука.
Все уже придумано до вас, используйте chroot.
Если вам в chroot надо чтото прокинуть — используйте pipes/hardlinks.
Существуют миллиарды комбинаций, шел сильно мощная штука.
Все уже придумано до вас, используйте chroot.
Если вам в chroot надо чтото прокинуть — используйте pipes/hardlinks.
UFO just landed and posted this here
Ну вот вы добавили в блеклист.
Давайте дальше, чтоли «добавляйте»
Логичнее было добавить обратный слеш, но есть еще другие варианты.
И это только один вид атак — регекспы.
Давайте дальше, чтоли «добавляйте»
ls /\[b\]in
ls /\[a-z\]in
ls /\[a-b\]in
ls /\*inЛогичнее было добавить обратный слеш, но есть еще другие варианты.
И это только один вид атак — регекспы.
Зашибись безопасность!
Извените, но этот подход совершенно бесполезен. Тут сходу десякти способов запустить полноценный шелл можно придумать. А если вы начнёте эти способы ограничивать (через chroot, права, ещё что-то), то на фига этот недо-шелл вообще нужен?
Извените, но этот подход совершенно бесполезен. Тут сходу десякти способов запустить полноценный шелл можно придумать. А если вы начнёте эти способы ограничивать (через chroot, права, ещё что-то), то на фига этот недо-шелл вообще нужен?
Да действительно он не обеспечивает 100% защиту. Статья немного изменила вектор: инструкция превратилась в анализ безопасности данного способа, что очень важно.
Да. Вредная статья. Мне как-то давали подобный rbash, чтобы я не лазил где попало. Даже обходить ничего не пришлось, залил при помощи scp нормальный шелл в одну из разрешенных утилит и вперед, лол.
В защиту автора: ограниченный шелл как способ обеспечения безопасности от целенаправленного взлома, разумеется, плох. Но может использоваться как способ дать доступ младшем персоналу для выполнения какого-то ограниченного списка команд, с уменьшением риска случайно выстрелить себе в ногу.
Был у нас заказчик как раз с такой фигнёй на серверах. Все понимал, но ни как не мог повлиять на тамошних админов, нагородивших этот странный огород. Сошлись на том, что кастыль для доступа к командам shell через консольный mysql вкрутили даже в ansible.
Можеть лучше SELinux настроить?
Правильный ответ — jailkit.
Rbash действительно дырявенький с этой точки зрения. Ну то есть сам по себе rbash хорош и задачу (свою!) выполняет, но его задача — не совсем в области безопасности, а как верно замечают выше — скорее, чтобы у неопытных пользователей консоли глаза от обилия бинарников не разбегались.
Rbash действительно дырявенький с этой точки зрения. Ну то есть сам по себе rbash хорош и задачу (свою!) выполняет, но его задача — не совсем в области безопасности, а как верно замечают выше — скорее, чтобы у неопытных пользователей консоли глаза от обилия бинарников не разбегались.
использование сторонних утилит, например SELinux (не подошло, усложняет систему)
useradd -c «User with the limited rights» -Z guest_u -m -U -s /bin/bash user
passwd user
Вот весь SELinux
И конечно же забыли про LD_PRELOAD...
Sign up to leave a comment.
Ограничение прав локального пользователя в Linux до минимума