Hacker News Reader

Comment by mikewarot | Hacker News Reader

Capability Based Security is a proven solution to computer security problems that arose in the Viet Nam conflict. Those problems keep cropping up here almost daily.

The simple truth is that access control lists aren't up to the task of protecting systems with persistent internet connections and mobile code. A Windows or Linux machine can not ever be made secure.

A microkernel, with the smallest possible attack surface, that never trusts driver code is the way forward. I don't care if the eventual winner is Fuchsia or Genode, all I want is momentum forward out of the morass that is the current Linux/Windows world.

I look forward to trying out Fuchsia and Genode in the next few months, and porting a Forth interpreter to each.

View on HN

What does the "Viet Nam conflict" have to do with capability-based security?

Due to possible enemy infiltration of our computer systems and spy networks, there were multiple levels of secret data that had to be coordinated to allow airstrikes (one level of secret information) to avoid enemy radar(a different level of secrets).

The location of enemy radar sites was very tightly held information, as knowing what we knew could reveal means and sources of information. The actual airstrikes would eventually be known by the destruction of enemy targets. It wasn't possible at the time to have a computer system which could allow the mixing of these levels of secrecy. This meant everything had to be done by hand.

The development of Multilevel Secure systems by the Air Force in the 1970s is a direct result of that experience.

> It wasn't possible at the time to have a computer system which could allow the mixing of these levels of secrecy. This meant everything had to be done by hand.

> The development of Multilevel Secure systems by the Air Force in the 1970s is a direct result of that experience.

BTW, this stuff is not just for Air Force folks, either. Multi-level security is the most principled approach around to efficiently mitigate pervasive information-disclosure vulnerabilities like Spectre. The current approach to mitigation has us flushing speculation contexts down the drain even when sensitive info is provably not at stake, which is wildly inefficient compared to what's theoretically possible.

I imagine it's a reference to https://blogs.tedneward.com/post/the-vietnam-of-computer-sci...

Interesting tangent, but no... not that.

I suspect a combination of 1) the US military having extensively studied this problem already. 2) that they did it a very long time ago.

I share your feeling, but I'd rather have a none isolated driver I can trust than an isolated one I cannot trust. My threat model includes fishy OEM doing borderline things.

In driver development I often see abstraction violations or very loose abstractions: news hw capabilities can't be accounted for when designing framework abstractions.

I have never done dev on windows, but I guess there is a reason why the form factor of things running windows is pretty limited. I don't see how you can have fixed interfaces in an ever evolving wold.

> I'd rather have a none isolated driver I can trust

We all would, but that doesn't seem practical given the market dynamics explained elsewhere in this thread.

Reply on news.ycombinator.com