6 ms·

The real problem is that any app I run accesss all files I own with equal permissions. App1 and App2 shouldn’t write their data to my home, or read each other’

by sakoht 8y ago

The real problem is that any app I run accesss all files I own with equal permissions. App1 and App2 shouldn’t write their data to my home, or read each other’s data, or, please, be able to write each other’s data. A video game can read my tax forms. WTF. Mobile & tablet OSs solve this. Everything has to follow. Until then, basically every app should run in a docker container. Then it can do what it wants.

pmontra 8y ago
You can create another user and sudo / gksudo to it when working on sensitive data. It never occurred to me before reading your comment. I could start doing it myself.
- darkmighty 8y ago
  su - <username> also works. Indeed the capability exists (unix/linux pioneered it?), but it relies on manual containment by the user. It should be automated, with prompts at install or execution time, like on mobile OSs. An idea is each file should have its own user, basically, with both relative and absolute file creation/modification permissions. If you run an arbitrary executable as a user there's great security risk since it can do anything you can (without sudo of course). It seems like the natural progression from Run everything as root -> Separate root and day-to-day user -> Don't use root and achieve things with sudo -> Each file has its own permissions (i.e. essentially its own user) set by the parent user Permissions should be both for individual actions and permanent classes of actions, on the user's discretion (i.e. allow it to create this file or always allow it to create files) This approach is even naturally hierarchical, executables could create other executables as long as they have permission to do so, and set the child permissions to at most its own. In this context an executable asking for permissions can be akin to sudo: it really is a file-user asking for its parent file-user for expanded permissions. To give a real life allegory, consider a Technician in a company wants to make a tool purchase, so he asks the Engineer. The Engineer doesn't have permission, so he denies or asks the Manager. Finally the Manager either denies or asks the CEO which has permission over everything.
  - pmontra 8y ago
    There are differences between the apps I use on my phone and the programs I use on my PC. I don't trust many of the apps on my phone (all of Google, FB, messaging, etc). I trust the open source apps (example K9 email) and I'm replacing proprietary apps with open source ones. I trust almost all programs I use on my PC, which I install with apt-get from Ubuntu or other open source PPAs (no snap, no flatpack). There are a few proprietary programs I might doubt of, for example NVidia driver, Skype, TeamViewer, Telegram. I understand that one is enough to compromise all the PC. I'm ok with separating untrusted apps/programs but I don't want to get permissions in the way of programs I trust. Software development would be a nightmare if emacs and vim and all GNU userland and interpreters, compilers, etc would run in different environments.
    - slavik81 8y ago
      > I trust almost all programs I use on my PC That's because you have to. I trust all my programs too, because I wouldn't install them if I didn't trust them. We've spent decades telling people only to install applications they trust, and not to click on suspicious executables. The result is that they are very resistant to install new programs, unless the programs are from organizations they already know and trust. That's partly why web applications are so popular: it requires less trust to use a website than to run a native application. If native applications were less dangerous, people might be willing to use more of them.
    - ric2b 8y ago
      That's a circular argument. 1. Desktop OS's have awful security 2. Therefore you're VERY careful about what you install 3. Because you're VERY careful about what you install, you don't need the extra security, it would only be an hassle.
    - darkmighty 8y ago
      Valid point. I thought about this, for system apps you would be able to assign lasting permission requests to read/write/modify anything., by default -- so it would work as right now. Just like in browsers, permissions (permission type prompt) could be remembered in a cache. If you're not comfortable with giving any command full reign on your system, you could simply give granular, temporary permissions as required. A concept I find useful is that there are two kinds of security: -- Accidental security -- Malicious security Permissions help with both. Not only you don't want 3rd parties to invade or disrupt your system, you don't want users to invade or disrupt your system (or their own systems) accidentally. A classic example I believe is an user wanting to delete all files in current directory, typing $ sudo rm ./* and missing the dot, getting $ sudo rm /* #(delete *all files*) Ideally in this case you would see two different requests: > The command rf requests root access for file deletion at / > Accept? (y/N) > User's administrative password: or > The command rf requests access for file deletion at /home/user/cache/ > Accept? (Y/n) Note you're not prompted for password in the second case because you already have permissions for this operations (only the process 'rf' doesn't). You may not be particularly worried about malicious security for system programs, but even professional administrators could be worried about accidental security and best practices (if they're not they could easily select persistent full permissions). I get the impression the last thing e.g. sysadmins want is mess up production systems, and wouldn't mind a few more prompts when doing things manually (which should be rare?), or assgining scripts the exact permissions needed for their job.
- Spivak 8y ago
  You can do better than entirely separate accounts. You could use a user namespace (i.e. subuid/subgid) for sensitive data.
paulddraper 8y ago
AppArmor and SELinux address this problem. But -- speaking from experience -- they are painful to use; most users prefer convenience over heightened security.
- Spivak 8y ago
  They're painful to set up yourself, but that's pretty much true of all current sandboxing approaches. If you just let your distro do it and follow their conventions it you barely notice.
  - paulddraper 8y ago
    > that's pretty much true of all current sandboxing approaches Agreed.
mr_toad 8y ago
It’s a shame Unix doesn’t have a chhome utility that functions like chroot.
- JdeBP 8y ago
  Just changing the HOME environment variable, which would be what such a hypothetical utility would boil down to, does not address what sakoht was talking about, which is Hurd-style subsetting of a user's account and files.
fiatjaf 8y ago
This is already solved by Linux, as you probably know. You can just use groups and users if you want. Also you can run Docker containers if you want, just don't force me to do it, as they're stupid.
jlarocco 8y ago
There's a very simple solution to this: Don't run apps that you don't trust. If you simply must, use a VM or AppArmor or SELinux. Don't inconvenience everybody because you're too lazy to be responsible for your own data. Besides, untrustworthy apps will bypass the protections anyway. Judging by the popularity of "curl <url> | sudo bash" lately, they'll probably just ask for root directly.
- ndnxhs 8y ago
  >a few users are too lazy Running untrusted programs is the default way we do computing. No one has time to audit every single program they run. The current desktop security model comes from when people mostly ran the programs that came with the OS and programs they wrote themself. Its vastly inappropriate for modern computer usage.
  - elihu 8y ago
    > The current desktop security model comes from when people mostly ran the programs that came with the OS and programs they wrote themself. Even that isn't particularly safe.
    - ndnxhs 8y ago
      It was good enough to stop bob on floor 5 from hogging all the CPU and preventing Jim's buggy script from deleting everyone's emails.
- theonemind 8y ago
  I have some degree of distrust of most of my applications. The "open trust" model usually ends up getting abused to the point where we have to lock it down...like early Windows, wide open for easy of administration, leading to things like the notorious "Blaster" worm, or the open architecture of the Internet, where we now have massive spam and DNS amplification attacks and all sorts of problems based on the notion of a trustworthy network. In general, everything in computing will keep going in the direction of "trust everything as little as possible for it to do its job" forever, I think, and probably has to.
int_19h 8y ago
BSDs have had jails for ages, which (unlike Docker) have been designed as a security isolation mechanism from the get go. https://www.freebsd.org/doc/handbook/jails.html https://www.freebsd.org/doc/handbook/jails.html
nixpulvis 8y ago
This is a great paper on the subject. ALCs don't: http://waterken.sourceforge.net/aclsdont/current.pdf http://waterken.sourceforge.net/aclsdont/current.pdf
eeeeeeeeeeeee 8y ago
It seems like MacOS has been headed in this direction, at least with the App Store apps. But it's a hard problem to elegantly implement without breaking everything. I still see a lot of Mac apps that basically say "disable system protection first."
- saagarjha 8y ago
  I have seen very few apps that do this now, mostly because it's getting harder to make users do this so apps have started to give up.
  - eeeeeeeeeeeee 8y ago
    Yep, it's definitely older apps that have been around longer and the dev isn't as active with it.
- rffn 8y ago
  I am moving away from macOS for this reason. There ar emore issues, but this is a major one for me.
jimmaswell 8y ago
Has this ever been a problem in practice for you or is it all theoretical? The tradeoff doesn't seem worth it to me.
- ddebernardy 8y ago
  Not the OP, but think of all the times your computer caught viruses or got hacked.
  - mises 8y ago
    I'm thinking of zero. Zero times, in my life. As the old saying goes, common sense is the best antivirus. Although I did get the ask toolbar once...
    - ric2b 8y ago
      You might have been infected 50 times and not know it.
userbinator 8y ago
Mobile & tablet OSs solve this. Everything has to follow. No no no NO!!!! Think of all the things you can't do on a mobile device that you can do on a PC, or which require ridiculous workarounds like uploading from one app to some server on the Internet and then downloading again into another. Effortless data interchange is what makes computing great, and stops proprietary walled-garden data-silos from becoming the norm.
- jen729w 8y ago
  Agreed, and we’re now in serious danger of “Okay button fatigue” or whatever you’d like to call it. If every normal app has to ask for permission to use your disk, you’re just going to click “Okay” when malware asks. Then the whole system was for naught.
  - dietr1ch 8y ago
    Maybe just having some groups, like Firefox's containers. It's less secure, but a simple setup would drastically reduce the number of programs with access to important information.
  - AnIdiotOnTheNet 8y ago
    So just don't do that. The application needs an "Open" dialog already so you can tell it what files to open, just have that dialog be a process run by the system instead of the application, treat the permission as implicit since the user is the one selecting the file, and pass a handle back to the application.
    - detaro 8y ago
      E.g. Flatpak has the concept of "Portals" for that: https://github.com/flatpak/flatpak/wiki/Portals https://github.com/flatpak/flatpak/wiki/Portals
- Ar-Curunir 8y ago
  What can you do wrt file-management on your laptop that you can't on your phone? I have a file manager on my phone that can send files to whatever app needs it; why should a random game have access to arbitrary files?
RGamma 8y ago
Yes, this entire discussion is part of a whole other problem: there's too many properties of programs one has to trust esp. on desktop (or alternatively be stuck configuring selinux for days). One should/must/can not build an operating system on trust alone, as especially the mobile software space consistently continues to show with its numerous malware apps (imagine that on the desktop! "oh sure, have root/admin '50 smileys FOR FREE'", "oh sure, be able to read and write all my user's files <insert dubious clicker app>"). Mobile OSs have become vastly better (not perfect still) than this than desktop OSs. I would like to see desktop Linux's application management adapt a minimum necessary permissions policy: Allow access to some ressource/API/permission only if the app needs it (and the user allows it of course) and offer mechanisms to allow permission management and ways to enable inter-application communication. This also modularises applications more by bundling up their connections to the rest of the platform and their effects in a central location. For instance sandboxing applications into their own empty folder would make it simpler to operate on files these applications created (backup, migrate, autocreate <- NixOS would benefit from these especially, allowing finer grained declarative control). It would still be okay then for application developers to follow their own conventions within that sandbox. Nowadays files are all bunched up in arbitrary folders and nobody knows where they're coming from. It's become so much harder these days to coordinate so many projects that need to create files in the home folder on Linux by trying to introduce standards versus taking that capability away from programs transparently; this should also be much more efficient man-hours-wise. That said, this is going to be a nontrivial project with how many implicit connections between applications exist. Executing untrusted (or buggy!, I'm looking at you, Steam) software should no longer have to make me afraid my system gets messed up. For now I think it's best to simply not run untrusted programs and creating regular backups... I wish I had the time/skills to work on something like this.
fghtr 8y ago
I solved this problem by switching to Qubes OS.
- AnIdiotOnTheNet 8y ago
  Problem with QubesOS is how ridiculously heavy it is and that none of your stuff can actually use the GPU.
heinrichhartman 8y ago
> basically every app should run in a docker container Why does it have to be "Docker"? Any other container framework should do as well, no? Note that systemd can create cgroups and namespaces for processes it manages: http://0pointer.de/blog/projects/security.html http://0pointer.de/blog/projects/security.html
mises 8y ago
Linux is built to avoid this: important programs get users, and permissions can then be set to disallow others from even reading.

by sakoht 8y ago

pmontra 8y ago

You can create another user and sudo / gksudo to it when working on sensitive data. It never occurred to me before reading your comment. I could start doing it myself.

darkmighty 8y ago
su - <username> also works. Indeed the capability exists (unix/linux pioneered it?), but it relies on manual containment by the user. It should be automated, with prompts at install or execution time, like on mobile OSs. An idea is each file should have its own user, basically, with both relative and absolute file creation/modification permissions. If you run an arbitrary executable as a user there's great security risk since it can do anything you can (without sudo of course). It seems like the natural progression from Run everything as root -> Separate root and day-to-day user -> Don't use root and achieve things with sudo -> Each file has its own permissions (i.e. essentially its own user) set by the parent user Permissions should be both for individual actions and permanent classes of actions, on the user's discretion (i.e. allow it to create this file or always allow it to create files) This approach is even naturally hierarchical, executables could create other executables as long as they have permission to do so, and set the child permissions to at most its own. In this context an executable asking for permissions can be akin to sudo: it really is a file-user asking for its parent file-user for expanded permissions. To give a real life allegory, consider a Technician in a company wants to make a tool purchase, so he asks the Engineer. The Engineer doesn't have permission, so he denies or asks the Manager. Finally the Manager either denies or asks the CEO which has permission over everything.
- pmontra 8y ago
  There are differences between the apps I use on my phone and the programs I use on my PC. I don't trust many of the apps on my phone (all of Google, FB, messaging, etc). I trust the open source apps (example K9 email) and I'm replacing proprietary apps with open source ones. I trust almost all programs I use on my PC, which I install with apt-get from Ubuntu or other open source PPAs (no snap, no flatpack). There are a few proprietary programs I might doubt of, for example NVidia driver, Skype, TeamViewer, Telegram. I understand that one is enough to compromise all the PC. I'm ok with separating untrusted apps/programs but I don't want to get permissions in the way of programs I trust. Software development would be a nightmare if emacs and vim and all GNU userland and interpreters, compilers, etc would run in different environments.
  - slavik81 8y ago
    > I trust almost all programs I use on my PC That's because you have to. I trust all my programs too, because I wouldn't install them if I didn't trust them. We've spent decades telling people only to install applications they trust, and not to click on suspicious executables. The result is that they are very resistant to install new programs, unless the programs are from organizations they already know and trust. That's partly why web applications are so popular: it requires less trust to use a website than to run a native application. If native applications were less dangerous, people might be willing to use more of them.
  - ric2b 8y ago
    That's a circular argument. 1. Desktop OS's have awful security 2. Therefore you're VERY careful about what you install 3. Because you're VERY careful about what you install, you don't need the extra security, it would only be an hassle.
  - darkmighty 8y ago
    Valid point. I thought about this, for system apps you would be able to assign lasting permission requests to read/write/modify anything., by default -- so it would work as right now. Just like in browsers, permissions (permission type prompt) could be remembered in a cache. If you're not comfortable with giving any command full reign on your system, you could simply give granular, temporary permissions as required. A concept I find useful is that there are two kinds of security: -- Accidental security -- Malicious security Permissions help with both. Not only you don't want 3rd parties to invade or disrupt your system, you don't want users to invade or disrupt your system (or their own systems) accidentally. A classic example I believe is an user wanting to delete all files in current directory, typing $ sudo rm ./* and missing the dot, getting $ sudo rm /* #(delete *all files*) Ideally in this case you would see two different requests: > The command rf requests root access for file deletion at / > Accept? (y/N) > User's administrative password: or > The command rf requests access for file deletion at /home/user/cache/ > Accept? (Y/n) Note you're not prompted for password in the second case because you already have permissions for this operations (only the process 'rf' doesn't). You may not be particularly worried about malicious security for system programs, but even professional administrators could be worried about accidental security and best practices (if they're not they could easily select persistent full permissions). I get the impression the last thing e.g. sysadmins want is mess up production systems, and wouldn't mind a few more prompts when doing things manually (which should be rare?), or assgining scripts the exact permissions needed for their job.
Spivak 8y ago
You can do better than entirely separate accounts. You could use a user namespace (i.e. subuid/subgid) for sensitive data.

paulddraper 8y ago

AppArmor and SELinux address this problem. But -- speaking from experience -- they are painful to use; most users prefer convenience over heightened security.

Spivak 8y ago
They're painful to set up yourself, but that's pretty much true of all current sandboxing approaches. If you just let your distro do it and follow their conventions it you barely notice.
- paulddraper 8y ago
  > that's pretty much true of all current sandboxing approaches Agreed.

mr_toad 8y ago

It’s a shame Unix doesn’t have a chhome utility that functions like chroot.

JdeBP 8y ago
Just changing the HOME environment variable, which would be what such a hypothetical utility would boil down to, does not address what sakoht was talking about, which is Hurd-style subsetting of a user's account and files.

fiatjaf 8y ago

This is already solved by Linux, as you probably know. You can just use groups and users if you want. Also you can run Docker containers if you want, just don't force me to do it, as they're stupid.

jlarocco 8y ago

There's a very simple solution to this: Don't run apps that you don't trust. If you simply must, use a VM or AppArmor or SELinux. Don't inconvenience everybody because you're too lazy to be responsible for your own data. Besides, untrustworthy apps will bypass the protections anyway. Judging by the popularity of "curl <url> | sudo bash" lately, they'll probably just ask for root directly.

ndnxhs 8y ago
>a few users are too lazy Running untrusted programs is the default way we do computing. No one has time to audit every single program they run. The current desktop security model comes from when people mostly ran the programs that came with the OS and programs they wrote themself. Its vastly inappropriate for modern computer usage.
- elihu 8y ago
  > The current desktop security model comes from when people mostly ran the programs that came with the OS and programs they wrote themself. Even that isn't particularly safe.
  - ndnxhs 8y ago
    It was good enough to stop bob on floor 5 from hogging all the CPU and preventing Jim's buggy script from deleting everyone's emails.
theonemind 8y ago
I have some degree of distrust of most of my applications. The "open trust" model usually ends up getting abused to the point where we have to lock it down...like early Windows, wide open for easy of administration, leading to things like the notorious "Blaster" worm, or the open architecture of the Internet, where we now have massive spam and DNS amplification attacks and all sorts of problems based on the notion of a trustworthy network. In general, everything in computing will keep going in the direction of "trust everything as little as possible for it to do its job" forever, I think, and probably has to.

int_19h 8y ago

BSDs have had jails for ages, which (unlike Docker) have been designed as a security isolation mechanism from the get go. https://www.freebsd.org/doc/handbook/jails.html https://www.freebsd.org/doc/handbook/jails.html

nixpulvis 8y ago

This is a great paper on the subject. ALCs don't: http://waterken.sourceforge.net/aclsdont/current.pdf http://waterken.sourceforge.net/aclsdont/current.pdf

eeeeeeeeeeeee 8y ago

It seems like MacOS has been headed in this direction, at least with the App Store apps. But it's a hard problem to elegantly implement without breaking everything. I still see a lot of Mac apps that basically say "disable system protection first."

saagarjha 8y ago
I have seen very few apps that do this now, mostly because it's getting harder to make users do this so apps have started to give up.
- eeeeeeeeeeeee 8y ago
  Yep, it's definitely older apps that have been around longer and the dev isn't as active with it.
rffn 8y ago
I am moving away from macOS for this reason. There ar emore issues, but this is a major one for me.

jimmaswell 8y ago

Has this ever been a problem in practice for you or is it all theoretical? The tradeoff doesn't seem worth it to me.

ddebernardy 8y ago
Not the OP, but think of all the times your computer caught viruses or got hacked.
- mises 8y ago
  I'm thinking of zero. Zero times, in my life. As the old saying goes, common sense is the best antivirus. Although I did get the ask toolbar once...
  - ric2b 8y ago
    You might have been infected 50 times and not know it.

userbinator 8y ago

Mobile & tablet OSs solve this. Everything has to follow. No no no NO!!!! Think of all the things you can't do on a mobile device that you can do on a PC, or which require ridiculous workarounds like uploading from one app to some server on the Internet and then downloading again into another. Effortless data interchange is what makes computing great, and stops proprietary walled-garden data-silos from becoming the norm.

jen729w 8y ago
Agreed, and we’re now in serious danger of “Okay button fatigue” or whatever you’d like to call it. If every normal app has to ask for permission to use your disk, you’re just going to click “Okay” when malware asks. Then the whole system was for naught.
- dietr1ch 8y ago
  Maybe just having some groups, like Firefox's containers. It's less secure, but a simple setup would drastically reduce the number of programs with access to important information.
- AnIdiotOnTheNet 8y ago
  So just don't do that. The application needs an "Open" dialog already so you can tell it what files to open, just have that dialog be a process run by the system instead of the application, treat the permission as implicit since the user is the one selecting the file, and pass a handle back to the application.
  - detaro 8y ago
    E.g. Flatpak has the concept of "Portals" for that: https://github.com/flatpak/flatpak/wiki/Portals https://github.com/flatpak/flatpak/wiki/Portals
Ar-Curunir 8y ago
What can you do wrt file-management on your laptop that you can't on your phone? I have a file manager on my phone that can send files to whatever app needs it; why should a random game have access to arbitrary files?

RGamma 8y ago

Yes, this entire discussion is part of a whole other problem: there's too many properties of programs one has to trust esp. on desktop (or alternatively be stuck configuring selinux for days). One should/must/can not build an operating system on trust alone, as especially the mobile software space consistently continues to show with its numerous malware apps (imagine that on the desktop! "oh sure, have root/admin '50 smileys FOR FREE'", "oh sure, be able to read and write all my user's files <insert dubious clicker app>"). Mobile OSs have become vastly better (not perfect still) than this than desktop OSs. I would like to see desktop Linux's application management adapt a minimum necessary permissions policy: Allow access to some ressource/API/permission only if the app needs it (and the user allows it of course) and offer mechanisms to allow permission management and ways to enable inter-application communication. This also modularises applications more by bundling up their connections to the rest of the platform and their effects in a central location. For instance sandboxing applications into their own empty folder would make it simpler to operate on files these applications created (backup, migrate, autocreate <- NixOS would benefit from these especially, allowing finer grained declarative control). It would still be okay then for application developers to follow their own conventions within that sandbox. Nowadays files are all bunched up in arbitrary folders and nobody knows where they're coming from. It's become so much harder these days to coordinate so many projects that need to create files in the home folder on Linux by trying to introduce standards versus taking that capability away from programs transparently; this should also be much more efficient man-hours-wise. That said, this is going to be a nontrivial project with how many implicit connections between applications exist. Executing untrusted (or buggy!, I'm looking at you, Steam) software should no longer have to make me afraid my system gets messed up. For now I think it's best to simply not run untrusted programs and creating regular backups... I wish I had the time/skills to work on something like this.

fghtr 8y ago

I solved this problem by switching to Qubes OS.

AnIdiotOnTheNet 8y ago
Problem with QubesOS is how ridiculously heavy it is and that none of your stuff can actually use the GPU.

heinrichhartman 8y ago

> basically every app should run in a docker container Why does it have to be "Docker"? Any other container framework should do as well, no? Note that systemd can create cgroups and namespaces for processes it manages: http://0pointer.de/blog/projects/security.html http://0pointer.de/blog/projects/security.html

mises 8y ago

Linux is built to avoid this: important programs get users, and permissions can then be set to disallow others from even reading.