Hacker News Reader

Comment by sakoht | Hacker News Reader

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.

View on HN

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.

There is a middle ground. Universal data interchange formats but sandboxed on a per directory/app level. Imagine how easy it is to do docker run --volume=~/tax_forms. Put some UX on top of that, plus something resembling Android Intents for escape hatches without giving out full access, and you will have a fantastic solution.

Implementation really really is key when it comes to the UX here though. Windows actually already has this feature (Controlled folder access) but it's done so badly you'd almost think it's a joke. Take this as a warning of how bad things can be if you just sandbox everything without thinking. Enabling the feature accidentally is deceptively simple without any warnings on how difficult it is to use: "Protect files from unauthorized changes by unfriendly apps" is all it says, who wouldn't want that? After that havoc breaks loose. You can only have ONE group of folders protected, you must have Documents protected. Whenever a new program tries to write in a protected folder the program just fails, then 15 seconds later you get a confusing prompt saying excel_32_broker_confusing_name.exe tried to write to protected area, clicking the prompt takes you to a page where you can't simply press yes to allow, you have to manually browse to find the exact program location, good luck finding c:\program files(x86)\office\bin or whatever they decide to call the exe.

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.

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.

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.

E.g. Flatpak has the concept of "Portals" for that: https://github.com/flatpak/flatpak/wiki/Portals

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?

Exactly! I remember the days of proprietary data formats, when people would literally have to print out data from one program to type it back into another. Let's not regress to that.

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

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.

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.

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.

> 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.

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:

  > 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.

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.

You can do better than entirely separate accounts. You could use a user namespace (i.e. subuid/subgid) for sensitive data.

AppArmor and SELinux address this problem.

But -- speaking from experience -- they are painful to use; most users prefer convenience over heightened security.

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.

> that's pretty much true of all current sandboxing approaches

Agreed.

> 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

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

Not the OP, but think of all the times your computer caught viruses or got hacked.

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...

You might have been infected 50 times and not know it.

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."

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.

Yep, it's definitely older apps that have been around longer and the dev isn't as active with it.

I am moving away from macOS for this reason. There ar emore issues, but this is a major one for me.

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

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.

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

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

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.

I solved this problem by switching to Qubes OS.

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

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.

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.

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.

>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.

> 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.

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.

"Don't run apps that you don't trust"

So basically no apps at all.

Reply on news.ycombinator.com