|
| ▲ | hibikir 26 minutes ago | parent | next [-] |
| 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 5 minutes ago | parent [-] | | > 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 Facebook's pinky promises. |
|
|
| ▲ | black_knight 2 hours ago | parent | prev | next [-] |
| 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. |
| |
| ▲ | Findecanor 15 minutes ago | parent | next [-] | | Redox is also moving towards having capabilities mapped to fd's, somewhat like Capsicum. Their recent presentation at FOSDEM: https://fosdem.org/2026/schedule/event/KSK9RB-capability-bas... | |
| ▲ | Noumenon72 24 minutes ago | parent | prev | next [-] | | Seems like a bad time to bring this up when it wouldn't have helped with this attack at all. | |
| ▲ | h4x0rr 2 hours ago | parent | prev [-] | | Eli5, what is that supposed to mean? | | |
| ▲ | kibwen an hour ago | parent | next [-] | | 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 | |
| ▲ | an hour ago | parent | prev [-] | | [deleted] |
|
|
|
| ▲ | ashishb 2 hours ago | parent | prev | next [-] |
| 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. |
| |
| ▲ | lifeisgood99 2 hours ago | parent | next [-] | | 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 an hour ago | parent [-] | | I would configure mailman with permanent write access to the mailbox area That's what I with my sandbox right now |
| |
| ▲ | 2 hours ago | parent | prev [-] | | [deleted] |
|
|
| ▲ | symaxian 3 hours ago | parent | prev | next [-] |
| Sand-boxing such as in Snap and Flatpak? |
| |
| ▲ | troad 3 hours ago | parent | next [-] | | 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. | | |
| ▲ | FergusArgyll 2 hours ago | parent | next [-] | | Doesn't it use bwrap under the hood? what's wrong with that? | | |
| ▲ | okanat an hour ago | parent [-] | | Many apps require unnecessarily broad permissions with Flatpak. Unlike Android and iOS apps they weren't designed for environments with limited permissions. |
| |
| ▲ | jacobgkau 3 hours ago | parent | prev [-] | | 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.) |
| |
| ▲ | nextos 3 hours ago | parent | prev [-] | | Snap and Flatpak do both sandboxing and package management. You can use the underlying sandboxing with bwrap. A good alternative is firejail. They are quite easy to use. I prefer to centralize package management to my distro, but I value their sandboxing efforts. Personally, I think it's time to take sandboxing seriously. Supply chain attacks keep happening. Defense is depth is the way. |
|
|
| ▲ | jacobgkau 3 hours ago | parent | prev | next [-] |
| > getting a lot of slack recently I think you mean a lot of flak? Slack would kind of be the opposite. |
| |
| ▲ | troad 3 hours ago | parent [-] | | Haha, yes, corrected. Thank you. I have a habit of fusing unrelated expressions. |
|
|
| ▲ | its_magic 3 hours ago | parent | prev [-] |
| 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 3 hours ago | parent | next [-] | | > 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? | | | |
| ▲ | rectang 3 hours ago | parent | prev [-] | | 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 2 hours ago | parent [-] | | 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 23 minutes ago | parent [-] | | 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”? |
|
|
|