Hacker News Reader

Comment by rcrisan | Hacker News Reader

perhaps this is the worst possible abstraction to be protected by a security framework.

How is that? Per-process namespaces in Plan 9 seem like a good idea for isolation. "Everything is a file," but what is and isn't accessible can be managed on a per-process level.

In POSIX we only generally get a user/group level of granularity which seems to practically mean that only daemons are completely isolated.

Per process won’t be good enough in a different app that does legitimately need `/net`, just not when displaying file:/// links inside HTML pages.

I disagree. Use a second process that has a limited namespace where you've mounted only the local files you want an HTML document to be able to refer to and an IPC socket marked for exclusive use. The first process resolves file links and reads file contents via IPC to the second process.

I can see a way this would be useful to use the same abstraction to limit app/user web access to a single domain.

For instance the dropbox binary can only access "/home/dropbox" and "/net/dropbox.com" if this was more well-known/used.

This can be done with a proper capability system.

IMO not so much. Just assume all files are malicious unless accompanied by metadata saying otherwise. That is pretty much the status quo already.

Except we have some grandfathered file types that are implicitly trusted.

In the article, the remote file's contents were not malicious, but merely trying to access it was. That would require a very different security posture to "assume all files are malicious".

> the remote file's contents were not malicious

until ... one day ... they are!

The remote file is only one of two files in the story.

And what about malicious metadata?

I don't think "everything is a file" is necessarily bad. What's worse is "every application I run has access to every resource that the OS gives my user access to".

Would be nice if the operating system could set up a fresh, temporary "user" for each application installed, and instead run the application as that user, who starts out with no access to computing resources. Maybe some existing systems already sandbox apps into their own unprivileged users, I don't know, but it would probably be very secure.

Modern operating systems can; there is quite granular control.

But often when such sandboxes are attempted, it turns out that it often became more complex than originally thought, and applications need many resources which were not originally considered, so they are given those resources, and very often those resources can be used again to construct more resources or otherwise to some measure escape the sandbox.

I believe this is how Qubes OS is supposed to operate.

On the contrary, it's very good design.

> perhaps this is the worst possible abstraction to be protected by a security framework.

I honestly don't understand how anyone with at least a basic understanding of how OSes are designed and operated could ever arrive at that conclusion. The layers of wrong assumptions required to support that assertion are in the level of "not even wrong" confusions.

Reply on news.ycombinator.com