Sandbox "privileges" file

chrisnharvey commented 8 years ago

As briefly discussed here. It would be nice if we could have a file that defines which "privileges" an AppImage needs when running in a sandbox.

For example:

May use the network
May read $HOME
May write $HOME/.local
May write all of $HOME

Similar to how Android and iOS ask for the users permission when an app is trying to do something like "Access the Camera" or "Access Contacts".

probonopd commented 8 years ago

Another approach would be the use of portals. https://lwn.net/Articles/562138/ https://mail.gnome.org/archives/gnome-list/2014-January/msg00000.html

zzo38 commented 2 years ago

Portals aren't good enough. For example, you may need to:

Call popen to execute a command which is either specified interactively by the user or stored in a user-defined configuration file.
Use non-Unicode file names, and use non-Unicode text in other ways.
Access files whose names start with the selected file name, followed by - or . and other text, such as a SQLite journal file or SQLite WAL file.
Access files, programs, devices, network interfaces, dynamic libraries, etc whose names are specified in a user-defined configuration file, command-line arguments, or environment variables.
Need different permissions depending on the command-line switches given to the program when it is started.

totchi-lagawi commented 3 months ago

Portals have a major problem : they force developers to modify their application just for AppImages (this is useless for .deb or .rpm packages, and on Windows and macOS), which is problematic especially for cross-platform applications.

Firejail uses a profile database. It however means that a completely new application won't work until its profile is added to the Firejail database. And completely unsupported apps won't work in sandbox without requiring the user to make custom profiles.

Personally, I would use the same approach as macOS : there is one default profile for every AppImages, and app developers can specify a "privilege" file in their package if their app needs more permissions. This allows developers to support AppImage sandboxing without modifying its codebase, and keeps sandboxing easy and transparent for the user.

Samueru-sama commented 3 months ago

Since this was bumped

I recommend you use aisap if you want to sanbox appimages: https://github.com/mgord9518/aisap

It has a internal database of appimages. And also has levels of permissions

Also in AM we expanded it further, by default all appimages get level2 sandbox and access to respective directory in XDG_CONFIG_HOME and XDG_DATA_HOME of the application, meaning that after being sandboxed you don't have to move the configuration files of the application to the fake home since they automatically get added, it also gives access to theming related directories as well.

zzo38 commented 3 months ago

In any cases, it will be necessary that the user might override some or all of the permissions (althoug this feature does not need to be a part of AppImage itself; it can be handled by separate programs). (It would be helpful to also allow the user to substitute I/O; while stdin/stdout does a part of that, it won't do everything, e.g. a program might request camera access but you will want to grant permission to read a video file instead, or to read the output of a different program that applies effects to the picture received from the camera. This also does not need to be a part of AppImage, and should be done by other parts of the oeprating system.)

Additionally, it might sometimes make sense to allow priviliegs to be grouped together (and allow the definitions of the groups to be altered by system administrators, or sometimes by other things too such as environment variables), e.g. a program that uses SDL can specify its use of the "SDL1(video,audio)" privilege group, to indicate that it uses SDL1 with the video and audio subsystems; the author of a program will not have to worry about how exactly that maps to the privileges that SDL1 uses on the target computer. (Another example would be X vs Wayland in versions of SDL that support both.)

The "aisap" permission levels are similar than the grouping that I mentioned above, although it is a simpler way which does not consider that the definitions of such groups may sometimes need to be changed according to circumstances. In addition, my comment on July 16 mentions additional considerations which may be required for some programs (my "Free Hero Mesh" software requires all five of those considerations).

It is helpful for AppImage files to be able to optionally include a sandbox permissions file, so that the user can know which permissions are required when using other programs to implement the sandbox.

probonopd commented 3 months ago

The way I envision it:

If the user uses a sandbox for AppImage, than the sandbox should check for the presence of a a "privilege" file in the AppImage
If that file is there, then the sandbox software shows a dialog when the application is run for the first time, showing which privileges the application requests, asking the user if he agrees
If yes, the AppImage is executed and the question is not asked again next time
If no, the AppImage is not executed and the question is asked again next time
To keep things simple for application authors and users, users should not be bothered to select the individual privileges, just agree/disagree overall

probonopd commented 3 months ago

What should be in a hypothetical privileges.conf?

network = true
read_home = true
write_home = true
audio = true
wayland = true
x11 = true
dbus = true
...

Samueru-sama commented 3 months ago

Aisap also accepts individual permissions from a config file.

We don't use it in AM though, since the sandbox script that gets put in PATH can already be modified to add/remove permissions.

Also the .desktop of aisap contains this, which I don't know if it ended up being fully implemented:

[X-App Permissions]
Level=0

It means that you can request a specific sandbox level from .desktop file in the AppImage.

totchi-lagawi commented 3 months ago

If a "privilege" file is added, it shouldn't use the format of any existing sandbox privilege file, to not give the priority to that sandbox.

I think that sandbox software should also see if the AppImage is signed, and if it isn't it should show a warning when it asks the users to agree the permissions of the app. Furthermore, it should also look for "dangerous" permissions, eg. read-write access to the full filesystem, and warn the user for them.

totchi-lagawi commented 2 months ago

After thinking for a while, I propose the following : When a user downloads and run an application for the first time, the system (in that order) :

Searchs for a system (maybe user-defined) profile for the app (first at a user-specific location, then at a system location)
Searchs for a profile inside of the application
Apply the default profile (that should work but will probably break things)

If the profile found was never used, a dialog should be shown to the user, who can then allow or deny specific permission (instead of saying I agree to all or I can't use sandbox). In addition to that, if the system detects a "dangerous" permission (e.g. read-write access to the full filesystem), a warning is put on that dialog. If the used profile is modified, then the system only shows the new permissions, if there are none the new profile is automatically used.

One thing that could be added is the ability to specify if the permission is required or optional.

By "system" I mean any wrapper around the execution of an AppImage.

AppImage / AppImageSpec

Sandbox "privileges" file #5