Hacker News new | past | comments | ask | show | jobs | submit login

> Do I want Firefox to have access to my Contacts? My Photos? Do I want Facebook to have that access? To all of them, or just ones that I select? Should my disk utility have the ability to send data over the network? My IDE? My IDE plugins?

Modern security on Linux is hardly dependent on the POSIX security model.

Linux just got the Landlock feature[1] in the kernel[2] that does just this. Along with Landlock, features like cgroups, seccomp, AppArmor, Firejail and other sandboxing features go far beyond the traditional POSIX security model. Even parts of the ChromeOS security model are based on modern Linux sandboxing features, and don't rely on POSIX security.

To address your Firefox example, I use these features to sandbox Firefox so that it runs in a container, and limit its ability to run code or make certain syscalls, and it's only allowed to touch its profile and a dedicated Downloads folder. D-Bus can't even reach it.

> This has nothing to do with "stores"

I didn't say anything about stores. It has everything to do with Apple, Microsoft and (slowly) Google forgoing OS-level security for centralized control of what can and cannot run on their operating systems. This is not just enforced with "stores", but with certificate systems like Apple's Notarization and Gatekeeper programs and Microsoft's certificate program.

Instead of relying on the system to provide security, we're relying on Apple, Google and Microsoft to decide what we can run, or can't run, even though Apple is responsible for distributing 500 million copies of Xcodeghost[3], and Google's Play Store is the #1 vector for malware on Android[4].

[1] https://lwn.net/Articles/703876/

[2] https://lwn.net/Articles/700607/

[3] https://www.vice.com/en/article/n7bbmz/the-fortnite-trial-is...

[4] https://www.zdnet.com/article/play-store-identified-as-main-...




> Instead of relying on the system to provide security, we're relying on Apple, Google and Microsoft to decide what we can run, or can't run, even though Apple is responsible for distributing 500 million copies of Xcodeghost[3], and Google's Play Store is the #1 vector for malware on Android[4].

The security stuff is a huge red herring.

The security model is all about limiting self publishing and directly reaching consumers by the biggest players in IP, Disney, Netflix, Nintendo and Tencent. 90% of App Store revenue is games. Most remaining revenue is to subscription entertainment services. Security as engineers talk about it basically never affects the bottom line.


> Instead of relying on the system to provide security, we're relying on Apple, Google and Microsoft to decide what we can run, or can't run

This is highly misleading. System-level hardening is complementary to cryptographic trust, not a replacement forit. Hardening features do their best to prevent arbitrary malicious processes from controlling the system, and the certificate systems make it possible to revoke the ability of specific known-malicious authors to distribute software. In macOS, you can look at the entitlements system, sandboxing, and system integrity protection for examples of hardening.

Not to mention, at least on macOS and Windows, all the certificate verification features can be turned off.


> System-level hardening is complementary to cryptographic trust, not a replacement forit. Hardening features do their best to prevent arbitrary malicious processes from controlling the system, and the certificate systems make it possible to revoke the ability of specific known-malicious authors to distribute software. In macOS, you can look at the entitlements system, sandboxing, and system integrity protection for examples of hardening.

I agree, however neither of these operating systems gives the user the level of control to address these concerns:

> Do I want Firefox to have access to my Contacts? My Photos? Do I want Facebook to have that access? To all of them, or just ones that I select? Should my disk utility have the ability to send data over the network? My IDE? My IDE plugins?

A system that implemented security that empowers users would allow you to say "I want my Email App to only access certain Contacts or certain Photos", allow you to supply dummy data to apps and give you better granularity.

Instead, what we get from Google is a system whose security is convenient for advertisers first, and not users, so it doesn't offer that level of empowerment even though some AOSP forks do. You either give it all of your contacts or pictures or none of them. Making a secure system that also empowers users would mean that they and their partners can't collect user data. We're shown scary warnings about installing apps outside of the Play Store and are assured that Play Protect means that everything on the Play Store is secured.

What we get from Apple is a security model that is convenient to their bottom line, so instead of addressing that user's needs, users are told they don't have to worry about their Email App doing anything bad with their contacts or photos because Apple vets apps and its developers. Like on Android, you either give the app all of your contacts or none. Making a secure system that also empowers users goes against their marketing that insists that their App Store and certificate racket are the only things keeping users private and safe.


> Instead, what we get from Google is a system whose security is convenient for advertisers first, and not users, so it doesn't offer that level of empowerment even though some AOSP forks do. You either give it all of your contacts or pictures or none of them. Making a secure system that also empowers users would mean that they and their partners can't collect user data. We're shown scary warnings about installing apps outside of the Play Store and are assured that Play Protect means that everything on the Play Store is secured.

This literally isn't true since Android 10 and has been even more hardened in Android 11. Now the apps ONLY see the pictures you, as user, allow them to see. The same goes for file access, location access and plenty of other security model changes in last two Android versions.

So your rant about how evil Google caters to advertisers only really becomes wierd when they literally implemented the change you want.


iOS already lets you choose with granularity which photos to allow an app access to as of iOS 14. Both macOS and iOS do not allow any app to have access to photos, contacts, camera, etc, without prompting the user first. But there is a trade off between usability and security, and Apple is pushing that boundary towards security and privacy about as aggressively as any vendor is. People have been complaining about all the new entitlements pop-ups in macOS and saying they shouldn’t exist! But they are providing real benefits to users and increased safety.

Of course they should be doing more, but they are constantly improving, and the same can be said of any organization. Where are the Linux distros that do this stuff out of the box and don’t involve configuring these tools with the command line? SELinux and all of those other tools you mention aren’t helping users if users are forced to become sysadmins to benefit.


> iOS already lets you choose with granularity which photos to allow an app access to as of iOS 14.

How does this work? When an iOS app asks for permission to view photos, the user is asked which folders to grant it access to? How does the user grant one-time access?

> Both macOS and iOS do not allow any app to have access to photos, contacts, camera, etc, without prompting the user first. But there is a trade off between usability and security, and Apple is pushing that boundary towards security and privacy about as aggressively as any vendor is. People have been complaining about all the new entitlements pop-ups in macOS and saying they shouldn’t exist!

I think security prompts, viewed as interruptions, are a consequence of the Apple-owns-everything model. If I want to share a single photo with a friend using my messaging app, I don't really want to grant permission to view photos to the app. The fact that I have to is frustrating.

Instead, a step backwards towards the desktop metaphor, where the user owns the files, is a better place to step forward from: the user owns the files, and the apps are potentially hostile tools which the user sometimes requires. The app should ask the operating system for a photo, and the operating system should allow me to select the photo I want. The app then gets read access to this file right now. The app could certainly do something malicious with the read access it has received, but at least if it doesn't do anything malicious with it now, it can't do it later.

The limitation is that each app wouldn't be able to design its own photo selector

Some apps would of course legitimately want a broader access than that, e.g. a backup app, but the broader requirement shouldn't determine the limited requirement.

The same for location, for instance: it would be a resource that the app requires and the user chooses to give the current location or the spoofed location or cancel the action. (An advanced option that could be available for that would be "automatically fulfil the request in the same way for the next day/week/month/till the next upgrade/forever".)

The cognitive load would be much less. A user doesn't need to evaluate how trustworthy the app is in general. The user doesn't need to think, "It will be much easier for me to give SMS access to this app for setup, but I don't want it general access, so which one should I chose?". The user doesn't need to deny access to any app (which is tiring, since we're typically most naturally inclined to cooperate). Every action taken is naturally limited, so the stakes are lower.

The current approach is another attempt to reduce the cognitive load by reducing gratuitous choices. But it also prevents necessary distinctions and forces people to make choices they really don't want to (I want to send this photo vs I want this app to have access to my photos). But users view permission dialogs as things that take away their control rather than as things that give them control, so this approach seems failed. As you say, making them more and more fine grained just means the user is reminded more and more often that they don't have a say.

> Where are the [free software systems] that do this stuff out of the box and don’t involve configuring these tools with the command line?

There are projects to build software in this way-ish. They are all ridiculously limited and impractical. The amount of effort it takes is incredible. It's not simply a change of configuration; operating systems and programs need to be written to operate in this way. For instance, systems would have to stop making assumptions about the global filesystem namespace - the GTK filepicker would have to return read access to a file, rather than a filepath which a program than asks to open read-only.

Can you imagine a team of three or four developers maintaining a secure fork of a web browser in their spare time? and without a web browser, everything is a toy.


What you’re describing is literally the iOS (and increasingly, macOS) security model that gets derided by power users for being too restrictive. The system owns the photo picker. When an app asks for photos, you can either give it access to the whole library, or you can choose specific photos to share with it from the system picker. The system owns location services. When an app asks for location, you can either choose to allow it indefinitely, choose to deny it, or choose to allow it once. Even if you allow it indefinitely, iOS will follow up with a prompt a while later explaining that the app has been using your location in the background, show you a map of the locations it has tracked over that time period, and ask if you want to continue allowing it indefinitely or deny access.

What you claim about reducing gratuitous choices is pretty clearly not how Apple views these things. They have been adding more and more granular permissions with every update, in response to developers abusing the wider permissions. I also have no idea what you mean by the user being reminded they don’t have a say. The user does have a say. What irritates the people who don’t like the prompts is they think they shouldn’t have to click through anything. It’s not a complaint that the permissions are too wide, it’s that they’re too granular.

I will also note that the cryptographic verification (and App Store review) side of things makes these measures a lot stronger, because developers can’t just hack around in private APIs and system-level frameworks to circumvent the restrictions. They are forced by a contract only to access the restricted resources through approved channels. Even though Apple is not perfect with review, the evidence from other platforms and their own data is that they catch the vast majority of abuse that happens and we never see it.


> I think security prompts, viewed as interruptions, are a consequence of the Apple-owns-everything model.

No. It's a consequence of finding a balance between a usable system and the fact that people are shit.

From the start iOS was very limited as to what apps could access. Funnily enough, the Android crowd derided it for this. "What, no file system access, ahahaha".

And a user's usage scenario isn't "I open photos and and decide to share one with an app". The usage is "I open an app and want to select an unlimited random number of photos and videos to share with my friends in this app".

So the usability/permissions tradeoff was: an app sees nothing outside the sandbox, but can request access to a limited number of other system-defined sandboxes: photos, camera, microphone, location etc.

Guess what. People are shit. So they decided that unlimited access to photos is so very nice, and could be abused.

So the new permissions in iOS let you limit access even further: you select which photos an app has access to, and it only has access to those. Because what users want hasn't changed: they don't share photos with an app, they use an app to share photos.

The result is significantly more cumbersome than before and there's literally no way around it. It has nothing to do with "being Apple-owned". If you limit access, you will end up with security prompts and popups, access management dialogs etc.

> The same for location, for instance: it would be a resource that the app requires and the user chooses to give the current location or the spoofed location or cancel the action.

This is literally what iOS does. However, when iOS does it, suddenly it's "security prompts, viewed as interruptions, are a consequence of the Apple-owns-everything model"


>the GTK filepicker would have to return read access to a file, rather than a filepath which a program than asks to open read-only.

xdg-desktop-portal [1] does something pretty close, and it is how Linux applications shipped as Flatpaks access your files (at least when the Flatpak sandbox is in enforcing mode). Every sandboxed program has its own mount namespace which cannot see your home folder. When you want to open a file in a sandboxed program, you select the file in an out-of-process file chooser, and the portal puts a handle to that file in the program's view of the filesystem.

[1] https://github.com/flatpak/xdg-desktop-portal-gtk/


Flatpak and the xdg-desktop-portal have some pretty interesting ideas.

It's a huge shame there's almost zero documentation, both in the code, and for users / developers. I've heard about this feature before, but I've no idea how to make it work.


When needing to grant access to photos on iOS, the user can has three options:

- Deny access to photos

- Grant access to hand-picked photos\

- Grant access to all photos.

Picking the middle option opens an OS-handled photo picker where you choose which photos the application can access. The model works pretty well in balancing flexibility, security and convenience.

Something else _many_ apps support, is just pasting a photo. So if I want to post a photo on Twitter, I can just copy it from my photo app, and paste it there. Twitter has access to no photos on the system at all, it merely receives that one.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: