Когда я начинаю firejail, я вижу свой полный домашний каталог. Когда я начинаю firejail --whitelist=~/something, я вижу только somethingсвой домашний каталог. Теперь я хотел бы ограничить больше доступа к системе. Я могу, например, добавить --blacklist=/mediaи это работает как и ожидалось.
Но как поведение по умолчанию определяет это /home/OTHERUSERи /home/*кроме того, что файлы из белого списка скрыты? Я не вижу соответствующего правила в /etc/firejail/*.
И возможны ли разрешенные подкаталоги? Например, --blacklist=/media --whitelist=/media/dataне работает так, как ожидалось, даже когда на странице руководства указано, что белый список переопределяет другие параметры, такие как --read-only.
Являются ли эти правила жестко закодированными в двоичном коде? Если нет, то какое правило это делает?
Пример того, что я хотел бы иметь. Основные правила:
- Дом пустой, за исключением вещей, указанных в профиле.
- Черный список
/media/data - Разрешить символическую ссылку
~/apps ->/media/data/appsтолько для чтения. - Разрешить
/media/data/apps(при необходимости) только чтение.
1, 2 работают, 3 работает только с 4 (вероятно, нормально), но переопределение доступа на чтение для подкаталога запрещенного каталога не работает.
Кажется немного нелогичным, что это должно работать, но на уровне файловой системы mkdir -p foo/bar;chmod 111 foo;ls foo/bar/(где 111это означает, что нет разрешения на чтение (просмотр каталогов) для foo, а работает только исполняемый бит (вход в подкаталоги), даже в случае ls foo/сбоя.
Расширенный сценарий запретит все, кроме белого списка (профиль + /usr, /bin, /lib и т. д.). Еще одна вещь, которая кажется невозможной без root (и тогда само приложение запускается как root), это замена ie /etc/passwd на тот, который не содержит пользователей, что не должно быть известно в тюрьме. /etcсодержит довольно много читаемых данных, которые должны быть скрыты от ненадежных приложений.
Но, возможно, расширенный сценарий действительно оправдал бы использование полного контейнера chroot + userspace-lxc.