Comment by api | Hacker News Reader

Comment by api | Hacker News Reader

Parent Full thread

Security in a complex interdependent software ecosystem is untenable.

Period.

NodeJS/npm is in no way unique here. Apt, yum, gem, Homebrew, Docker hub, etc. are just as bad if not worse, not to mention "git clone" followed by "./configure" or "make." Any time you bring down code onto your machine and execute it you are... well... bringing down code onto your machine and executing it.

I've been increasingly thinking that this could be a very fertile area for AI research. Security is really an AI hard problem. There is no combination of sandboxing, permissions, auditing, formulaic static code analysis, firewall hacks, etc. that will yield a system that is both (a) usable/convenient and (b) secure.

Take 'npm' for instance. It's amazingly convenient but it (and all other packagers like it) is a security nightmare. Operating securely would require one to set up a shadow mirror of the entire NodeJS ecosystem and then have someone ($$$$$) manually audit every single thing in there that you are going to use and every single change that comes down from above. That's not tenable for anyone but the most lavishly funded organizations, and anything like that is universally reviled by developers since it slows them down. I've worked in environments like that before (government), and we had people quit because it was just "impossible to do my work."

The real problem is that things you run have full access to anything that you as a user have. In a more ideal security scenario, one that I've been pondering for many years, every single program has its own sandbox to play in, and can't see or affect your other user data. I'm sure that mobile devices are doing very similar things.

An "Open File" dialog box would let the user see exactly what they're picking, but just return an opaque & reusable handle to the program, meaning there's no change to the user experience. There would be more permission requests to the user in other circumstances, but that's the result of distrusting code that's running on your box.

I wouldn't expect an AI to try to preempt all the problems of a black-list style system, but rather a white-list as above would be far more manageable.

Isn't that basically what OS X app sandboxing is? Well, the results of Open File aren't an opaque blob, but the app doesn't have permission to access files outside its sandbox until the user uses the Open dialog, which grants the app access to the file in question.

This is basically how mobile apps have ended up, and it works relatively well

Maybe it's not too late to do the same on desktop!

> git clone" followed by "./configure" or "make."

Actually, you don't even need to follow it with ./configure or make.. An ext:// git url to clone from will execute arbitrary code:

http://www.vuxml.org/freebsd/7f645ee5-7681-11e5-8519-005056a...

This is a recurring theme within the Unix world — amongst others, vulnerable programs have included tar(1), xterm(1), and vim(1), and they always stem from the eagerness of the authors to provide both the ability to run shell commands, and the ability to run commands from untrusted sources; the fix is to limit the extended ability to trusted sources. But when reported, it (1) gets fixed quickly, and (2) leads to an uproar within the community. Here it has been a wontfix: works as expected, and will likely stay that way.

> There is no combination of sandboxing, permissions, auditing, formulaic static code analysis, firewall hacks, etc. that will yield a system that is both (a) usable/convenient and (b) secure.

https://en.wikipedia.org/wiki/Object-capability_model contradicts this, or anyway offers an alternative to the pile of hacks. It's true that none of the systems listed there are familiar; it's very hard to supplant the basic assumptions we've built on and built on since the 1970s.

Seems like a complexity explosion.

Un-forgeable references can be created using crypto. In a way things like Bitcoin addresses or cryptographically authenticated network endpoint addresses might qualify.

Those sorts of references support the capability model, yes, and they're the best you can do in a distributed system. They don't fit the object capability model because an overtly confined process can smuggle a reference out to a confederate via covert channels -- timing, power, etc.

So why did I bring up the less general model? Because the parent comment claimed usable security is impossible, even at the local level. If local machines have no security, the distributed case isn't going to be any better.

The complexity explosion I'm seeing is in the bail-and-patch approach.

I don't think a super detailed object permission model would be less complex than bail and patch. Bail and patch is after all just the ad hoc input and adjustment of rules. It's an AI hard problem because the complexity just is and you have to deal with it.

See "Admonition and designation" in this short paper "Aligning security and usability": http://people.cs.vt.edu/~kafura/cs6204/Readings/Usability/Al...

Security isn't a separable concern; the epicycles grow out of trying to treat it as separable -- you have your program, and then you have your rules restricting the program. ('By admonition' in the paper.)

Here's a modern example of the alternative: https://sandstorm.io/how-it-works#powerbox "Notice how in this example, the application never gains the ability to send spam. And yet, the user experience is no worse and arguably better than before. The user is never prompted with any sort of security questions, yet the app is only able to email them with their consent."

P.S. if my remarks came across as combative, I didn't mean them to. I'm just offering links about how some of us think we're not stuck with the current untenable situation -- life can get better.

Seems like you should just accept the risks and isolate your systems as much as possible, i.e. depend only on ephemeral data and restart frequently.

apt and yum are emphatically better since at least they verify their sources and maintainers and sign packages, and it doesn't really require much compared to the effort put into actually writing all that packaged software. These scripting language packaging systems have none of that.

Reply on news.ycombinator.com