Hacker News Reader

Comment by mikewarot | Hacker News Reader

That's funny... the InfoSec community has no clue about what it takes to actually secure a computer. It was figured out in the 1970s[1], after issues with mixed levels of secret information couldn't be handled quickly in the Viet Nam conflict, and is now mostly forgotten.

You can take $5 from your wallet and hand it to a stranger, without needing to trust them with everything in your wallet.

You can not take a single file in a folder and hand it to an executable, without needing to trust it with everything on your computer.

[1] https://en.wikipedia.org/wiki/Multilevel_security

View on HN

I think you're projecting a bit here. This is not only a well known approach, it's implemented in many ways.

> You can not take a single file in a folder and hand it to an executable

Here's a few things that achieve this that I directly used recently (and I'm sure there's way more): selinux, apparmor, linux namespaces, AWS IAM roles, path mapping over RDP, flatpak portals, android data, google drive sharing, google photos albums, windows ACLs, probably some more...

The idea is alive and doing well, but it can't be applied the same way it was in the military... because people don't care enough and they don't have a good reason to care. "disable selinux to make your app work" is a meme at this point, because labeling your system is a HARD problem. But the idea that Infosec in general is not aware of the approach is silly. The principle of least privilege is probably the most known idea everyone's aware of.

>because people don't care enough and they don't have a good reason to care

Users do care, but they're not given an OS that works in a sane manner to enforce their wishes. You can't bolt this stuff on after the fact without a lot of grief.

Strongly disagree and we've got receipts too. Even a basic search for selinux-related issues will show you how many people want to disable it compared to how many want to understand it. It's not users either. Developers who should know better and who should distribute the policies that users need in the first place also start their installation instructions with "disable selinux".

It's not even selinux specific - "everyone's a domain admin" is also a meme in security in the enterprise windows world where the permissions are actually a bit easier to manage. One of the main complaints about AWS complexity are IAM policies. There's just no way around it - this is inherently complex and a generic user does not care to learn how to deal with this. When you simplify it (like mobile phones do) on the other hand, there will be lots of people (rightfully) complaining about not being able to use the files between applications - a common complaint about iOS environment.

Forcing the user to decide ahead of time exactly what files are required goes against the purpose of a computer. It is a run-time choice, not an administrative one.

SE linux et al solve the wrong problem, which is why we all hate it.

Selinux is only one of the tech I mentioned. Flatpak portals do access query at runtime instead. But if you hold MLS and its military origins as an example, keep in mind those were very much labelled ahead of time and there's lots of administration involved.

Do you have any more information on this issue, what you mean, and the topic? I think I'm getting this but want to read more to understand.

Are you saying modern Operating systems are inherently insecure in what is allowed to use those spaces? You mentioned the dollar analogy. Someone else mentioned Androids storage access service.

I'm understanding it like this. Youre saying systems of access control within the kernel space are a known and used resource, but practices like this are ignored in the infosec world. Am I getting it?

I read HN partially to learn about cybersecurity is why I ask.

Current operating systems allow the program to directly access files, which is the way they've worked historically. This means that if the program is compromised, all the files the user is allowed to access on the system are at risk.

A better way to deal with this is to use an operating system that doesn't trust applications with access to files by default, and instead uses it's own dialogs to allow the user to select files for access, and only give capabilities/handles to those files to the application.

technically you can severely limit what an app can see and do on a modern OS (inc. limiting it to only specific files), but it's so complicated nobody does it. definitely not as convenient as 'here program, please read only this file right now'

(fwiw HN is not a great place to learn security, but I don't have better recs either)

Not sure if this is exactly what the person you replied to is talking about, but I recently looked through a list of tools for restricting the permissions of programs: https://www.macchaffee.com/blog/2023/hacking-myself/

Spoiler: they're all kinda bad, but macOS sandboxing is promising

> You can not take a single file in a folder and hand it to an executable, without needing to trust it with everything on your computer

iOS works this way. This is a problem that has real, commercially viable solutions. There are many real criticisms of the way security practitioners execute their craft (passwords and 2FA are littered with HCI failures) but something as well studied as sandboxing is not one.

> You can not take a single file in a folder and hand it to an executable

You totally can, with macOS and iOS’s sandboxing model.

While that's an interesting option for the developer, it doesn't appear to be something the end user can use on any random executable. (I'd LOVE to be wrong)

As with the Android thread above, this is encouraging news.

On macOS you can provide your own additional sandboxing rules to any random executable via sandbox-exec(1). (No, it's not user friendly.)

This tool make it easier to use: https://github.com/lynaghk/sandboxtron

Android's storage access framework makes me want a strong drink, but it does solve exactly that problem.

That's cool, it's a PowerBox implementation. Instead of putting up a dialog box, then accessing the file named by that dialog (which requires access to ALL the users files), the system puts up the dialog and gives you the handle/capability to access ONLY the files the user chose.

Awesome!

UWP also offers such capabilities, but allas the Win32 revolt coupled with Microsoft's mismanagement, killed it.

You have to trust them to not attack you while you’re fiddling/looking at your wallet.

I guess MLS works for the military but object-capability sandboxing is a better fit for most other cases. Of course legacy compatibility is slowing adoption of security in general.

This has almost no relation to the actual topic…?

Reply on news.ycombinator.com