Hacker News new | ask | show | jobs
by amelius 2887 days ago
I really hate it when I need to send a single file or photo, an app suddenly "needs access to my filesystem" and I have to grant that access.

OSes should allow me to create a sandbox for an app, so I can grant them access (and the app will not "break"), while still being secure.

8 comments

> I really hate it when I need to send a single file or photo, an app suddenly "needs access to my filesystem" and I have to grant that access.

There's another way: the app could instead use Android's Intent system to request a file chooser. This switches to a separate app which already has access to the filesystem (like the built-in Gallery app), which after the user has chosen the file, returns something which allows the original app access to just that file. This mechanism exists since the first version of Android.

I think this won't work because the app can get away by asking (insisting) for more permission than it actually needs.
exactly.
That shows the larger problem with Android. An app shouldn’t need access to your file system to send a photo. It should bring up a system provided photo picker and once the user chooses a set of files, the OS should give it a read only access to the file.

If a photo management app needs access to your photos, you should be able to give it access to your photo library.

I don't think that's the solution because apps may easily "bribe" the user into giving the app more access than it strictly needs. The bribing goes like: "sorry, but if you don't give me full access, then you can't use me". Simple, but very effective in most cases.

A better solution (imho) is to make the app think it has access, while in reality its access is limited to a sandbox.

That’s still a problem with the OS. Why does any app need access to the file system instead of the users photo library or access to certain files in a document store where the app only has read access to files that the user explicitly chooses in a system provided file picker or can write files to a location that the user chooses?
It’s fine that it’s an option but there is still nothing on the OS stopping an app from getting more permission. Why is the other permission even an option?
Just a matter of freedom vs security I guess?
I thought Android apps were sandboxed [1]. The "needs access to my file system" is the way for data to transfer into that sandbox.

Android should add the option for temporary data access. I would prefer turning on the access temporarily to send 1 photo, then turning it off a few minutes later.

https://developer.android.com/training/articles/security-tip...

The problem is that apps want access to my entire filesystem, otherwise they break. So a solution is to make them think they have access, while in reality they only have access to the sandbox filesystem (containing just the files I want to manipulate with that app).
What is the "file system permission" you are referring to?

See: https://developer.android.com/reference/android/Manifest.per...

If you don't mind sharing, what app are you referring to?

The file system itself should be well protected (on a non-rooted phone) as to prevent any unauthorized access to important data. Any app can only do whatever on the SD card if you give it permission to do so, but on the OS file system itself there isn't much they can do (again, on a non-rooted phone).

That doesn’t help. No app should need general access to the sd card.
Completely agree.
I believe this is what you're looking for?

https://developer.android.com/training/secure-file-sharing/r...

That's basically what Privacy Guard does. It was available at one point in stock Android and is a major selling point (IMO) of LineageOS.
Your solution is too simple and intuitive.
Linux does have this feature. It is the chroot() system call.

Linux can also allow limited access to select filesystem data within a chroot() - this is done with a "bind mount."

Why these two security features were not designed around all Android apps from the beginning is beyond me.

Didn't chroot() become secure / usable only late in the era of smartphones, way past creation of Android? Containers are a pretty new development, after all.
Neither linux containers nor linux chroot provide meaningful security. They’re useful for other things, but the kernel itself isn’t particularly well hardened against local privilege escalation attacks.

OpenBSD is one of the best on that front, but it is a defense-in-depth mechanism, not something designed to run known-malicious code.

That's no different than running programs in userspace on a PC- if you trust the app, it makes no sense to decline.

At least you can turn it off later.

And then you need to app to the sandbox? Seems even more complex
Actually isn't. And this was already implemented in iOS and Windows Mobile.