Я работаю в Debian testing ARCH=i386 с amd64 битным ядром. 64-битное ядро позволяет запускать и 64-битные программы и 32-битные.uname -ar
Linux mainpc.tinyware.sytes.net 5.10.43-tinyware-amd64 #1 SMP Fri Jun 11 00:52:31 UTC 2021 x86_64 GNU/Linux
32-битный userspace уже есть в основной системе, хочется иметь 64-битный userspace как можно более прозрачно.Для этого подготовлен chroot:
sudo mkdir /opt/debian64
sudo debootstrap --arch amd64 stable /opt/debian64/ http://mirror.yandex.ru/debian/Надо сделать chroot полноценным, пробросив в него нужные файловые системы, для этого в /etc/fstab добавим
/proc /opt/debian64/proc bind bind,auto
/dev /opt/debian64/dev bind bind,auto
/dev/pts /opt/debian64/dev/pts bind bind,auto
/sys /opt/debian64/sys bind bind,auto
/tmp /opt/debian64/tmp bind bind,auto
/home /opt/debian64/home bind bind,auto
/run /opt/debian64/run bind bind,autoТеперь в него легко можно чрутиться от рута и это полноценное окружение.
sudo chroot /opt/debian64
Но хотелось бы запускать программы прямо от текущего пользователя. Для этого
sudo cp /usr/sbin/chroot /usr/bin/uchroot
sudo setcap CAP_SYS_CHROOT+ep /usr/bin/uchrootТеперь можно запускать программы из под обыкновенного пользователя
$ uchroot /opt/debian64
или сразу команду (можно добавить в ярлык)
$ uchroot /opt/debian64 tuxguitar
Так же для красоты можно скопировать в /opt/debian64 файлы /etc/passwd /etc/shadow /etc/group /etc/gshadowURL:
Обсуждается: http://www.opennet.dev/tips/info/3185.shtml
Вместо uchroot можно использовать schroot из соответствующего пакета. В файле конфигурации можно указать конкретных пользователей, которые могут запускать приложения в чруте (не запрашивая у них пароль).
Много слышал про 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, наставить хлама, затем стереть её и распаковать по новой?
chroot, ну это как бы не о безопасности.Запускаемые в chroot приложения имеют доступ к файловой системе хоста. Ну т.е. штатно не имеют, но элементарно получают доступ, если поставлена именно такая задача (что нештатно и подразумевает злонамеренно). В итоге доступ к хостовому /home/username/.ssh/ можно запретить только если запускать приложения в chroot от пользователя не имеющего права на чтение /home/username/.ssh/ и не имеющего возможности повысить свои привилегии (включая нештатный через уязвимости по повышению привилегий).
Хотя справедливости ради, при наличии уязвимостей на всех уровнях, то и из qemu-kvm можно получить доступ к хостовому home/username/.ssh/. Просто это не для китайских ботов и скрипт-киддисов будет задачка.
> chroot, ну это как бы не о безопасности.
> Запускаемые в chroot приложения имеют доступ к файловой системе хоста. Ну т.е.
> штатно не имеют, но элементарно получают доступ, если поставлена именно такая
> задача (что нештатно и подразумевает злонамеренно). В итоге доступ к хостовому
> /home/username/.ssh/ можно запретить только если запускать приложения в chroot от пользователя
> не имеющего права на чтение /home/username/.ssh/ и не имеющего возможности повысить
> свои привилегии (включая нештатный через уязвимости по повышению привилегий).
> Хотя справедливости ради, при наличии уязвимостей на всех уровнях, то и из
> qemu-kvm можно получить доступ к хостовому home/username/.ssh/. Просто это не для
> китайских ботов и скрипт-киддисов будет задачка.Ну как это будет иметь доступ ко всей фс, только ктому что пробросишь, а так из чрута не выйти.
> ... а так из чрута не выйти.Поясните свою логику? Каким образом у вас появляется эта мысль?
В чруте
# chroot /proc/1/cwd/
это не то?Естественно запрет запуска chroot в чруте проблемму не решает.
При рабработке chroot-а вопросам безопасности не уделялось внимание.
chroot для доверенных окружений
/proc/1/cwd это симлинки. В чруте она указывает относительно newroot.
Когда выполняется chroot в newroot, то выполняется переход по inode. В итоге вы попадаете в хост систему.
Я вроде привел конкретную команду. Вы не потрудились ее проверить, а только лишь посмотрели куда указывает симлинк /proc/1/cwd.
Спасибо, мне теперь понятен ваш ход мыслей.
Я потрудился проверить:
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Получился листинг того же чрута.
Извини, но у тебя немножко мешанина в голове. Симлинка ничего не знает о иноде куда указывает кроме путевого имени.
Ну мля.
В хост системе делаем:
touch /MARK_FILE
чтобы следующими телодвижениями получить возможность увидеть его из chroot-a.Переходим в chroot:
sudo chroot /opt/debian64/ /bin/bashтеперь мы в chroot-те с правами root.
И ход конем
chroot /proc/1/cwd /bin/bash
хопа, мы в хост системе
ls -1 /
и мы видим
.
..
....
/MARK_FILE
Здесь, хорошо описано
https://access.redhat.com/blogs/766093/posts/1975883
(гугл-транслейтом хорошо переводится)
А вот здесь
https://ru.wikipedia.org/wiki/Chroot
указано на проблемму second chroot, ссылка потом ведет на
https://web.archive.org/web/20150314231549/http://www.bpfh.n...Ну, справедливости ради, УМВР.
Т.е. ваш
ls /proc/1/cwd
у меня будет показывать/MARK_FILE
и
cat /proc/1/cwd/etc/passwd
выведет содержимое passwd хост системы.
У меня ванильное ядро. Может в вашем ядре мейнтейнеры как-то это запатчили, хотя и сомневаюсь
Укажите параметры хост системы
> Извини, но у тебя немножко мешанина в голове. Симлинка ничего не знает
> о иноде куда указывает кроме путевого имени.https://01.org/linuxgraphics/gfx-docs/drm/filesystems/path-l...
Цитата:
The other case involves things in /proc that look like symlinks but aren't really (and are therefore commonly referred to as "magic-links"):Т.е. в документации к ядру четко указано, что то что вы принимаете за symlinks на файловой системе /proc, симлинком не является.
Для моего локалхоста, Midnight Commander на файловой системе /proc симлинки считает симлинками, а
вот ls, cat, chroot на файловой системе /proc уже считают symlinks как "magic-links"
"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/...
Как по мне - chroot именно про безопасность. И всегда так было при настройках серверов-сервисов.
Для приведенных случаев безопасность обеспечивается не 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.Т.е. мы строим многоуровневую защиту с целью задолбать злоумышленника, но принимаем, что каждый уровень может быть уязвим.
Ещё всё ненужное из чрута выпиливали, да, да
Мой кейс такой. Собрать ядро под 32 и 64 в разных userspace, собрать некоторые пакеты в разных userspace. Удобно иметь чруты вообще разных дистрибутивов и собирать под них. Тебе лучше остаться на виртуалке.
Вы прям так радуетесь своему tar.bzКогда в виртуалку можно легко и непринужденно пробрасывать блочные устройства ZFS zvol с хоста.
А можно при желании монтировать их на хосте.А чтобы откатиться назад на снэпшот, нужно всего лишь остановить виртуалку и набрать, к примеру:
zfs rollback pool1/vm/amd64/devuan_vol@before_upgrade
Вам нравится целую машинерию поддерживать ради элементарной вещи, типа отката состояния конкретной директории на бэкап? ZFS для линукса не родная и ее использование дискуссионно само по себе. Все эти снапшоты не бесплатны и содержат массу подводных камней, которых у распаковки тарболла нет и быть не может.
Если нужно подготовить чрут, чтобы там пару действий сделать, лучше уж сделать это с помощью элементарных утилит и архива с файлами, чем полагаться на настройки хоста и системы управления виртуализацией.
Вероятно, в данном конкретном случае можно посмотреть на https://docs.openshift.com/container-platform/3.11/crio/crio...Далее:
https://github.com/docker/compose
или совсем
https://minikube.sigs.k8s.io/docs/start/ + https://helm.sh/docs/intro/quickstart/Chroot - сформировать контент другой файловой системы для каких-либо целей. Полезно при сборке образа диска для виртуалки, для загрузочной флешки, и в обратную сторону для ремонта компа, загрузившись с флешки попасть в ФС комп-а как в корневую.
Q-Emu и Kvm - поработать с железом, но с отдельным, виртуальным, с отдельными памятью и процессором.
Контейнеры - получить все процессоры, всю память, в отдельной сети на многих отдельных IP адресах и поверх запустить важный хлам. С возможностью получить память и процы обратно сразу в любой момент без отдельных телодвижений.
Под описание, из этой троицы, хорошо подходят контейнеры. Чрут не столь интересен.
Открой для себя lxc и не мучайся с chroot.
открой для себя docker и не мучайся с chroot