[woodman]

So what, your definition of a solved problem is one that never occurs again due to uniform implementation of countermeasures? That isn't realistic. That is like saying that plane geometry isn't a solved problem because people are still walking around having not read Euclid's "Elements", doing geometry wrong.

[ObviousScience]

For the record, plane geometry wasn't solved by Euclid's "Elements"; the conjecture about the 5th postulate remained open for a substantial amount of time, and other axioms were introduced when it was pointed out that Euclid's work relied on numerous implied axioms.

[woodman]

Damn it. Well at least I can still trust in Plato's theory of forms.

[thevardanian]

Just because you've invented solar panels does not mean that you've solved the energy crisis. Sometimes the implementation of technology is just as inventive as the invention itself.

[woodman]

lol, ok lets break this down Barney style:

Converting sunlight to electricity is a solved problem. The "energy crisis" remains unsolved.

Jailing processes is a solved problem. Preventing users from shooting themselves in the foot remains unsolved.

Now let us reexamine the post:

> ...would be a helpful thing to build into modern operating systems...

Already built in.

> Why can’t we also have something analogous where different files or other system resources are only accessible to applications that have been approved for that access?

We do. Solved problem. Now if we want to prevent users from shooting themselves, that is a different problem.

That last paragraph sure makes it sound like the writer is unaware of these solution's existence... but let us suppose that he knows about them and is coming at it from your perspective. In that case I agree, we don't have a solution in place - and I'd love to see one in common use. I'd think you'd be able to implement such a system through package management for the majority of software, an added chroot step. That is why I included distro and application devs in those that share blame for the problem. Users are also included, to a smaller degree, because this is a known problem with a known solution.

[Chris_Newton]

I’m well aware of strategies using chroot, virtual machines, and the like. These are useful tools up to a point, but a long way short of what I would ideally like to see. For example, they restrict access at a very coarse level compared to the kinds of user/group/ACL models we use in many other contexts. By their nature, they also do not admit convenient ways to break out of the jail with the user’s explicit consent. Once you get beyond individual applications with their own dedicated file types and consider more generic cases like text editors working on text files that are likely to exist throughout a filesystem, this lack of flexibility is a serious limitation. Another key distinction is that chroot and the like are voluntary mechanisms, usually off by default and therefore not completely enforced by the OS.

Some systems mentioned in this HN discussion are closer to the kind of model I had in mind. As other posters have pointed out, the difficulty is how you structure a system so that it is reasonably effective by default but still usable by non-experts. I believe we could achieve this — or at least get much closer than the typical security models we use at the moment — but it will surely take a lot more thought and experimentation than we have attempted as an industry so far. Microsoft’s UAC mechanism makes an interesting case study here: it was fundamentally a reasonable idea, but the first implementation proved too intrusive for average users to tolerate and lost much of its effectiveness as a result.

[woodman]

It sounds to me like your ideal situation could be implemented with the tools we already have at hand - it is just an issue of default settings and how the package maintainers set compilation and installation options. Unless you really wanna go hardcore and advocate for something that is impossible for users/developers to break, which would most likely require a formally verified microkernel [0] - at the very least.

[0] http://en.wikipedia.org/wiki/L4_microkernel_family#High_assu...