The OpenNET Project / Index page

[ новости /+++ | форум | wiki | теги | ]



"Раздел полезных советов: Работа с 32- и 64-разрядными chroot  на примере Debian"
Вариант для распечатки  
Пред. тема | След. тема 
Форум Разговоры, обсуждение новостей
Изначальное сообщение [ Отслеживать ]

"Раздел полезных советов: Работа с 32- и 64-разрядными chroot  на примере Debian"  +/
Сообщение от auto_tips (??), 14-Июн-21, 13:54 
Я работаю в 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/gshadow

URL:
Обсуждается: https://www.opennet.ru/tips/info/3185.shtml

Ответить | Правка | Cообщить модератору

Оглавление

Сообщения [Сортировка по ответам | RSS]

1. Сообщение от Аноним (1), 14-Июн-21, 13:54   +/
Вместо uchroot можно использовать schroot из соответствующего пакета. В файле конфигурации можно указать конкретных пользователей, которые могут запускать приложения в чруте (не запрашивая у них пароль).
Ответить | Правка | Наверх | Cообщить модератору

2. Сообщение от Аноним (2), 14-Июн-21, 21:53   +/
Много слышал про 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, наставить хлама, затем стереть её и распаковать по новой?

Ответить | Правка | Наверх | Cообщить модератору
Ответы: #3, #4, #6

3. Сообщение от Anon2 (?), 15-Июн-21, 12:04   +/
chroot, ну это как бы не о безопасности.

Запускаемые в chroot приложения имеют доступ к файловой системе хоста. Ну т.е. штатно не имеют, но элементарно получают доступ, если поставлена именно такая задача (что нештатно и подразумевает злонамеренно). В итоге доступ к хостовому /home/username/.ssh/ можно запретить только если запускать приложения в chroot от пользователя не имеющего права на чтение /home/username/.ssh/ и не имеющего возможности повысить свои привилегии (включая нештатный через уязвимости по повышению привилегий).

Хотя справедливости ради, при наличии уязвимостей на всех уровнях, то и из qemu-kvm можно получить доступ к хостовому home/username/.ssh/. Просто это не для китайских ботов и скрипт-киддисов будет задачка.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #2 Ответы: #5, #11

4. Сообщение от Павел Отредиезemail (?), 16-Июн-21, 16:59   +/
Мой кейс такой. Собрать ядро под 32 и 64 в разных userspace, собрать некоторые пакеты в разных userspace. Удобно иметь чруты вообще разных дистрибутивов и собирать под них. Тебе лучше остаться на виртуалке.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #2

5. Сообщение от Павел Отредиезemail (?), 16-Июн-21, 17:01   +/
> chroot, ну это как бы не о безопасности.
> Запускаемые в chroot приложения имеют доступ к файловой системе хоста. Ну т.е.
> штатно не имеют, но элементарно получают доступ, если поставлена именно такая
> задача (что нештатно и подразумевает злонамеренно). В итоге доступ к хостовому
> /home/username/.ssh/ можно запретить только если запускать приложения в chroot от пользователя
> не имеющего права на чтение /home/username/.ssh/ и не имеющего возможности повысить
> свои привилегии (включая нештатный через уязвимости по повышению привилегий).
> Хотя справедливости ради, при наличии уязвимостей на всех уровнях, то и из
> qemu-kvm можно получить доступ к хостовому home/username/.ssh/. Просто это не для
> китайских ботов и скрипт-киддисов будет задачка.

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

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #3 Ответы: #7

6. Сообщение от ZFS (?), 18-Июн-21, 17:24   +/
Вы прям так радуетесь своему tar.bz

Когда в виртуалку можно легко и непринужденно пробрасывать блочные устройства ZFS zvol с хоста.
А можно при желании монтировать их на хосте.

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

zfs rollback pool1/vm/amd64/devuan_vol@before_upgrade

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #2 Ответы: #8

7. Сообщение от Anon2 (?), 20-Июн-21, 11:59   +/
> ... а так из чрута не выйти.

Поясните свою логику? Каким образом у вас появляется эта мысль?

В чруте
# chroot /proc/1/cwd/
это не то?

Естественно запрет запуска chroot в чруте проблемму не решает.
При рабработке chroot-а вопросам безопасности не уделялось внимание.
chroot для доверенных окружений

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #5 Ответы: #9

8. Сообщение от Аноним (8), 21-Июн-21, 00:11   +/
Вам нравится целую машинерию поддерживать ради элементарной вещи, типа отката состояния конкретной директории на бэкап? ZFS для линукса не родная и ее использование дискуссионно само по себе. Все эти снапшоты не бесплатны и содержат массу подводных камней, которых у распаковки тарболла нет и быть не может.
Если нужно подготовить чрут, чтобы там пару действий сделать, лучше уж сделать это с помощью элементарных утилит и архива с файлами, чем полагаться на настройки хоста и системы управления виртуализацией.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #6

9. Сообщение от Павел Отредиезemail (?), 21-Июн-21, 16:53   +/
/proc/1/cwd это симлинки. В чруте она указывает относительно newroot.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #7 Ответы: #10

10. Сообщение от Anon2 (?), 22-Июн-21, 20:25   +/
Когда выполняется chroot в newroot, то выполняется переход по inode. В итоге вы попадаете в хост систему.
Я вроде привел конкретную команду. Вы не потрудились ее проверить, а только лишь посмотрели куда указывает симлинк /proc/1/cwd.
Спасибо, мне теперь понятен ваш ход мыслей.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #9 Ответы: #12

11. Сообщение от abu (?), 28-Июн-21, 07:03   +/
"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 именно про безопасность. И всегда так было при настройках серверов-сервисов.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #3 Ответы: #13, #17

12. Сообщение от Павел Отредиезemail (?), 28-Июн-21, 13:50   +/
Я потрудился проверить:

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

Получился листинг того же чрута.

Извини, но у тебя немножко мешанина в голове. Симлинка ничего не знает о иноде куда указывает кроме путевого имени.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #10 Ответы: #14, #16

13. Сообщение от Anon2 (?), 08-Июл-21, 13:12   +/
Для приведенных случаев безопасность обеспечивается не 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.

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

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #11

14. Сообщение от Anon2 (?), 08-Июл-21, 13:18   +/
Ну мля.
В хост системе делаем:
touch /MARK_FILE
чтобы следующими телодвижениями получить возможность увидеть его из chroot-a.

Переходим в chroot:
sudo chroot /opt/debian64/ /bin/bash

теперь мы в chroot-те с правами root.

И ход конем
chroot /proc/1/cwd /bin/bash
хопа, мы в хост системе
ls -1 /
и мы видим
.
..
....
/MARK_FILE

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #12 Ответы: #15

15. Сообщение от Anon2 (?), 08-Июл-21, 14:00   +/
Здесь, хорошо описано
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 хост системы.
У меня ванильное ядро. Может в вашем ядре мейнтейнеры как-то это запатчили, хотя и сомневаюсь
Укажите параметры хост системы

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #14

16. Сообщение от Anon2 (?), 08-Июл-21, 14:33   +/
> Извини, но у тебя немножко мешанина в голове. Симлинка ничего не знает
> о иноде куда указывает кроме путевого имени.

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"

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #12

17. Сообщение от anonymous (??), 16-Июл-21, 10:30   +/
Ещё всё ненужное из чрута выпиливали, да, да
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #11


Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




Спонсоры:
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2021 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру