3 ms·

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, w

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.

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.