5 ms·

MacOS has been getting a lot of flak recently for (correct) UI reasons, but I honestly feel like they're the closest to the money with granular app permissions.

by troad 9mo ago

MacOS has been getting a lot of flak recently for (correct) UI reasons, but I honestly feel like they're the closest to the money with granular app permissions. Linux people are very resistant to this, but the future is going to be sandboxed iOS style apps. Not because OS vendors want to control what apps do, but because users do. If the FOSS community continues to ignore proper security sandboxing and distribution of end user applications, then it will just end up entirely centralised in one of the big tech companies, as it already is on iOS and macOS by Apple.

its_magic 9mo ago
I'm sure that will contribute to the illusion of security, but in reality the system is thoroughly backdoored on every level from the CPU on up, and everyone knows it. There is no such thing as computer security, in general, at this point in history.
- ashishb 9mo ago
  > but in reality the system is thoroughly backdoored on every level from the CPU on up, and everyone knows it. Indeed. Why lock your car door as anyone can unlock and steal it by learning lock-picking?
  - its_magic 9mo ago
    Residents of San Francisco ask themselves that question all the time.
- rectang 9mo ago
  There's a subtlety that's missing here: if your threat model doesn't include the actors who can access those backdoors, then computer security isn't so bad these days. That subtlety is important because it explains how the backdoors have snuck in — most people feel safe because they are not targeted, so there's no hue and cry.
  - autoexec 9mo ago
    The backdoors snuck in because literally everyone is being targeted. Few people ever see the impact of that themselves or understand the chain of events that brought those impacts about.
    - rectang 9mo ago
      And yet, many people perceive a difference between “getting hacked” and “not getting hacked” and believe that certain precautions materially affect whether or not they end up having to deal with a hacking event. Are they wrong? Do gradations of vulnerability exist? Is there only one threat model, “you’re already screwed and nothing matters”?
- themafia 9mo ago
  I'm sure you're right; however, there is still a distinction between the state using my device against me and unaffiliated or foreign states using my device against me or more likely simply to generate cash for themselves. It's still worth solving one of these problems.
  - its_magic 8mo ago
    A distinction without a difference. One mafia is as bad as another. One screws you in the short term, the other screws you in the long term, and much worse. The problem in both cases is the massive attack surface at every level of the system. Most of these proposals about "security" are just rearranging deckchairs on the Titanic. If you can't keep a nation state out (and you're referring to your own state, right?) then you can't keep a lone wolf hacker out either, because in either case that's who's doing the work.
symaxian 9mo ago
Sand-boxing such as in Snap and Flatpak?
- troad 9mo ago
  Notoriously not actually secure, at least in the case of Flatpak. (Can't speak to Snap) Not sure how something can be called a sandbox without the actual box part. As Siri is to AI, Flatpak is to sandboxes.
  - jacobgkau 9mo ago
    The XDG portal standards being developed to provide permissions to apps (and allow users to manage them), including those installed via Flatpak, will continue to be useful if and when the sandboxing security of Flatpaks are improved. (In fact, having the frontend management part in place is kind of a prerequisite to really enforcing a lot of restrictions on apps, lest they just stop working suddenly.)
  - FergusArgyll 9mo ago
    Doesn't it use bwrap under the hood? what's wrong with that?
    - okanat 9mo ago
      Many apps require unnecessarily broad permissions with Flatpak. Unlike Android and iOS apps they weren't designed for environments with limited permissions.
      - IsTom 9mo ago
        > Unlike Android My experience with android apps seems to be different. Every other app seems to be asking for contacts or calling or access to files.
        HPsquared 9mo ago
        You can usually deny those. If they ask for them without a good reason, that's already suspicious.
jacobgkau 9mo ago
> getting a lot of slack recently I think you mean a lot of flak? Slack would kind of be the opposite.
- troad 9mo ago
  Haha, yes, corrected. Thank you. I have a habit of fusing unrelated expressions.
ashishb 9mo ago
It also has persistent permissions. Think about it from a real world perspective. I knock on your door. You invite me to sit with you in your living room. I can't easily sneak into your bed room. Further, your temporary access ends as soon as you exit my house. The same should happen with apps. When I run 'notepad dir1/file1.txt', the package should not sneakily be able to access dir2. Further, as soon as I exit the process, the permission to access dir1 should end as well.
- deleted 9mo ago
  [deleted]
- lifeisgood99 9mo ago
  A better example would be requiring the mailman to obtain written permission to step on your property every day. Convenience trumps maximal security for most people.
  - ashishb 9mo ago
    I would configure mailman with permanent write access to the mailbox area That's what I with my sandbox right now
    - bombolo 9mo ago
      With systemd or firejail it's quite easy to do this sort of thing on linux.
  - BobbyTables2 9mo ago
    The early version of UAC in Windows did that… Asking continuously is worse than not asking at all…
    - expedition32 9mo ago
      Some of the stuff that I install is actually meant to behave like malware. But fine lock windows down for normal users as long as I can still disable all the security. We don't need another Apple.
black_knight 9mo ago
I think we could get a lot further if we implement proper capability based security. Meaning that the authority to perform actions follows the objects around. I think that is how we get powerful tools and freedom, but still address the security issues and actually achieve the principle of least privilege. For FreeBSD there is capsicum, but it seems a bit inflexible to me. Would love to see more experiments on Linux and the BSDs for this.
- h4x0rr 9mo ago
  Eli5, what is that supposed to mean?
  - deleted 9mo ago
    [deleted]
  - kibwen 9mo ago
    The original model of computer security is "anything running on the machine can do and touch anything it wants to". A slightly more advanced model, which is the default for OSes today, is to have a notion of a "user", and then you grant certain permissions to a user. For example, for something like Unix, you have the read/write/execute permissions on files that differ for each user. The security mentioned above just involves defining more such permissions than were historically provided by Unix. But the holy grail of security models is called "capability-based security", which is above and beyond what any current popular OS provides. Rather than the current model which just involves talking about what a process can do (the verbs of the system), a capability involves taking about what a process can do an operation on (the nouns of the system). A "capability" is an unforgeable cryptographic token, managed by the OS itself (sort of like how a typical OS tracks file handles), which grants access to a certain object. Crucially, this then allows processes to delegate tasks to other processes in a secure way. Because tokens are cryptographically unforgeable, the only way that a process could have possibly gotten the permission to operate on a resource is if it were delegated that permission by some other process. And when delegating, processes can further lock down a capability, e.g. by turning it from read/write to read-only, or they can e.g. completely give up a capability and pass ownership to the other process, etc. https://en.wikipedia.org/wiki/Capability-based_security https://en.wikipedia.org/wiki/Capability-based_security
hibikir 9mo ago
Yet we look at phones, and we see people accepting outrageous permissions for many apps: They might rely on snooping into you for ads, or anything else, and yet the apps sell, and have no problem staying in stores. So when it's all said and done, I do not expect practical levels of actual isolation to be that great.
- troad 9mo ago
  > Yet we look at phones, and we see people accepting outrageous permissions for many apps The data doesn't support the suggestion that this is happening on any mass scale. When Apple made app tracking opt-in rather than opt-out in iOS 14 ("App Tracking Transparency"), 80-90% of users refused to give consent. It does happen more when users are tricked (dare I say unlawfully defrauded?) into accepting, such as when installing Windows, when launching Edge for the first time, etc. This is why externally-imposed sandboxing is a superior model to Zuck's pinky promises.
  - int_19h 9mo ago
    In the case of iOS, the choice was to use the app with those permissions or without them, so of course people prefer to not opt-in - why would they? But when the choice is between using the app with such spyware in it, or not using it at all, people do accept the outrageous permissions the spyware needs.
- Analemma_ 9mo ago
  For all its other problems, App Store review prevents a lot of this: you have to explain why your app needs entitlements A, B and C, and they will reject your update if they don't think your explanation is good enough. It's not a perfect system, but iOS applications don't actually do all that much snooping.
BobbyTables2 9mo ago
I intensely hate that a stupid application can modify .bashrc and permanently persist itself. Sure, in theory, SELinux could prevent this. But seems like an uphill battle if my policies conflict with the distro’s. I’d also have to “absorb” their policies’ mental model first…
- themafia 9mo ago
  I tend to think things like .bashrc or .zshrc are bad ideas anyways. Not that you asked but I think the simpler solution is to have those files be owned by root and not writable by the user. You're probably not modifying them that often anyways.
deleted 9mo ago
[deleted]
TheChaplain 9mo ago
> Linux people are very resistant to this Because security people often does not know the balance between security and usability, and we end up with software that is crippled and annoying to use.
bsder 9mo ago
> Linux people are very resistant to this, but the future is going to be sandboxed iOS style apps. Linux people are NOT resistant to this. Atomic desktops are picking up momentum and people are screaming for it. Snaps, flatpaks, appimages, etc. are all moving in that direction. As for plain development, sadly, the OS developers are simply ignoring the people asking. See: https://github.com/containers/toolbox/issues/183 https://github.com/containers/toolbox/issues/183 https://github.com/containers/toolbox/issues/348 https://github.com/containers/toolbox/issues/348 https://github.com/containers/toolbox/issues/1470 https://github.com/containers/toolbox/issues/1470 I'll leave it up to you to speculate why. Perhaps getting a bit of black eye and some negative attention from the Great Orange Website(tm) can light a fire under some folks.
cxr 9mo ago
It's truly perverse that, at the same time that desktop systems are trying to lock down what trusted, conventional native apps can and cannot do and/or access, you have the Chrome team pushing out proposals to expand what browsers allow websites to do to the user's file system, like silently/arbitrarily reading and writing to the user's disk—gated only behind a "Are you sure you want to allow this? Y/N"-style dialog that, for extremely good reasons, anyone with any sense about design and interaction has strongly opposed for the last 20+ years.
ddtaylor 9mo ago
Flatpak

by troad 9mo ago

its_magic 9mo ago

I'm sure that will contribute to the illusion of security, but in reality the system is thoroughly backdoored on every level from the CPU on up, and everyone knows it. There is no such thing as computer security, in general, at this point in history.

ashishb 9mo ago
> but in reality the system is thoroughly backdoored on every level from the CPU on up, and everyone knows it. Indeed. Why lock your car door as anyone can unlock and steal it by learning lock-picking?
- its_magic 9mo ago
  Residents of San Francisco ask themselves that question all the time.
rectang 9mo ago
There's a subtlety that's missing here: if your threat model doesn't include the actors who can access those backdoors, then computer security isn't so bad these days. That subtlety is important because it explains how the backdoors have snuck in — most people feel safe because they are not targeted, so there's no hue and cry.
- autoexec 9mo ago
  The backdoors snuck in because literally everyone is being targeted. Few people ever see the impact of that themselves or understand the chain of events that brought those impacts about.
  - rectang 9mo ago
    And yet, many people perceive a difference between “getting hacked” and “not getting hacked” and believe that certain precautions materially affect whether or not they end up having to deal with a hacking event. Are they wrong? Do gradations of vulnerability exist? Is there only one threat model, “you’re already screwed and nothing matters”?
themafia 9mo ago
I'm sure you're right; however, there is still a distinction between the state using my device against me and unaffiliated or foreign states using my device against me or more likely simply to generate cash for themselves. It's still worth solving one of these problems.
- its_magic 8mo ago
  A distinction without a difference. One mafia is as bad as another. One screws you in the short term, the other screws you in the long term, and much worse. The problem in both cases is the massive attack surface at every level of the system. Most of these proposals about "security" are just rearranging deckchairs on the Titanic. If you can't keep a nation state out (and you're referring to your own state, right?) then you can't keep a lone wolf hacker out either, because in either case that's who's doing the work.

symaxian 9mo ago

Sand-boxing such as in Snap and Flatpak?

troad 9mo ago
Notoriously not actually secure, at least in the case of Flatpak. (Can't speak to Snap) Not sure how something can be called a sandbox without the actual box part. As Siri is to AI, Flatpak is to sandboxes.
- jacobgkau 9mo ago
  The XDG portal standards being developed to provide permissions to apps (and allow users to manage them), including those installed via Flatpak, will continue to be useful if and when the sandboxing security of Flatpaks are improved. (In fact, having the frontend management part in place is kind of a prerequisite to really enforcing a lot of restrictions on apps, lest they just stop working suddenly.)
- FergusArgyll 9mo ago
  Doesn't it use bwrap under the hood? what's wrong with that?
  - okanat 9mo ago
    Many apps require unnecessarily broad permissions with Flatpak. Unlike Android and iOS apps they weren't designed for environments with limited permissions.
    - IsTom 9mo ago
      > Unlike Android My experience with android apps seems to be different. Every other app seems to be asking for contacts or calling or access to files.
      - HPsquared 9mo ago
        You can usually deny those. If they ask for them without a good reason, that's already suspicious.

jacobgkau 9mo ago

> getting a lot of slack recently I think you mean a lot of flak? Slack would kind of be the opposite.

troad 9mo ago
Haha, yes, corrected. Thank you. I have a habit of fusing unrelated expressions.

ashishb 9mo ago

It also has persistent permissions. Think about it from a real world perspective. I knock on your door. You invite me to sit with you in your living room. I can't easily sneak into your bed room. Further, your temporary access ends as soon as you exit my house. The same should happen with apps. When I run 'notepad dir1/file1.txt', the package should not sneakily be able to access dir2. Further, as soon as I exit the process, the permission to access dir1 should end as well.

deleted 9mo ago
[deleted]
lifeisgood99 9mo ago
A better example would be requiring the mailman to obtain written permission to step on your property every day. Convenience trumps maximal security for most people.
- ashishb 9mo ago
  I would configure mailman with permanent write access to the mailbox area That's what I with my sandbox right now
  - bombolo 9mo ago
    With systemd or firejail it's quite easy to do this sort of thing on linux.
- BobbyTables2 9mo ago
  The early version of UAC in Windows did that… Asking continuously is worse than not asking at all…
  - expedition32 9mo ago
    Some of the stuff that I install is actually meant to behave like malware. But fine lock windows down for normal users as long as I can still disable all the security. We don't need another Apple.

black_knight 9mo ago

I think we could get a lot further if we implement proper capability based security. Meaning that the authority to perform actions follows the objects around. I think that is how we get powerful tools and freedom, but still address the security issues and actually achieve the principle of least privilege. For FreeBSD there is capsicum, but it seems a bit inflexible to me. Would love to see more experiments on Linux and the BSDs for this.

h4x0rr 9mo ago
Eli5, what is that supposed to mean?
- deleted 9mo ago
  [deleted]
- kibwen 9mo ago
  The original model of computer security is "anything running on the machine can do and touch anything it wants to". A slightly more advanced model, which is the default for OSes today, is to have a notion of a "user", and then you grant certain permissions to a user. For example, for something like Unix, you have the read/write/execute permissions on files that differ for each user. The security mentioned above just involves defining more such permissions than were historically provided by Unix. But the holy grail of security models is called "capability-based security", which is above and beyond what any current popular OS provides. Rather than the current model which just involves talking about what a process can do (the verbs of the system), a capability involves taking about what a process can do an operation on (the nouns of the system). A "capability" is an unforgeable cryptographic token, managed by the OS itself (sort of like how a typical OS tracks file handles), which grants access to a certain object. Crucially, this then allows processes to delegate tasks to other processes in a secure way. Because tokens are cryptographically unforgeable, the only way that a process could have possibly gotten the permission to operate on a resource is if it were delegated that permission by some other process. And when delegating, processes can further lock down a capability, e.g. by turning it from read/write to read-only, or they can e.g. completely give up a capability and pass ownership to the other process, etc. https://en.wikipedia.org/wiki/Capability-based_security https://en.wikipedia.org/wiki/Capability-based_security

hibikir 9mo ago

Yet we look at phones, and we see people accepting outrageous permissions for many apps: They might rely on snooping into you for ads, or anything else, and yet the apps sell, and have no problem staying in stores. So when it's all said and done, I do not expect practical levels of actual isolation to be that great.

troad 9mo ago
> Yet we look at phones, and we see people accepting outrageous permissions for many apps The data doesn't support the suggestion that this is happening on any mass scale. When Apple made app tracking opt-in rather than opt-out in iOS 14 ("App Tracking Transparency"), 80-90% of users refused to give consent. It does happen more when users are tricked (dare I say unlawfully defrauded?) into accepting, such as when installing Windows, when launching Edge for the first time, etc. This is why externally-imposed sandboxing is a superior model to Zuck's pinky promises.
- int_19h 9mo ago
  In the case of iOS, the choice was to use the app with those permissions or without them, so of course people prefer to not opt-in - why would they? But when the choice is between using the app with such spyware in it, or not using it at all, people do accept the outrageous permissions the spyware needs.
Analemma_ 9mo ago
For all its other problems, App Store review prevents a lot of this: you have to explain why your app needs entitlements A, B and C, and they will reject your update if they don't think your explanation is good enough. It's not a perfect system, but iOS applications don't actually do all that much snooping.

BobbyTables2 9mo ago

I intensely hate that a stupid application can modify .bashrc and permanently persist itself. Sure, in theory, SELinux could prevent this. But seems like an uphill battle if my policies conflict with the distro’s. I’d also have to “absorb” their policies’ mental model first…

themafia 9mo ago
I tend to think things like .bashrc or .zshrc are bad ideas anyways. Not that you asked but I think the simpler solution is to have those files be owned by root and not writable by the user. You're probably not modifying them that often anyways.

deleted 9mo ago

[deleted]

TheChaplain 9mo ago

> Linux people are very resistant to this Because security people often does not know the balance between security and usability, and we end up with software that is crippled and annoying to use.

bsder 9mo ago

> Linux people are very resistant to this, but the future is going to be sandboxed iOS style apps. Linux people are NOT resistant to this. Atomic desktops are picking up momentum and people are screaming for it. Snaps, flatpaks, appimages, etc. are all moving in that direction. As for plain development, sadly, the OS developers are simply ignoring the people asking. See: https://github.com/containers/toolbox/issues/183 https://github.com/containers/toolbox/issues/183 https://github.com/containers/toolbox/issues/348 https://github.com/containers/toolbox/issues/348 https://github.com/containers/toolbox/issues/1470 https://github.com/containers/toolbox/issues/1470 I'll leave it up to you to speculate why. Perhaps getting a bit of black eye and some negative attention from the Great Orange Website(tm) can light a fire under some folks.

cxr 9mo ago

It's truly perverse that, at the same time that desktop systems are trying to lock down what trusted, conventional native apps can and cannot do and/or access, you have the Chrome team pushing out proposals to expand what browsers allow websites to do to the user's file system, like silently/arbitrarily reading and writing to the user's disk—gated only behind a "Are you sure you want to allow this? Y/N"-style dialog that, for extremely good reasons, anyone with any sense about design and interaction has strongly opposed for the last 20+ years.

ddtaylor 9mo ago

Flatpak