| 1.1, Аноним (1), 13:54, 14/06/2021 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
Вместо uchroot можно использовать schroot из соответствующего пакета. В файле конфигурации можно указать конкретных пользователей, которые могут запускать приложения в чруте (не запрашивая у них пароль).
| | |
| 1.2, Аноним (2), 21:53, 14/06/2021 [ответить] [﹢﹢﹢] [ · · · ]
| +/– | |
Много слышал про chroot но пока не тыкал его, т.к. не понятна практическая конкретизация применения.
Например, рассмотрим мой кейс: я (как сознательная веб-макака, дабы не засирать рабочее окружение) установил qemu-kvm, создал гостя, накатил туда debian10 + apache2 + php8 + mysql8 и прочий lamp хлам.
Удобство в том, что qcow2 образ диска забекаплен, я в любой момент могу наставить кучу пакетов/модулей (нагадить в виртуалке), затем остановить её, грохнуть qcow2 файл и восстановить его из бекапа и вновь начать работать с чистой гостевой lamp.
Разумеется, запускаемые "сайты" не могут выбраться из гостевого /var/www/site-name и прочитать локальный файл в /home/username/.ssh/
Правильно ли я понимаю, что в своём кейсе я могу заменить qemu-kvm на chroot и также гибко управлять окружением внутри условной папки /opt/debian64 ?
Тоесть забекапить её в tar.bz, наставить хлама, затем стереть её и распаковать по новой?
| | |
| |
| 2.3, Anon2 (?), 12:04, 15/06/2021 [^] [^^] [^^^] [ответить]
| +/– | |
chroot, ну это как бы не о безопасности.
Запускаемые в chroot приложения имеют доступ к файловой системе хоста. Ну т.е. штатно не имеют, но элементарно получают доступ, если поставлена именно такая задача (что нештатно и подразумевает злонамеренно). В итоге доступ к хостовому /home/username/.ssh/ можно запретить только если запускать приложения в chroot от пользователя не имеющего права на чтение /home/username/.ssh/ и не имеющего возможности повысить свои привилегии (включая нештатный через уязвимости по повышению привилегий).
Хотя справедливости ради, при наличии уязвимостей на всех уровнях, то и из qemu-kvm можно получить доступ к хостовому home/username/.ssh/. Просто это не для китайских ботов и скрипт-киддисов будет задачка.
| | |
| |
| 3.5, Павел Отредиез (?), 17:01, 16/06/2021 [^] [^^] [^^^] [ответить]
| +/– |
 > chroot, ну это как бы не о безопасности.
> Запускаемые в chroot приложения имеют доступ к файловой системе хоста. Ну т.е.
> штатно не имеют, но элементарно получают доступ, если поставлена именно такая
> задача (что нештатно и подразумевает злонамеренно). В итоге доступ к хостовому
> /home/username/.ssh/ можно запретить только если запускать приложения в chroot от пользователя
> не имеющего права на чтение /home/username/.ssh/ и не имеющего возможности повысить
> свои привилегии (включая нештатный через уязвимости по повышению привилегий).
> Хотя справедливости ради, при наличии уязвимостей на всех уровнях, то и из
> qemu-kvm можно получить доступ к хостовому home/username/.ssh/. Просто это не для
> китайских ботов и скрипт-киддисов будет задачка.
Ну как это будет иметь доступ ко всей фс, только ктому что пробросишь, а так из чрута не выйти.
| | |
| |
| 4.7, Anon2 (?), 11:59, 20/06/2021 [^] [^^] [^^^] [ответить]
| +/– | |
> ... а так из чрута не выйти.
Поясните свою логику? Каким образом у вас появляется эта мысль?
В чруте
# chroot /proc/1/cwd/
это не то?
Естественно запрет запуска chroot в чруте проблемму не решает.
При рабработке chroot-а вопросам безопасности не уделялось внимание.
chroot для доверенных окружений
| | |
| |
| |
| 6.10, Anon2 (?), 20:25, 22/06/2021 [^] [^^] [^^^] [ответить]
| +/– |
Когда выполняется chroot в newroot, то выполняется переход по inode. В итоге вы попадаете в хост систему.
Я вроде привел конкретную команду. Вы не потрудились ее проверить, а только лишь посмотрели куда указывает симлинк /proc/1/cwd.
Спасибо, мне теперь понятен ваш ход мыслей.
| | |
| |
| 7.12, Павел Отредиез (?), 13:50, 28/06/2021 [^] [^^] [^^^] [ответить]
| +/– |
Я потрудился проверить:
pavel@mainpc:~$ sudo chroot /opt/debian64/
root@mainpc:/# ls /proc/1/cwd
bin etc lib64 media proc sbin tmp vmlinuz
boot home libx32 mnt root srv usr vmlinuz.old
dev lib lost+found opt run sys var
Получился листинг того же чрута.
Извини, но у тебя немножко мешанина в голове. Симлинка ничего не знает о иноде куда указывает кроме путевого имени.
| | |
| |
| 8.14, Anon2 (?), 13:18, 08/07/2021 [^] [^^] [^^^] [ответить] | +/– | Ну мля В хост системе делаем touch MARK_FILE чтобы следующими телодвижениями ... текст свёрнут, показать | | |
| |
| 9.15, Anon2 (?), 14:00, 08/07/2021 [^] [^^] [^^^] [ответить] | +/– | Здесь, хорошо описано https access redhat com blogs 766093 posts 1975883 гугл... текст свёрнут, показать | | |
|
| 8.16, Anon2 (?), 14:33, 08/07/2021 [^] [^^] [^^^] [ответить] | +/– | https 01 org linuxgraphics gfx-docs drm filesystems path-lookup html Цитата T... текст свёрнут, показать | | |
|
|
|
|
|
| 3.11, abu (?), 07:03, 28/06/2021 [^] [^^] [^^^] [ответить]
| +/– | |
"chroot, ну это как бы не о безопасности."
Не сочтите, что придираюсь, просто прочтите, например, пункт 1.2 в документе про chroot для BIND:
https://tldp.org/HOWTO/Chroot-BIND-HOWTO-1.html
или вот, про настройку Postfix:
"chroot
Postfix provides multiple layers of security. One such layer is the option to permit most Postfix services to run within a chroot environment. The Unix chroot function allows a process to change its view of, and access to, its filesystem by changing its root directory to a new path other than the normal /. "
https://www.oreilly.com/library/view/postfix-the-definitive/0596002122/ch04s08
Как по мне - chroot именно про безопасность. И всегда так было при настройках серверов-сервисов.
| | |
| |
| 4.13, Anon2 (?), 13:12, 08/07/2021 [^] [^^] [^^^] [ответить]
| +/– | |
Для приведенных случаев безопасность обеспечивается не chroot-ом, а правами пользователя. Если система не позволяет повысить привилегии до root (или другого пользователя имеющего право на запуск "системного вызова chroot"), то можно принять, что это безопасно.
в пункте 1.2 также написано
This should be considered as a supplement to the normal security precautions (running the latest version, using access control, etc.), certainly not as a replacement for them.
Т.е. мы строим многоуровневую защиту с целью задолбать злоумышленника, но принимаем, что каждый уровень может быть уязвим.
| | |
|
|
| 2.4, Павел Отредиез (?), 16:59, 16/06/2021 [^] [^^] [^^^] [ответить]
| +/– |
Мой кейс такой. Собрать ядро под 32 и 64 в разных userspace, собрать некоторые пакеты в разных userspace. Удобно иметь чруты вообще разных дистрибутивов и собирать под них. Тебе лучше остаться на виртуалке.
| | |
| 2.6, ZFS (?), 17:24, 18/06/2021 [^] [^^] [^^^] [ответить]
| +/– | |
Вы прям так радуетесь своему tar.bz
Когда в виртуалку можно легко и непринужденно пробрасывать блочные устройства ZFS zvol с хоста.
А можно при желании монтировать их на хосте.
А чтобы откатиться назад на снэпшот, нужно всего лишь остановить виртуалку и набрать, к примеру:
zfs rollback pool1/vm/amd64/devuan_vol@before_upgrade
| | |
| |
| 3.8, Аноним (8), 00:11, 21/06/2021 [^] [^^] [^^^] [ответить]
| +/– |
Вам нравится целую машинерию поддерживать ради элементарной вещи, типа отката состояния конкретной директории на бэкап? ZFS для линукса не родная и ее использование дискуссионно само по себе. Все эти снапшоты не бесплатны и содержат массу подводных камней, которых у распаковки тарболла нет и быть не может.
Если нужно подготовить чрут, чтобы там пару действий сделать, лучше уж сделать это с помощью элементарных утилит и архива с файлами, чем полагаться на настройки хоста и системы управления виртуализацией.
| | |
|
| 2.19, Аноним (19), 17:06, 09/08/2021 [^] [^^] [^^^] [ответить]
| +/– | |
Вероятно, в данном конкретном случае можно посмотреть на https://docs.openshift.com/container-platform/3.11/crio/crio_runtime.html
Далее:
https://github.com/docker/compose
или совсем
https://minikube.sigs.k8s.io/docs/start/ + https://helm.sh/docs/intro/quickstart/
Chroot - сформировать контент другой файловой системы для каких-либо целей. Полезно при сборке образа диска для виртуалки, для загрузочной флешки, и в обратную сторону для ремонта компа, загрузившись с флешки попасть в ФС комп-а как в корневую.
Q-Emu и Kvm - поработать с железом, но с отдельным, виртуальным, с отдельными памятью и процессором.
Контейнеры - получить все процессоры, всю память, в отдельной сети на многих отдельных IP адресах и поверх запустить важный хлам. С возможностью получить память и процы обратно сразу в любой момент без отдельных телодвижений.
Под описание, из этой троицы, хорошо подходят контейнеры. Чрут не столь интересен.
| | |
|
|