search

mgord9518 / aisap

Tool to make sandboxing AppImages easy
MIT License
32 stars 2 forks source link

Warning: ConnectToCompositor() try again : Connection refused (Likely me not knowing how to use this 😅) #6

Closed Samueru-sama closed 2 months ago

Samueru-sama commented 3 months ago

Hello, I'm testing this project with the librewolf appimage.

Running manually with ./aisap-0.9.8-alpha-x86_64.AppImage --trust-once --no-data-dir ./librewolf works perfectly without errors.

However I tried running it with the example profile.ini file this way:

./aisap-0.9.8-alpha-x86_64.AppImage --profile ./profile.ini --trust-once ./librewolf

And I just get a bunch of Warning: ConnectToCompositor() try again : Connection refused errors. And I don't know what I'm missing. shouldn't this example profile be enough already?

Amazing project, I want to integrate it into AM: https://github.com/ivan-hc/AM

We already launch all appimages thru symlinks that point to /opt/application so aisap integration should be as simple as a wrapper script that replaces the original symlink!

Is there a way configure it to at least allow all applications launched with it access to $XDG_CONFIG_HOME and xdg-downloads as bare minimum?

Also does the sandbox allow following symlinks? I have also been thinking of symlinking the necesary config directories to allow files to follow the system theme and that way not allow all of $XDG_CONFIG_HOME to be read.

Samueru-sama commented 3 months ago

Btw shouldn't the .desktop file inside the aisap appimage contain NoDisplay=true ? Because running said file just causes a terminal window to open and close as aisap runs and exits instantly.

mgord9518 commented 3 months ago

The only differences seem to be that the example allows Wayland permission and the baked-in LibreWolf permissions grant dbus, so my guess is either LibreWolf is detecting that you're running Wayland and trying to connect but lacks the permissions, or it's failing because a lack of dbus permissions.

Under aisap/profiles/profile_database.json are all the permissions baked into aisap, so that's where you can compare them. I believe when I created the LibreWolf entry it didn't support Wayland but this might've changed.

Giving base permssions, such as default access to directories should also be possible. I'd try using the CLI flags on top of whatever profile file you're already using, they should be overwritten per-launch. I would be really careful about XDG_CONFIG_HOME or anything where multiple apps may store configurations as it could allow malware to read and edit possibly sensitive information from other applications.

Symlinks should also be followed, if they aren't then I'd consider it a bug

As far as NoDisplay, I suppose it should be set for the time being since aisap is currently CLI-only. In the future I'll probably make a simple GUI dialog that allows editing permissions for integrated apps.

Samueru-sama commented 3 months ago

I am not using wayland btw.

or anything where multiple apps may store configurations as it could allow malware to read and edit possibly sensitive information from other applications.

I understand, I'm having a discussion about adding aisap here: https://github.com/ivan-hc/AM/issues/659

Iirc macos does something similar where ~/.library is still a free for all, I know this is an excuse but I don't want perfection to be my enemy.

Also XDG_CONFIG_HOME should only be used to store config data, but chromium and others use it to store everything 😫

I'd try using the CLI flags on top of whatever profile file you're already using, they should be overwritten per-launch.

Is it possible to use only CLI flags to allow access to certain directories? Because this way the script per application can easily be edited to give or remove permissions.

And btw yuzu has had a terrible death, and has been replaced for suyu, just letting you know if you could please add suyu to have the same rules as yuzu.

Thank you so much for making this. I didn't know this project existed until a few weeks ago.

Omg the thing was right on my face, it is the --add-file flag

mgord9518 commented 3 months ago

Is it possible to use only CLI flags to allow access to certain directories? Because this way the script per application can easily be edited to give or remove permissions.

Yup! You can use the CLI flags to toggle any permission, which is what I did while working to create the baked-in profile library. I'll add Suzu and other popular Yuzu forks.

And of course! I'm really happy to see some people find it useful

Samueru-sama commented 3 months ago

Something like this is what I'm likely going to use as a default template, I will no longer give full access to the xdg directories, and also each app now gets its own home instead of sharing one: 

#!/bin/sh

APPEXEC="$(readlink $(command -v deadbeef-devel-appimage))"
SANDBOXDIR="${SANDBOXDIR:-$HOME/.local/am-sandboxes}/$(echo "$APPEXEC" | awk -F "/" '{print $NF}')"
DATADIR="${XDG_DATA_HOME:-$HOME/.local/share}"
CONFIGDIR="${XDG_CONFIG_HOME:-$HOME/.config}"

mkdir -p "$SANDBOXDIR"
exec aisap --trust-once \
--level 2 \
--data-dir "$SANDBOXDIR" \
--add-file "$DATADIR"/Themes \
--add-file "$DATADIR"/icons \
--add-file "$CONFIGDIR"/gtk3.0 \
--add-file "$CONFIGDIR"/gtk4.0 \
--add-file "$CONFIGDIR"/kdeglobals \
--add-file "$HOME"/.local/lib \
--add-socket x11 \
--add-socket wayland \
--add-socket pulseaudio \
--add-socket network \
--add-device dri \
$APPEXEC

Works fine with librewolf, I don't have broken icon or theme.

However when I test this with a deadbeef-appimage that I maintain, for some reason the sandboxed home for it doesn't get created, that is why I added that mkdir thinking that was the issue but nope, it is empty.

And I checked where the appimage is located and the fakehome isn't there either.

EDIT: Also I noticed that theming on qt apps is broken. Even when I give full access to $XDG_CONFIG_HOME and $XDG_DATA_HOME and /usr 🤔

EDIT2: It may not be all qt apps, what I tested was pavucontrol-qt and its home doesn't get created either, same issue as with deadbeef.

mgord9518 commented 3 months ago

Strange. I allow some directories like ~/.themes by default for level 1 and 2, if we can figure out what all is needed to make the theming work I'd be happy to add it

I have no clue why the fake home isn't being created, it should be for any permissions not explicitly specifying no home (which would only be used for simple games and the like -- where there is no need for saving data). I'll try to investigate this weekend if I have the time

Samueru-sama commented 3 months ago

I think ~/.themes is now obsolete and $XDG_DATA_HOME/themes is used instead.

However the issue is very likely that the fake home is not being made. It seems that applications that are not in the internal aisap list don't get their own home made.

For example I sandboxed and launched yuzu:

image

While this is what happens when I do the same to suyu:

image

Both are being launched with the following flags: 

exec aisap --trust-once \
--level 2 \
--data-dir "$SANDBOXDIR" \
--add-file "$DATADIR"/themes \
--add-file "$DATADIR"/icons \
--add-file "$CONFIGDIR"/gtk3.0 \
--add-file "$CONFIGDIR"/gtk4.0 \
--add-file "$CONFIGDIR"/kdeglobals \
--add-file "$CONFIGDIR"/qt5ct \
--add-file "$CONFIGDIR"/qt6ct \
--add-file "$CONFIGDIR"/Kvantum \
--add-file "$HOME"/.local/lib \
--add-socket x11 \
--add-socket wayland \
--add-socket pulseaudio \
--add-socket network \
--add-device dri \
"$APPEXEC" "$@"

(Where $DATADIR and $CONFIGDIR are the respective XDG_DATA directory or it's default location if the xdg variables are not set).

Another thing I noticed is that I have $XDG_CONFIG_HOME set to $HOME/.local/config instead of the default ~/.config and even though I tested giving my web browser (Brave) entire access to $XDG_CONFIG_HOME it still uses the .config directory inside the fakehome instead of the .local/config which it does have access to. As if the env variable gets unset.

Samueru-sama commented 3 months ago

I noticed you fixed the fake home dir not being created.

Thank you! I'm so happy this tool exists.

Samueru-sama commented 3 months ago

Here are some of my findings so far.

dbus instead is located at /tmp/dbus-G201hrxOej on my system, and it seems to have a random name? Well I guess this is the kind of stuff you run into when not using systemd lol. I fixed it with this terrible hack: --add-file /tmp/"$(ls /tmp | grep dbus || echo "nodbus")" and if you wonder why I added that echo "nodbus" in case the script fails to find dbus in tmp, that is because of the next issue:

*EDIT: Nvm `/tmp/dbus` also works. Much better than my original hack.** 

/run/user/1000/aisap/mount/a068b5ba7bdbc439296f109ee8ccf648
/run/user/1000/aisap/tmp/a068b5ba7bdbc439296f109ee8ccf648
bwrap: execvp /tmp/.mount_a068b5ba7bdbc439296f109ee8ccf648/AppRun: No such file or directory
exited non-zero status: exit status 1

I ran into this issue because xfce4-screenshooter is hardcoded to keep the screenshots in /tmp (That's a terrible decision from xfce) and I wanted to sandbox a tesseract appimage that I have to do OCR on some screenshots. I fixed this by setting the TMPDIR env variable to a directory that I only have access to since that is the only way to change the location for the screenshooter.

We fixed this by making the script instead use XDG_DOWNLOAD_DIR="$(xdg-user-dir DOWNLOAD 2>/dev/null)" and then: --add-file "${XDG_DOWNLOAD_DIR:-~/Downloads}"

We also had to put a check to unset those variables as it is possible for them to get defined as$HOME. Ivan found a weird bug in fedora where even though his user-dirs.dirs had the clear names of each xdg directory, some were being defined as $HOME/ with a trailing slash. 🙃 So watch out against this if you decide to implement full xdg user dirs support.

Also deadbeef hates me, I was surprised that my music player is the only app that is literary impossible to sandbox, the thing needs to launch itself when running some playerctl shell scripts that I have.

You are free to close this issue, everything else is now suggestions with only the exception of the crash when giving access to /tmp and the controller not working on level 2 with ppsspp. I never figured out why I had that issue with librewolf, but I'm launching librewolf with a script now instead anyway.

Thanks again for this tool.

ivan-hc commented 3 months ago

@mgord9518 This is really an amazing project, thank you for providing it!

This is how @Samueru-sama have implemented this in "AM" and how it works:

https://github.com/ivan-hc/AM?tab=readme-ov-file#sandbox-an-appimage

Samueru-sama commented 3 months ago

update: deadbeef can actually be sandboxed and still run scripts.

The problem is that a sandboxed appimage can't launch another appimage, and I have both playerctl and dunst as an appimage which are part of my scripts.

mgord9518 commented 2 months ago

@Samueru-sama Ah, yeah that's unfortunate. I've been brainstorming the issue of sandboxed AppImages launching other AppInages/ using FUSE.

The closest I've thought of is having IPC within the sandbox that would ask aisap to mount another AppImage and expose it, but this would probably take extra logic in the program itself. Either that or I might be able to make a small fusermount wrapper that would be exposed to the sandbox. It'll take some research but it should be possible.

Samueru-sama commented 2 months ago

@Samueru-sama Ah, yeah that's unfortunate. I've been brainstorming the issue of sandboxed AppImages launching other AppInages/ using FUSE.

The closest I've thought of is having IPC within the sandbox that would ask aisap to mount another AppImage and expose it, but this would probably take extra logic in the program itself. Either that or I might be able to make a small fusermount wrapper that would be exposed to the sandbox. It'll take some research but it should be possible.

So far I worked around it by disabling the sandbox in dunst and playerctl and launching them with the --appimage-extract-and-run flag which bypasses fuse.

Also I can get around the dunst appimage issue by using notify-send instead of dunstify in that case notify-send uses dunst to send the notification and when this is done I don't have the fuse errors interestingly.

So to resume, here are the only issues that remain: 

--rm-file "${XDG_DESKTOP_DIR:-~/Desktop}" \
--add-file "${XDG_DOCUMENTS_DIR:-~/Documents}":rw \
--add-file "${XDG_DOWNLOAD_DIR:-~/Downloads}":rw \
--rm-file "${XDG_GAMES_DIR:-~/Games}" \
--rm-file "${XDG_MUSIC_DIR:-~/Music}" \
--rm-file "${XDG_PICTURES_DIR:-~/Pictures}" \
--rm-file "${XDG_VIDEOS_DIR:-~/Videos}" \

If the user doesn't use english in their PC, they still get access to XDG_DOWNLOAD_DIR even when aisap will only gives access to ~/Downloads.

We also had to put a check to make sure that these directories don't get defined as $HOME or $HOME/ as that can happen.

It also means that this overwrites the default rules that aisap applies, as if they don't want to give access to ~/Downloads the rule becomes --rm-file.

I also added XDG_GAMES_DIR which isn't part of the spec but it is commonly used and requested to be added to xdg user dirs, so I just went and added it anyway lol, I actually had a ~/Games directory before I discovered aisap.

Samueru-sama commented 2 months ago

@mgord9518 Hey the recent changes broke something.

When I try to launch ppsspp I get :: failed to get permissions from profile: strconv.Atoi: parsing "": invalid syntax which didn't happen before.

I also get the same error when launching cpu-x and libreoffice, it seems that the issue of applications not in the database came back in a different way. (Although that wouldn't explain why ppsspp is affected?)

Also I discovered that ppsspp didn't work with the controller on level 2 because I forgot to add "input" in devices in the database 😅 I was making the changes and adding more apps to the database when I ran into this new issue when testing, I thought for a sec that I broke something in the database and tested the appimage released here and I get the same issue still.

mgord9518 commented 2 months ago

@Samueru-sama oops, looks like I had it spitting an error where it shouldn't have. It should be fixed in the latest commit. No clue about PPSSPP, I wasn't able to replicate the error with it

Samueru-sama commented 2 months ago

@Samueru-sama oops, looks like I had it spitting an error where it shouldn't have. It should be fixed in the latest commit. No clue about PPSSPP, I wasn't able to replicate the error with it

The ppsspp error was just that it was missing the input device in the database, I added it in the recent pr.

Thank you for fixing this quickly.

edit: If you meant that you weren't able to replicate the :: failed to get permissions from profile: strconv.Atoi: parsing "": error that's odd. iirc ppsspp has qt and sdl builds maybe it only happens with one of those.

But the issue is gone in the latest version of aisap!

EDIT: I spoke too soon, I will close this and instead an issue for ppsspp.