Hacker News Reader

Comment by tmp538394722 | Hacker News Reader

“Everything’s a file!”

> In Unix everything is a file. Files are files, folders are files, disks are files, your keyboard is a file, your mouth is a file, the air is a file, you can't breathe, your file lungs fill with files and you try to scream but only files come out oh god Dennis how could you do this

-- https://twitter.com/TartanLlama/status/1375045731644538882

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

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 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.

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.

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.

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.

> “Everything’s a file!”

I fail to see how HTTP and REST's "everything is a resource" paradigm is significantly different than UNIX's "everything is a file" paradigm, and I'm yet to see anyone claim that the freedom and power to open any HTML document (OMG a file!) made available through the internet is a mistake or a bad design decision.

Several ways. In Unix files are streams of bytes. In HTTP resources are complex entities with MIME types, multiple representations, encodings, etc. HTTP URL structure supports parameters and there is a method for providing data and obtaining a result back, a sort of RPC.

On the other side Unix has users and permissions, HTTP does not and you have to build your own.

Reply on news.ycombinator.com