.png)
Вот типичная schroot.confконфигурация, которую я использую:
[label]
description=whatever
type=directory
personality=linux
preserve-environment=true
directory=/wherever
users=UserForSchrootOnly
profile=desktop_no_tmp
Нет root-usersдирективы.
Отдельные домашние каталоги для schroot env, не использующие /home хоста.
UserForSchrootOnlyЯ вхожу в эти среды schroot с пользователем хостовой ОС . Обычно я добавляю этого пользователя в /etc/sudoers.d/someConfфайлвнутришрут, с линией,
UserForSchrootOnly ALL=(ALL:ALL) ALL
Одна из моих целей этой настройки — иметь достаточно изолированную среду (не для аудита строгой изоляции, но эффективную на практике), как через schroot, так и используя пользователя ОС только для этой цели и больше нигде. С другой стороны, по практическим причинам гораздо проще иметь этого выделенного пользователя, который также будет sudoer, внутри schroot env, конечно.
Пример использования — запуск недоверенного закрытого исходного кода приложения.
Меня беспокоит:
поскольку UserForSchrootOnlyпользователь является sudoer внутри schroot env, возможно ли из-за этого нарушить безопасность хост-системы? Есть ли способ использовать повышение прав sudo внутри schroot env, чтобы получить доступ к чему-либо за пределами schroot или за пределами UserForSchrootOnlyдомашнего каталога хост-системы?
На странице руководства schroot.conf упоминается, что доступ root к chroot представляет серьезный риск; меня не беспокоит неправильное поведение пользователя. Меня беспокоит ненадежное приложение с закрытым исходным кодом, которое использует пользователя sudoer, которого оно запускает.
Я хотел бы отметить, что хотя это кажется идеальным сценарием для песочницы вроде firejail, мне не удалось запустить некоторые приложения с ней, даже добавив параметр --no-profile. Также другие сценарии включают приложения, которым нужны более свежие библиотеки, поэтому мне нужно настроить среду Debian Testing или Ubuntu schroot для запуска недоверенного приложения внутри.