6 ms·

I would love to see a real permission system on Linux, where applications have to explicitly ask me before accessing things deemed important. It's never been a

I would love to see a real permission system on Linux, where applications have to explicitly ask me before accessing things deemed important. It's never been a problem for me, but it would give me some comfort.

psanford 6y ago
For non-opensource applications (e.g. Zoom) I really like using Firejail[0] to run them within a sandbox. Firejail ships with a good set of default policies which make it explicit what the application gets access to. The filesystem sandboxing is especially comforting. [0]: https://firejail.wordpress.com/ https://firejail.wordpress.com/
- solarkraft 6y ago
  What are the security downsides of Firejail vs. Flatpaks? Complexity wise the former looks wildly more preferable.
bartvk 6y ago
This was introduced in macOS at some point (Catalina release?) and I saw a whole bunch of people complain about the number of dialogues they had to go through. I really like it, though. New applications have to ask whether they can read/write from ~/Documents or ~/Pictures, or read contacts. I agree with you, and also wish something like this existed for modern Linux desktops.
- hrjet 6y ago
  Try flatpak with flatseal The permissions are not interactive, you can set them once and forget.
Blikkentrekker 6y ago
It would be both annoying and somewhat useless, for giving an application access to the input system gives an application access to everything because then it could give itself access to everything. The same of course applies to giving it access to the file system. Something so simple as an audio manipulation application must have access to the filesystem, unless one only will it to be able to save within a specific subsection thereof, and if it be granted such access, it can now edit whatever file stores whatever application has whatever permissions, thus giving itself full permissions. The further problems with this scheme are that it's not entirely clear where the limits of one “application” lies which would have to be defined. It makes a great deal of assumptions that may not be true. This is also a problem with Linux capabilities. — I remember well an explanation where the auctor demonstrated how in about 2/3 of all Linux capabilities, they, or in combination with one other capability were sufficient to escalate to full root access on almost any modern normal system. Many of these security restrictions are theoretical of nature, and on most systems amount to very little against a sufficiently skilled attacker, but do inspire a false sense of security. > but it would give me some comfort. And that is what it seems to truly be for: not making the user safe, but making him feel safe, and the latter often has a negative influence on the former.
- theamk 6y ago
  > giving an application access to the input system gives an application access to everything How do you figure? There are systems already (like Wayland) where default access to input only gives you input when the app is active, and entire different process is required for global hotkeys or key logging. There are no nice GUIs to manage that AFAIK, but this is not an impossible problem to solve anymore. > The same of course applies to giving it access to the file system. uh, what? no. giving a browser access only to "~/Downloads" will work great and will make it much more secure. The modern Linux is much more than capabilities and user-based permissions. A mount namespace with selectively bind-mounted dirs can do wonders for security. And things like "bindfs" which can translate UIDs on the fly can give even more isolation.
  - Blikkentrekker 6y ago
    > How do you figure? There are systems already (like Wayland) where default access to input only gives you input when the app is active, and entire different process is required for global hotkeys or key logging. That's not what is commonly understood as access to the input system. > There are no nice GUIs to manage that AFAIK, but this is not an impossible problem to solve anymore. So long you be willing to live with a walled garden environment where one's text editor either can't edit the files on one's system any more, or is given sufficient permissions to circumvent all of this regardless. > uh, what? no. giving a browser access only to "~/Downloads" will work great and will make it much more secure. It would also mean that no modern browser works any more since they need access to far more to even start up. You should `strace` a browser and be surprised that it constantly needs to read and write files from all over the system. I would also be rather annoyed with a browser that can only save files in one folder rather than wherever it please me. Finally, even if this browser only have access to `~/Downloads`, it would still be capable of modifying any file that something else put there, thus allowing it to easily install malware into anything that anything els downloads, without the user's knowledge. > The modern Linux is much more than capabilities and user-based permissions. A mount namespace with selectively bind-mounted dirs can do wonders for security. And things like "bindfs" which can translate UIDs on the fly can give even more isolation. There is a good reason that SELinux never truly penetrated: — it is capable of much of this, but it would also make most applications unworkable and users would complain about no longer being able to do as they will. More or less what the situation is on Android, or Windows.
matheusmoreira 6y ago
I want to get notified every time a program performs any type of I/O system call. I want to see the parameters and the data being copied. I also want the opportunity to cancel the system call and even return fake results and data back to the program. I already use strace to understand what programs do but it would be great if I could also intercept these calls in real time. Just keep the program waiting until I approve its open system call on that specific file.
- karlding 6y ago
  Isn't this ability basically already provided via ptrace? The tracer can mutate syscall arguments, mutate syscall return values, or even block syscalls. The primitives ptrace provides should be sufficient to implement something like this. That's basically how strace is implemented anyways.
- samus 6y ago
  This can be done with a FUSE server. By using filesystem namespaces, an app can then be restricted to just the view of the filesystem that this FUSE server exposes. Another possibility, at least for dynamically linked programs, would be to set LD_LIBRARY_PATH to force every system call through a wrapper.
Ericson2314 6y ago
Someone needs to finish off Capsicum/CloudABI, and then we redo the userland. Will be so much simpler think about too.
dirkt 6y ago
It's interesting to see how the "we must protect users from each other on a multi-user system using permissions" need has shifted to "we must protect the often single user from multiple potentially evil applications using permissions".

psanford 6y ago

For non-opensource applications (e.g. Zoom) I really like using Firejail[0] to run them within a sandbox. Firejail ships with a good set of default policies which make it explicit what the application gets access to. The filesystem sandboxing is especially comforting. [0]: https://firejail.wordpress.com/ https://firejail.wordpress.com/

solarkraft 6y ago
What are the security downsides of Firejail vs. Flatpaks? Complexity wise the former looks wildly more preferable.

bartvk 6y ago

This was introduced in macOS at some point (Catalina release?) and I saw a whole bunch of people complain about the number of dialogues they had to go through. I really like it, though. New applications have to ask whether they can read/write from ~/Documents or ~/Pictures, or read contacts. I agree with you, and also wish something like this existed for modern Linux desktops.

hrjet 6y ago
Try flatpak with flatseal The permissions are not interactive, you can set them once and forget.

Blikkentrekker 6y ago

It would be both annoying and somewhat useless, for giving an application access to the input system gives an application access to everything because then it could give itself access to everything. The same of course applies to giving it access to the file system. Something so simple as an audio manipulation application must have access to the filesystem, unless one only will it to be able to save within a specific subsection thereof, and if it be granted such access, it can now edit whatever file stores whatever application has whatever permissions, thus giving itself full permissions. The further problems with this scheme are that it's not entirely clear where the limits of one “application” lies which would have to be defined. It makes a great deal of assumptions that may not be true. This is also a problem with Linux capabilities. — I remember well an explanation where the auctor demonstrated how in about 2/3 of all Linux capabilities, they, or in combination with one other capability were sufficient to escalate to full root access on almost any modern normal system. Many of these security restrictions are theoretical of nature, and on most systems amount to very little against a sufficiently skilled attacker, but do inspire a false sense of security. > but it would give me some comfort. And that is what it seems to truly be for: not making the user safe, but making him feel safe, and the latter often has a negative influence on the former.

theamk 6y ago
> giving an application access to the input system gives an application access to everything How do you figure? There are systems already (like Wayland) where default access to input only gives you input when the app is active, and entire different process is required for global hotkeys or key logging. There are no nice GUIs to manage that AFAIK, but this is not an impossible problem to solve anymore. > The same of course applies to giving it access to the file system. uh, what? no. giving a browser access only to "~/Downloads" will work great and will make it much more secure. The modern Linux is much more than capabilities and user-based permissions. A mount namespace with selectively bind-mounted dirs can do wonders for security. And things like "bindfs" which can translate UIDs on the fly can give even more isolation.
- Blikkentrekker 6y ago
  > How do you figure? There are systems already (like Wayland) where default access to input only gives you input when the app is active, and entire different process is required for global hotkeys or key logging. That's not what is commonly understood as access to the input system. > There are no nice GUIs to manage that AFAIK, but this is not an impossible problem to solve anymore. So long you be willing to live with a walled garden environment where one's text editor either can't edit the files on one's system any more, or is given sufficient permissions to circumvent all of this regardless. > uh, what? no. giving a browser access only to "~/Downloads" will work great and will make it much more secure. It would also mean that no modern browser works any more since they need access to far more to even start up. You should `strace` a browser and be surprised that it constantly needs to read and write files from all over the system. I would also be rather annoyed with a browser that can only save files in one folder rather than wherever it please me. Finally, even if this browser only have access to `~/Downloads`, it would still be capable of modifying any file that something else put there, thus allowing it to easily install malware into anything that anything els downloads, without the user's knowledge. > The modern Linux is much more than capabilities and user-based permissions. A mount namespace with selectively bind-mounted dirs can do wonders for security. And things like "bindfs" which can translate UIDs on the fly can give even more isolation. There is a good reason that SELinux never truly penetrated: — it is capable of much of this, but it would also make most applications unworkable and users would complain about no longer being able to do as they will. More or less what the situation is on Android, or Windows.

matheusmoreira 6y ago

I want to get notified every time a program performs any type of I/O system call. I want to see the parameters and the data being copied. I also want the opportunity to cancel the system call and even return fake results and data back to the program. I already use strace to understand what programs do but it would be great if I could also intercept these calls in real time. Just keep the program waiting until I approve its open system call on that specific file.

karlding 6y ago
Isn't this ability basically already provided via ptrace? The tracer can mutate syscall arguments, mutate syscall return values, or even block syscalls. The primitives ptrace provides should be sufficient to implement something like this. That's basically how strace is implemented anyways.
samus 6y ago
This can be done with a FUSE server. By using filesystem namespaces, an app can then be restricted to just the view of the filesystem that this FUSE server exposes. Another possibility, at least for dynamically linked programs, would be to set LD_LIBRARY_PATH to force every system call through a wrapper.

Ericson2314 6y ago

Someone needs to finish off Capsicum/CloudABI, and then we redo the userland. Will be so much simpler think about too.

dirkt 6y ago

It's interesting to see how the "we must protect users from each other on a multi-user system using permissions" need has shifted to "we must protect the often single user from multiple potentially evil applications using permissions".