The OpenNET Project / Index page

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

Работа с 32- и 64-разрядными chroot на примере Debian
Я работаю в 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
 
11.06.2021 , Автор: Павел Отредиез
Ключи: chroot, debian / Лицензия: CC-BY
Раздел:    Корень / Безопасность / Помещение программ в chroot

Обсуждение [ Линейный режим | Показать все | RSS ]
  • 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 для доверенных окружений

     
     
  • 5.9, Павел Отредиез (?), 16:53, 21/06/2021 [^] [^^] [^^^] [ответить]  
  • +/
    /proc/1/cwd это симлинки. В чруте она указывает относительно newroot.
     
     
  • 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.

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

     
  • 4.17, anonymous (??), 10:30, 16/07/2021 [^] [^^] [^^^] [ответить]  
  • +/
    Ещё всё ненужное из чрута выпиливали, да, да
     
  • 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 адресах и поверх запустить важный хлам. С возможностью получить память и процы обратно сразу в любой момент без отдельных телодвижений.

    Под описание, из этой троицы, хорошо подходят контейнеры. Чрут не столь интересен.

     

  • 1.20, Аноним (20), 01:55, 19/09/2021 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Открой для себя lxc и не мучайся с chroot.

     
  • 1.21, sods (?), 15:55, 29/09/2021 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    открой для себя docker и не мучайся с chroot
     


     Добавить комментарий
    Имя:
    E-Mail:
    Заголовок:
    Текст:




    Партнёры:
    PostgresPro
    Inferno Solutions
    Hosting by Hoster.ru
    Хостинг:

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