Partially sandboxing apps with permission intersections

[minkanjin]

So this is a bit more of a thought experiment to see if I understand the permission system correctly. I had the idea that it might be possible to get better security by “sandboxing” apps by using permission intersections. i.e. Both the current user and the app’s owner is used to determine access.

The idea is that both the user and the executable must have permissions to access to a file. This would of course require that the app has its own user account. Then the user adds the app to the ACL of a file the user owns. This way the app can only access files that is owned by the current user, and was given explicit permissions to the app by the user.

Since root has access to almost everything (except sometimes things mounted through fuse), any executable owned by root would have access to everything the current user has access to.

If such apps each have their own user accounts, it makes it possible to control which users have access to which apps by adding users to the app’s group. So that is also added security.

As far as I know, the sticky bit is not used for executables. So maybe the sticky bit can be repurposed to enable the old behaviour for executables that have not yet been ported to the new way of doing things. This would of course require us to trust whoever installed the executable, but that is also a problem with the current system anyway.

I think this might give part of the sandboxing that flatpak has. I suspect this is already implemented in one of the extended permission systems, but most people don’t know how to use those. This seems like a fairly simple way to bring this feature to everyone.

[szatox]

Congratulations, you have just invented suid. It is actually what su and sudo use to upgrade privileges from regular user to root (before possibly dropping them to a different user). Hell, it even uses sticky bit

I think the only point you're trying to do differently is intersecting permissions.
Linux grants "user" access when application's user own the file, "group" access when user doesn't own the file but does belong to the group owning the file, and "other" access when neither condition is met.

ACL does the same thing, except you can have multiple alternative entries. Alternative = additive permissions. Not: intersecting = multiplicative.
You can apply additional restrictions (-x) on the parent directory though. Ugly workaround and not very convenient, but it does result in intersecting permissions.
_________________
Make Computing Fun Again

[pingtoo]

It sound like that "sandboxing" tool need to have a way to configure to know how to add/remove additional user into ACL.

I think current flatpak (a sandboxing tool) does not have this capability. Are you suggestion double sandboxing and expect the outter box somehow influence the inner sandbox?

[minkanjin]

@szatox, maybe I don't understand correctly. I understood suid as changing the user. My idea is keep the user the same, but restrict the app. Very much a reduction in privileges, which is very different from suid as I understand it.

[minkanjin]

"It sound like that "sandboxing" tool need to have a way to configure to know how to add/remove additional user into ACL."
Yes, someone would have to develop user friendly interfaces for this. At the moment there is only the old fashioned way to do it.

As I understand flatpak from the GUI, apps are only given access to files that they need. With a tool like flatseal, you can give it access to more files that you own. I want to give more or less the same thing for apps outside flatpak.
This is not to extend flatpak, it is for the system in general. Flatpak is just the example of where I've seen this before.

[NeddySeagoon]

minkanjin,

Maybe you want SELinux?
_________________
Regards,

NeddySeagoon

Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail.

[pingtoo]

minkanjin,

In linux there is unshare(1) which is sandbox command line tool. may be you can look it up to see if that fit your idea.

In gentoo it is possible to use /usr/bin/sandbox to do something you described.

Then there is bubblewrap which is tool used by flatpak it also could be something you want to investigate.

All in all they are using namespaces(7) concept in linux kernel so you can also check on that.

[minkanjin]

I expected that SELinux would get mentioned. From what I understand it is quite dense. It has a whole bunch of features that most people won't use, and the learning curve is steep. Correct me if I'm wrong.
The only thing I (and most users) need, is a way to prevent closed source apps from harvesting my data. I think SELinux is too much for that.
From what I've heard, AppArmor was invented to simplify SELinux into what someone like me needs. But for some reason it hasn't really gained much popularity (Why is that?).

I think the best option is probably some combination of bubblewrap/firejail/apparmor. I'm just exploring the idea of doing it in a more basic linux without extensions.

[minkanjin]

The only problems I foresee at the moment, is that maintaining file permissions might become a lot of work. There would need to be tools to help clean up permissions when app is no longer wanted, etc.

The other problem is if I install an app under my own ownership, it would have access to all my files. So I would have to be mindful of how I install games from GOG, etc.

[minkanjin]

I also have a related question: The Gentoo repo has a few closed source binaries that are currently not sandboxed. That bothers me a bit. Which system would be easiest to implement into portage?

[szatox]

[pingtoo]

I would do it this way,

write a script that will bind mount everything necessary for the application into do a directory (pretend it is root), use this script to first bind-mount everything necessary for the use. And call command line argument (unshare) to box in the usage.

[NeddySeagoon]

pingtoo,

qubes-os does something similar. It runs each app in its own virtual machine, or used to.
_________________
Regards,

NeddySeagoon

Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail.

[pingtoo]

[minkanjin]

Either what I want is different from suid, or I don't understand suid. I understand suid like this: if I have access to the GPU and the soundcard, and the app has access to the network and the soundcard, then suid would drop my access to the GPU and give me access to the network. So I would end up with access to the network and the soundcard, just like the app.
That is not what I want. I want to lose access to the GPU, without gaining access to the network. So I end up with only access to the soundcard. The only privilege in the intersection is the soundcard.

Yes, umask would have to change. What makes it worse is that Gnome, for some unknown brilliant reason, overrides the user's setting for the usmask. So that would have to change.

There are closed source apps in the gentoo repo, like Steam and Discord. When I run them, they have access to everything I do. So they are not sandboxed. I don't like that because a lot of companies are very liberal at how they use you data. At the moment I install these apps via flatpak, since that is the only way I can get them in a sandbox.

[szatox]

[pietinger]