forum.opennet.ru - "Раздел полезных советов: Работа с 32- и 64-разрядными chroot на примере Debian" (20)

"Раздел полезных советов: Работа с 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: Обсуждается: http://www.opennet.dev/tips/info/3185.shtml
Ответить \| Правка \| Cообщить модератору

Оглавление

Вместо uchroot можно использовать schroot из соответствующего пакета В файле ко, Аноним (1), 13:54 , 14-Июн-21, (1)
Много слышал про chroot но пока не тыкал его, т к не понятна практическая конкр, Аноним (2), 21:53 , 14-Июн-21, (2)

chroot, ну это как бы не о безопасности Запускаемые в chroot приложения имеют до, Anon2 (?), 12:04 , 15-Июн-21, (3)

Ну как это будет иметь доступ ко всей фс, только ктому что пробросишь, а так из , Павел Отредиез (?), 17:01 , 16-Июн-21, (5)

Поясните свою логику Каким образом у вас появляется эта мысль В чруте chroot , Anon2 (?), 11:59 , 20-Июн-21, (7)

proc 1 cwd это симлинки В чруте она указывает относительно newroot , Павел Отредиез (?), 16:53 , 21-Июн-21, (9)

Когда выполняется chroot в newroot, то выполняется переход по inode В итоге вы , Anon2 (?), 20:25 , 22-Июн-21, (10)

Я потрудился проверить code pavel mainpc sudo chroot opt debian64 root main, Павел Отредиез (?), 13:50 , 28-Июн-21, (12)

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

Здесь, хорошо описаноhttps access redhat com blogs 766093 posts 1975883 гугл-т, Anon2 (?), 14:00 , 08-Июл-21, (15)

https 01 org linuxgraphics gfx-docs drm filesystems path-lookup htmlЦитата The, Anon2 (?), 14:33 , 08-Июл-21, (16)

chroot, ну это как бы не о безопасности Не сочтите, что придираюсь, просто про, abu (?), 07:03 , 28-Июн-21, (11)

Для приведенных случаев безопасность обеспечивается не chroot-ом, а правами поль, Anon2 (?), 13:12 , 08-Июл-21, (13)
Ещё всё ненужное из чрута выпиливали, да, да, anonymous (??), 10:30 , 16-Июл-21, (17)

Мой кейс такой Собрать ядро под 32 и 64 в разных userspace, собрать некоторые п, Павел Отредиез (?), 16:59 , 16-Июн-21, (4)
Вы прям так радуетесь своему tar bzКогда в виртуалку можно легко и непринужденно, ZFS (?), 17:24 , 18-Июн-21, (6)

Вам нравится целую машинерию поддерживать ради элементарной вещи, типа отката со, Аноним (8), 00:11 , 21-Июн-21, (8)

Вероятно, в данном конкретном случае можно посмотреть на https docs openshift , Аноним (19), 17:06 , 09-Авг-21, (19)

Открой для себя lxc и не мучайся с chroot , Аноним (20), 01:55 , 19-Сен-21, (20)
открой для себя docker и не мучайся с chroot, sods (?), 15:55 , 29-Сен-21, (21)

Сообщения [Сортировка по ответам | 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, #19

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. Сообщение от Павел Отредиез (?), 16-Июн-21, 16:59 +/–

Мой кейс такой. Собрать ядро под 32 и 64 в разных userspace, собрать некоторые пакеты в разных userspace. Удобно иметь чруты вообще разных дистрибутивов и собирать под них. Тебе лучше остаться на виртуалке.

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

5. Сообщение от Павел Отредиез (?), 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. Сообщение от Павел Отредиез (?), 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. Сообщение от Павел Отредиез (?), 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

19. Сообщение от Аноним (19), 09-Авг-21, 17:06 +/–

Вероятно, в данном конкретном случае можно посмотреть на 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 адресах и поверх запустить важный хлам. С возможностью получить память и процы обратно сразу в любой момент без отдельных телодвижений.
Под описание, из этой троицы, хорошо подходят контейнеры. Чрут не столь интересен.

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

20. Сообщение от Аноним (20), 19-Сен-21, 01:55 +/–

Открой для себя lxc и не мучайся с chroot.

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

21. Сообщение от sods (?), 29-Сен-21, 15:55 +/–

открой для себя docker и не мучайся с chroot

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

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

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

Партнёры:

Хостинг:

Закладки на сайте
Проследить за страницей

Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру

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, #19

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

5. Сообщение от Павел Отредиез (?), 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. Сообщение от Павел Отредиез (?), 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. Сообщение от Павел Отредиез (?), 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

19. Сообщение от Аноним (19), 09-Авг-21, 17:06	+/–
Вероятно, в данном конкретном случае можно посмотреть на 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 адресах и поверх запустить важный хлам. С возможностью получить память и процы обратно сразу в любой момент без отдельных телодвижений. Под описание, из этой троицы, хорошо подходят контейнеры. Чрут не столь интересен.
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #2

20. Сообщение от Аноним (20), 19-Сен-21, 01:55	+/–
Открой для себя lxc и не мучайся с chroot.
Ответить \| Правка \| Наверх \| Cообщить модератору

21. Сообщение от sods (?), 29-Сен-21, 15:55	+/–
открой для себя docker и не мучайся с chroot
Ответить \| Правка \| Наверх \| Cообщить модератору