LINUX.ORG.RU

Как запретить Portproton доступ в основную систему?

 ,


1

1

Всем привет. Начал недавно освоение Wine и Portproton как его самой результативной модификации. Да, буду виндовые проги запускать. Однако, меня сильно настораживает тот факт, что Wine имеет доступ во всю файловую систему (по крайней мере, к папке пользователя). Поскольку работать предстоит с проприетарным софтом (сиречь «чёрным ящиком»), то мне нужно как-то перестраховаться, сделав так, чтобы сам Wine видел только то, что находится в его папке, и не мог воспринимать всю остальную систему. Как это сделать?

Перемещено hobbit из general



Последнее исправление: hobbit (всего исправлений: 1)

Ответ на: комментарий от Jameson

Я давно не заходил, когда был в последний раз — её ещё не было.

Да и не люблю я гпт на самом деле. По сути, тот же гугл, только замудрённый и навороченный.

BinHex
() автор топика

Для разделения доступов в unix-подобных системах давным давно существует система юзеров, групп и прав доступа к файлам. Тебе осталось только воспользоваться ей. Никакого доп. софта для этого не нужно.

firkax ★★★★★
()
Последнее исправление: firkax (всего исправлений: 1)

Вопрос оказался не таким простым.

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

Но тут оказывается, что эти ребята из порт протона жестко прописали в своем коде при каждом запуске игры пересоздавать ссылки: https://github.com/Castro-Fidel/PortWINE/blob/5473a877147cf6dd116cd917ffce1d1f15355435/data_from_portwine/scripts/functions_helper#L1694

Они там подключают корень, домашнюю папку, папку со стимом, если найдут, а еще все флешки и внешние диски, ну это улет.

В общем то по хорошему надо править код и сделать создание линков опциональным. Ну можно и обойти. Зайти в префикс, удалить созданные линки и создать папки с такими же именами. Тогда их код не сможет создать линки на месте папок.

Вот как у меня в еве, например (у меня порт протон установлен в .portproton, по умолчанию, он ставится в ~/PortProton, так то наверно надо поправить пути под свои):

ls -la /home/me/.portproton/data/prefixes/EVE_ONLINE/dosdevices

Видим линки:

lrwxrwxrwx 1 me me   14 окт 19 02:38 h: -> ../../../../../
lrwxrwxrwx 1 me me   20 окт 19 02:12 z: -> ../../../../../../../

Удаляем их и создаем директории:

rm /home/me/.portproton/data/prefixes/EVE_ONLINE/dosdevices/h:
rm /home/me/.portproton/data/prefixes/EVE_ONLINE/dosdevices/z:
mkdir /home/me/.portproton/data/prefixes/EVE_ONLINE/dosdevices/h:
mkdir /home/me/.portproton/data/prefixes/EVE_ONLINE/dosdevices/z:

Но это надо делать для каждого префикса и для безопасности сразу после создания префикса, но до запуска установки проприетарного по

masa
()

Поставить его из Flatpak, а там через Flatseal можно выделить петушинный угол для хранения протоновского добра, епта, а доступ ко всему остальному запретить. Но у меня под мусор винда есть, где не хранится ничего важного, ее может ломать кто угодно и зачем угодно… Ну ты игр боишься с торрентов, что отчасти правильно, но я не знаю случаев когда кто-то пихал вирусню с прицелом на пользователей вайна

rtxtxtrx ★★
()
Последнее исправление: rtxtxtrx (всего исправлений: 1)
Ответ на: комментарий от masa

Симлинки никак не влияют на доступность всей файловой системы, они для обеспечения совместимости а не для прав. И вообще, wine никаким образом правами доступа не управляет, не надо пытаться его использовать в этой роли. Весь софт, запущеный через wine, имеет ровно те же права доступа как любой другой софт, запущеный этим юзером. Для прав доступа есть chmod chown chgrp и там всё просто.

firkax ★★★★★
()
Ответ на: комментарий от masa

Мне казалось подобные глупости про безопасность остались в прошлом веке. Если ты хочешь защищаться от проги, то думать что она чего-то там не знает или не догадается - идиотизм. Предполагай что враг знает и про /etc и про всё что можно у тебя напортить. И делать линуксовые сисколлы никто ей не мешает, если ты этого не знал. Повторяю, те симлинки только в целях эмуляции виндоокружения, ни в коем случае нельзя на них рассчитывать как на способ управления правами.

firkax ★★★★★
()
Ответ на: комментарий от masa

Там нет никакого слоя виртуализации, прога не внутри wine, а точно так же на хосте. Считай wine библиотекой с реализацией апи винды и виндового загрузчика. Апи линукса никуда не девается и вообще юзерспейсным способом его отключить невозможно. Более того, там не только апи линукса есть (сисколлы) но и обычное линуксовое libc тоже подгружено и функции из него можно просто вызывать (если узнать их адрес) чтобы не возиться с реализацией обёрток над сисколлами (но это уже удобства, на список возможностей не влияет).

firkax ★★★★★
()
Последнее исправление: firkax (всего исправлений: 1)
Ответ на: комментарий от BinHex

Молодец. Но ты чет бредишь:

❯ flatpak info --show-permissions net.davidotek.pupgui2 | grep files
filesystems=~/.var/app/com.heroicgameslauncher.hgl/config/heroic/gog_store;~/.var/app/net.lutris.Lutris/data/lutris/runners;~/.icons:ro;~/.local/share/lutris/runners;~/.var/app/net.lutris.Lutris/data/lutris/runtime/dxvk;xdg-config/kdeglobals:ro;~/.local/share/lutris/runtime/dxvk;/usr/share/icons:ro;~/.var/app/com.heroicgameslauncher.hgl/config/heroic/tools;~/.var/app/com.usebottles.bottles/data/bottles/runners;~/.var/app/net.lutris.Lutris/config/lutris:ro;~/.var/app/com.valvesoftware.Steam/data/Steam;~/.kshrc;~/stl:create;~/.var/app/com.heroicgameslauncher.hgl/config/heroic/GamesConfig;~/.zshrc;~/.local/share/lutris/pga.db:ro;~/snap/steam;~/.var/app/com.heroicgameslauncher.hgl/config/legendary;~/.config;~/.var/app/com.heroicgameslauncher.hgl/config/heroic/store_cache;~/.local/share/lutris/runtime/vkd3d;~/.local/share/Steam;~/.var/app/net.lutris.Lutris/data/lutris/runtime/vkd3d;~/.bashrc;~/.steam;~/.var/app/net.lutris.Lutris/data/lutris/pga.db:ro;~/.var/app/com.heroicgameslauncher.hgl/config/heroic/sideload_apps;

Я поставил этот протон. Он и так в петушинном угле. Я думал он там доступ имеет ко всему хомяку и тп. Но нет:

flatpak enter net.davidotek.pupgui2 sh
zsh: correct 'sh' to 'ssh' [nyae]? n
sh-5.2$ ls -ahl
total 4.0K
drwxr-xr-x 7 sergey sergey  160 Oct 20 06:41 .
drwxr-xr-x 3 sergey sergey   60 Oct 20 06:41 ..
-rw-r--r-- 1 sergey sergey    1 Oct 30  2023 .bashrc
drwxr-xr-x 1 sergey sergey 4.4K Oct 20 05:19 .config
drwxr-xr-x 1 sergey sergey   60 Sep  4 10:39 .icons
drwxr-xr-x 3 sergey sergey   60 Oct 20 06:41 .local
drwxr-xr-x 3 sergey sergey   60 Oct 20 06:41 .var
drwxr-xr-x 1 sergey sergey    0 Oct 20 06:41 stl

Оно лишь только твои конфиги может своровать:

sh-5.2$ ls -ahl .config
total 572K
drwxr-xr-x 1 sergey sergey 4.4K Oct 20 05:19  .
drwxr-xr-x 7 sergey sergey  160 Oct 20 06:41  ..
-rw-r--r-- 1 sergey sergey    0 Mar 27  2023  .gsd-keyboard.settings-ported
drwx------ 1 sergey sergey  766 Oct 20 05:20 'Code - OSS'
drwx------ 1 sergey sergey  254 May  8  2023  Electron
...

Потому что разраб-даун разрешил доступ ко всему каталогу ~/.config. В общем остальную твою файловую систему приложение не видит. Но в теории может чего положить в ~/.config/autostart или ~/.config/systemd/user/… Просто запрети ему доступ в этот каталог.

rtxtxtrx ★★
()
Ответ на: комментарий от BinHex

Удали протон и поставь Boxes.

Он имеет доступ только к иконкам:

flatpak info --show-permissions com.usebottles.bottles | grep files
filesystems=~/.icons:ro;/usr/share/icons:ro;

То что из приложения в контейнерах можно открыть любой файл, не означает что оно к нему или файловой системе имеет доступ. Если кратко, то ты через порталы ТОЛЬКО ТЫ САМ даешь временный доступ к тому или иному файлу, к остальным, если они не перечислены в permissions flatpak-процесс и все процессы, порождаемые им, доступа не имеют.

Так что, все-таки думать надо, если к чему-то даешь доступ.

На питоне оно так выглядит:

import gi
gi.require_version('Gtk', '3.0')
from gi.repository import Gtk

dialog = Gtk.FileChooserNative(
    title="Open File",
    parent=None,
    action=Gtk.FileChooserAction.OPEN,
    accept_label="_Open",
    cancel_label="_Cancel"
)

# Само приложение не видит файлы по которым ты лазаешь
response = dialog.run()
if response == Gtk.ResponseType.ACCEPT:
    # Оно может прочитать файл только если ты ему разрешишь
    file_path = dialog.get_filename()
    print(f"Selected file: {file_path}")
dialog.destroy()
rtxtxtrx ★★
()
Последнее исправление: rtxtxtrx (всего исправлений: 2)
Ответ на: комментарий от rtxtxtrx

Во Flatpak файл этот монтируется вроде куда-то в /run от туда и читается. Ток непонятно размонтиркется ли он или так и остается примонтированым пока не закроешь приложение

rtxtxtrx ★★
()
Ответ на: комментарий от masa

Не делай так, во-первых это создаст проблемы с разрешением unix путей в dos, во вторых не уберёт доступа в корень - он всё ещё будет дрст4пен другими путями.
Используй контейнеризацию, например, steam runtime с pressure-vessel кониейнером, она сейчас рекомендуется для игр т.к позволяет использовать системные драйвера и не создавать им конфликты зависимостей, а так же избежать хранения нескольких разных версий библиотеки в памяти если в системе библиотека новее.
Можно что-тотаналогичное сделать вручную, например unshare -u запустит shell в user namespace с фейковым рутом, замаппленным на твоего юзера. Внутри можно сделать chroot, тем самым ограничив досиуп к ФС и уже внутри него setuid на непривелигированного пользователя. Так кониейнеры и работают. После setuid процесс уже не может выбраться из chroot.
Так же unshare -p скрывает хостовые процессы и делают создаваемый процесс инитом в новом контейнере, unshare -m отвязывает дерево монтирования, что позволяет монтировать в контейнере ФС незаметно для хоста.
Чтобы сделать chroot - нужно создать «клон» хостовой системы с теми файлами которые нужны для работы протона, но тебе при этом не жалко показывать их запускаемому в нём софту. Например, можно пробросить /etc, /usr, и прочее с -o bind, а так же всё нужное chroot'у: /dev, /dev/pts, /proc, /run например
Некоторые контейнеры вместо этго делают копию или вообще свой дистр с библиотеками нужных версий.
Стимовский контейнер делает хитрее - он сравнивает версии библиотек и подсовывает те, что новее. Т.к библиотеки должны быть обратно совместимыми - это позволяет получить наиболее универсальный контейнер. fatpak вместо этого тащит целиком другой дистр, причём каждый раз разных версий под разные приложения. Результат - беги за новым диском и оперативкой побольше. Забавно, но из-за этого дебианщики очень любят fatpak, ведь если у них в дебиане что-то не работает из-за древних версий - fatpak притащит с собой рабочий софт

mittorn ★★★★★
()
Последнее исправление: mittorn (всего исправлений: 1)
Ответ на: комментарий от firkax

И делать линуксовые сисколлы никто ей не мешает, если ты этого не знал

Ну кроме seccomp лол. Никто не мешает перед запуском запретить через eBPF доступ за пределы нужных директорий. Контейнеры так примерно и работают.

hateyoufeel ★★★★★
()
Последнее исправление: hateyoufeel (всего исправлений: 1)
Ответ на: комментарий от hateyoufeel

Внешними средствами что-то запретить конечно можно, но wine тут ни при чём. Точно так же можно и линуксовой проге что-то запретить. Об этом и речь - wine за права не отвечает, надо использовать другие инструменты.

firkax ★★★★★
()
Ответ на: комментарий от Kapusha

sudo надо вообще удалить из системы и забыть про него, это вредоносная утилита - она насаждает виндузятные привычки и дыры.

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

Правильный способ - логиниться в отдельного юзера с другого tty (ctrl-alt-f3 итд). Заодно решается ещё одна проблема - если это фулскрин игра и у неё проблемы со сворачиванием, тут это будет несущественно.

firkax ★★★★★
()
Ответ на: комментарий от firkax

Внешними средствами что-то запретить конечно можно, но wine тут ни при чём.

Да нет, wine мог бы это использовать. Никто не мешает wine при старте ограничить доступ к ФС только путями, упомянутыми в конфиге этого самого wine.

hateyoufeel ★★★★★
()
Ответ на: комментарий от hateyoufeel

Стрёмная идея. Во-первых, незачем устраивать мешанину из разнородных вещей. Во-вторых, подозреваю столкнёшься с рядом проблем при попытке это реализовать дословно в том виде как ты написал.

firkax ★★★★★
()
Ответ на: комментарий от firkax

Стрёмная идея.

Норм идея.

Во-первых, незачем устраивать мешанину из разнородных вещей.

Какую мешанину? Wine уже позволяет ограничить доступ к ФС через монтирование «виндовых» дисков в настройках.

Во-вторых, подозреваю столкнёшься с рядом проблем при попытке это реализовать дословно в том виде как ты написал.

В каком месте столкнусь? Wine отлично работает внутри bubblewrap, стимовские игры с протоном так и запускаются. Осталось сделать один шаг вперёд и совместить одно с другим.

hateyoufeel ★★★★★
()
Ответ на: комментарий от hateyoufeel

И ты туда же? Это не ограничение доступа к фс, это обёртка совместимости. Использовать этот список в качестве списка ограничения доступа - плохая идея.

bubblewrap

Я ни разу эту штуку не пробовал, но почти уверен, что в этой схеме bubblewrap не берёт свои настройки из конфига wine и вообще никак от конфига wine не зависит.

Конфиг wine (точнее, множество мест от которых зависит его работа) делались вообще без оглядки на безопасность, не надо сувать его ни в какие инструменты безопасности. Можешь сделать наоборот: в соответствии с неким внешним файлом, для wine вообще недоступным, сначала генерить настройки для wine (с нуля), накладывать ограничения, и потом запускать wine. Наоборот - нельзя.

firkax ★★★★★
()
Ответ на: комментарий от firkax

Я ни разу эту штуку не пробовал, но почти уверен, что в этой схеме bubblewrap не берёт свои настройки из конфига wine и вообще никак от конфига wine не зависит.

Да, ты прав. Там примерно так и происходит.

Можешь сделать наоборот: в соответствии с неким внешним файлом, для wine вообще недоступным, сначала генерить настройки для wine (с нуля), накладывать ограничения, и потом запускать wine. Наоборот - нельзя.

Почему нельзя? Хочешь сказать, что софт внутри wine может изменять настройки монтирования дисков? Потому что я такого не припомню.

hateyoufeel ★★★★★
()
Ответ на: комментарий от hateyoufeel

То что софт изнутри wine может переписать эти симлинки это самая очевидная проблема, и чтоб её избежать там придётся организовывать read-only. Но я почти уверен что не единственная, поэтому уточнять не стал. Просто не надо опираться на wine для безопасности ни с какой стороны, так проще.

firkax ★★★★★
()
Последнее исправление: firkax (всего исправлений: 1)
Ответ на: комментарий от firkax

То что софт изнутри wine может переписать эти симлинки это самая очевидная проблема, и чтоб её избежать там придётся организовывать read-only.

Ну ты понимаешь же, что вот как раз предлагаемым мной ограничением этого софта эта ситуация и лечится? Ни при каких условиях вендовая прога не должна лезть в $WINEPREFIX.

hateyoufeel ★★★★★
()
Ответ на: комментарий от hateyoufeel

Что значит не должна лезть в префикс? wine из префикса как раз и узнаёт, куда замапить виндовую букву диска. И реестр там же. wine неотделим от виндопроги, это всё один процесс, я уже писал выше что самое разумное считать его просто пачкой библиотек + PE-загрузчиком. Главная в этой схеме виндопрога, код wine (в том же процессе, отдельные права ему не выдать) получает управление только когда она обращается к winapi.

firkax ★★★★★
()
Последнее исправление: firkax (всего исправлений: 1)
Ответ на: комментарий от firkax

Что значит не должна лезть в префикс? wine из префикса как раз и узнаёт, куда замапить виндовую букву диска.

Нууу иииии?

Главная в этой схеме виндопрога, код wine (в том же процессе, отдельные права ему не выдать) получает управление только когда она обращается к winapi.

Во-первых, не совсем так. У wine есть пачка сервисных процессов типа wineserver и собственной реализации svchost. Они висят в памяти всё время, пока жива виндовая прога. Но это не так важно. Во-вторых, код wine запускается ДО кода проги. Соответственно, никто не мешает при запуске wine открыть всё что нужно (на чтение), дропнуть привилегии и только после этого передавать работу в прогу.

hateyoufeel ★★★★★
()
Ответ на: комментарий от hateyoufeel

Можно просто не городить эти костыли и сделать нормально - ограничивать права предназначенными для этого инструментами, не пытаясь закостылить ограничитель прав в динамический PE-линковщик.

Я не отрицаю, что при желании можно там нагородить всякого ужаса и оно даже будет вроде работать, но не надо так делать.

firkax ★★★★★
()