forum.opennet.ru

Форум Разговоры, обсуждение новостей
Вариант для распечатки		Пред. тема \| След. тема
Режим отображения отдельной подветви беседы		[ Отслеживать ]

Оглавление

Раздел полезных советов: Работа с 32- и 64-разрядными chroot на примере Debian, auto_tips (??), 14-Июн-21, (0) [смотреть все]

Вместо 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]

3. "Работа с 32- и 64-разрядными chroot  на примере Debian" +/–

Сообщение от Anon2 (?), 15-Июн-21, 12:04

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

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

5. "Работа с 32- и 64-разрядными chroot  на примере Debian" +/–

Сообщение от Павел Отредиез (?), 16-Июн-21, 17:01

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

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

7. "Работа с 32- и 64-разрядными chroot  на примере Debian" +/–

Сообщение от Anon2 (?), 20-Июн-21, 11:59

> ... а так из чрута не выйти.
Поясните свою логику? Каким образом у вас появляется эта мысль?
В чруте
# chroot /proc/1/cwd/
это не то?
Естественно запрет запуска chroot в чруте проблемму не решает.
При рабработке chroot-а вопросам безопасности не уделялось внимание.
chroot для доверенных окружений

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

9. "Работа с 32- и 64-разрядными chroot  на примере Debian" +/–

Сообщение от Павел Отредиез (?), 21-Июн-21, 16:53

/proc/1/cwd это симлинки. В чруте она указывает относительно newroot.

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

10. "Работа с 32- и 64-разрядными chroot  на примере Debian" +/–

Сообщение от Anon2 (?), 22-Июн-21, 20:25

Когда выполняется chroot в newroot, то выполняется переход по inode. В итоге вы попадаете в хост систему.
Я вроде привел конкретную команду. Вы не потрудились ее проверить, а только лишь посмотрели куда указывает симлинк /proc/1/cwd.
Спасибо, мне теперь понятен ваш ход мыслей.

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

12. "Работа с 32- и 64-разрядными chroot  на примере Debian" +/–

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

14. "Работа с 32- и 64-разрядными chroot  на примере Debian" +/–

Сообщение от 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ообщить модератору

15. "Работа с 32- и 64-разрядными chroot  на примере Debian" +/–

Сообщение от 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ообщить модератору

16. "Работа с 32- и 64-разрядными chroot  на примере Debian" +/–

Сообщение от 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"

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

11. "Работа с 32- и 64-разрядными chroot  на примере Debian" +/–

Сообщение от 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 именно про безопасность. И всегда так было при настройках серверов-сервисов.

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

13. "Работа с 32- и 64-разрядными chroot  на примере Debian" +/–

Сообщение от 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ообщить модератору

17. "Работа с 32- и 64-разрядными chroot  на примере Debian" +/–

Сообщение от anonymous (??), 16-Июл-21, 10:30

Ещё всё ненужное из чрута выпиливали, да, да

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

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

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

Партнёры:

Хостинг:

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

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


	3. "Работа с 32- и 64-разрядными chroot на примере Debian"	+/–
	Сообщение от Anon2 (?), 15-Июн-21, 12:04
	chroot, ну это как бы не о безопасности. Запускаемые в chroot приложения имеют доступ к файловой системе хоста. Ну т.е. штатно не имеют, но элементарно получают доступ, если поставлена именно такая задача (что нештатно и подразумевает злонамеренно). В итоге доступ к хостовому /home/username/.ssh/ можно запретить только если запускать приложения в chroot от пользователя не имеющего права на чтение /home/username/.ssh/ и не имеющего возможности повысить свои привилегии (включая нештатный через уязвимости по повышению привилегий). Хотя справедливости ради, при наличии уязвимостей на всех уровнях, то и из qemu-kvm можно получить доступ к хостовому home/username/.ssh/. Просто это не для китайских ботов и скрипт-киддисов будет задачка.
	Ответить \| Правка \| Наверх \| Cообщить модератору


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


	7. "Работа с 32- и 64-разрядными chroot на примере Debian"	+/–
	Сообщение от Anon2 (?), 20-Июн-21, 11:59
	> ... а так из чрута не выйти. Поясните свою логику? Каким образом у вас появляется эта мысль? В чруте # chroot /proc/1/cwd/ это не то? Естественно запрет запуска chroot в чруте проблемму не решает. При рабработке chroot-а вопросам безопасности не уделялось внимание. chroot для доверенных окружений
	Ответить \| Правка \| Наверх \| Cообщить модератору


	9. "Работа с 32- и 64-разрядными chroot на примере Debian"	+/–
	Сообщение от Павел Отредиез (?), 21-Июн-21, 16:53
	/proc/1/cwd это симлинки. В чруте она указывает относительно newroot.
	Ответить \| Правка \| Наверх \| Cообщить модератору


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


	12. "Работа с 32- и 64-разрядными chroot на примере Debian"	+/–
	Сообщение от Павел Отредиез (?), 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ообщить модератору


	14. "Работа с 32- и 64-разрядными chroot на примере Debian"	+/–
	Сообщение от 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ообщить модератору


	15. "Работа с 32- и 64-разрядными chroot на примере Debian"	+/–
	Сообщение от 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ообщить модератору


	16. "Работа с 32- и 64-разрядными chroot на примере Debian"	+/–
	Сообщение от 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"
	Ответить \| Правка \| К родителю #12 \| Наверх \| Cообщить модератору


	11. "Работа с 32- и 64-разрядными chroot на примере Debian"	+/–
	Сообщение от 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 именно про безопасность. И всегда так было при настройках серверов-сервисов.
	Ответить \| Правка \| К родителю #3 \| Наверх \| Cообщить модератору


	13. "Работа с 32- и 64-разрядными chroot на примере Debian"	+/–
	Сообщение от 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ообщить модератору


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