
The Ethos Operating System - wbl
https://www.ethos-os.org/
======
pjmlp
It would be nice if people did not reuse operating systems names:

Insight ETHOS: On Object-Orientation in Operating Systems (1992)

[http://e-collection.library.ethz.ch/eserv/eth:38713/eth-3871...](http://e-collection.library.ethz.ch/eserv/eth:38713/eth-38713-02.pdf)

------
zenbowman
I love this. These kinds of large, moonshot projects are exactly what
university research labs need to work on to move us forward.

~~~
GauntletWizard
I love this. These projects almost certainly ultimately fail, get laughed at,
and then end up educating us anyway, whether for what to do or what _not_ to
do. I expect I'll probably see some hilarious things from it early on, laugh
at it's idealism and mistakes, and in 10 years I'll be using tech designed by
it's apostles.

~~~
serf
reminds me of Plan9.

We all talk about how silly it is and has been for years, while simultaneously
extolling the values behind the development ideas that Plan 9 follows, and the
good practices it teaches in regards to OS development.

~~~
chao-
No one I know, who knows enough about systems to know what Plan9 is, looked so
little into the details such that they find it "silly".

~~~
Yorrrick
I call it silly too. While also admiring many of its ideals.

------
mattdeboard
Ok, surely, after 5 hours and 37 comments I cannot be the only one who
wondered if this was a commercialization of LosethOS. Right?

~~~
userbinator
The naming is rather coincidental, as is the fact that it appears to be based
on principles that are the _exact opposite_ of LoseThos.

------
macrael
"The need which will drive new OS adoption is security."

Regardless as to wether or not Ethos is the next widespread OS, that line
rings very true.

~~~
kkowalczyk
It's actually very false.

"Security" is an invisible quality, by which I mean it cannot be easily
observed and because of that it cannot be easily compared and because of that
is not going to drive adoption.

This is in contrast to visible qualities: price, performance, availability of
the source code and its licensing terms, size of the ecosystem (number of
applications for the OS, number of books, articles, conferences, programmers
who know how to program for it) etc.

How exactly will you demonstrate that Ethos is more secure than, say, OpenBSD?

~~~
Aqueous
I think it's more about the possibility of guarantees.

OpenBSD has un-typed IO. Typed IO gives you guarantees that un-typed IO can
never give you. For starters, a number that doesn't validate properly as an
Int, for instance, will simply not be able to pass through, potentially
stopping if not Heartbleed then bugs like Heartbleed.

Don't you think companies and other interests would like stronger guarantees,
especially when they're running applications that protect information that
hackers and foreign governments and other companies would love to see?

~~~
vidarh
Until it becomes difficult to work with and is perceived by someone as slowing
them down, at which point someone will come up with the bright idea of typing
the io channel to a suitable type for layering an untyped stream over.

~~~
JonSolworth
This is the reason why we believe the Tao--the way--is essential to an OS. It
is the programming paradigms and use, combined with OS semantics, which is the
genius of UNIX.

------
jude-
So, I read a few of the papers. I'm hoping the Ethos OS folks are on this
forum, since I have a couple questions and concerns.

First, my current understanding of the OS:

Networking TL;DR: Their protocol is called MinimaLT, and it effectively
replaces TCP/IP. Traffic sent through a MinmaLT channel is encrypted and
MAC'ed by the OS. Each user has a public key, which gets submitted to the
remote host for each MinimaLT channel. The public key identifies processes
belonging to that user on both endpoints. The user can generate a new
public/private key as often as once per connection to allow for anonymity. The
OS maintains one channel per host-to-host tunnel, and multiplexes it across
applications.

Key management TL;DR: There exists an organization-wide key directory service
and ephemeral key upload service. Servers register and re-distribute their
ephemeral keys to their local key upload service, which synchronizes them with
the directory service. Clients connect to their local directory service to get
the ephemeral keys for other servers. The system scales up by piggybacking on
DNSSEC--the directory service delivers its local servers' ephemeral keys to
other directory services outside the organization by embedding them in short-
lived DNS records (which then get cached).

Questions:

* It's not clear to me how a server comes to trust a user's public key. Is it trust-on-first-use? If so, how does a user revoke the public key? For example, if Mal stole Alice's key, now Bob's server thinks Mal's actions are from Alice. What do Bob and Alice do then?

* It's not clear to me how the directory service and key upload service come to trust a local server. Is looks like this is something the local admin has to do manually?

Concerns:

* I'm not sure if this is more secure; in fact, I think it's less secure than SSL. The authenticity and integrity of ephemeral server public keys are backed by DNSSEC's security. So, this scheme effectively replaces a bunch of (presumably) independent TLS CAs with just one: the DNS root. You can bet the NSA has the private key.

* I don't like how the network architecture couples key distribution to name resolution, which I view as orthogonal concerns. This design puts both under the control of the same administative entity, which makes it easy for that administrative entity to trick clients into communicating with the wrong servers.

* MinimaLT isn't amenable to content caching. How does a CDN know that two ciphertexts are really e.g. the same image file? If it can tell, then the CDN can break your end-to-end encryption. If it can't tell, then the origin server can't scale.

~~~
borando
_The system scales up by piggybacking on DNSSEC_

You're missing the major point: MinimaLT will initially use X.509 (since it's
already deployed). A future protocol upgrade will support, if I'm not
mistaken, sayI.

DNS Security (e.g. DNSCurve, DNSCrypt, or even DNSSEC) adds a second layer of
security: keys are transmitted in DNS records, and server auth is done via
X.509.

This means an attacker would have to break both X.509 _and_ DNS.

 _I 'm not sure if this is more secure; in fact, I think it's less secure than
SSL_

I believe the above point addresses your concern. In addition, MinimaLT's
Curve25519 + Salsa20-Poly1305 is superior to any ciphersuite found in TLS.

~~~
jude-
Okay, that was not immediately clear. Thanks! :)

------
chewbacha
Anytime something restricts contributions based on academics I feel a little
sad.

This should be completely open, not just to college researchers and PhDs.

~~~
sept
Former lead kernel developer for Ethos has released source for OpenXCI:

[http://comments.gmane.org/gmane.comp.emulators.xen.user/8208...](http://comments.gmane.org/gmane.comp.emulators.xen.user/82080)
[http://article.gmane.org/gmane.comp.emulators.xen.user/81902...](http://article.gmane.org/gmane.comp.emulators.xen.user/81902/match=)

Related OSS projects are [http://qubes-os.org](http://qubes-os.org) and
[http://genode.org/](http://genode.org/)

------
peterwwillis
> We need a well-designed API

Nobody can agree on what that is.

> as simple as possible

Turn an incredibly complex operation into a simple one? Assuming we could make
it sufficiently simple, what do you do when someone needs a new simple feature
_like pinging?_

> we need multiple independent quality implementations of that API

Where are all the experienced cryptographers waiting in the wings to reinvent
your wheel five times?

> if one turns out to be crap, people can switch to a better one in a matter
> of hours

 _After_ the exploit has been found, _after two years_ , to switch to
something which _might also have the same flaw?_

Somehow this doesn't seem like a good solution.

------
dgreensp
Today's software requires constant patches to "stay" secure. If you stop
patching your OpenSSL or your Windows XP, its security will degrade -- but the
software is the same; all that's changed is some hacker was able to construct
an MS Paint file that executes arbitrary code, or some other ridiculous
nonsense.

Large software systems will always have bugs and be difficult to understand in
their entirety, but they could be made orders of magnitude easier to secure by
not giving every line of code the potential to compromise the system.

------
ansible
I looked around a bit, but I couldn't find a good introduction to the design
principals and such. Is there a good overview in one of the papers?

~~~
JonSolworth
Writing up the design principals of Ethos is one of my goals this summer. The
short description is:

(1) Strong security services (authentication, authorization, encryption,
isolation) (2) Higher level, less error prone semantics for all OS
interaction. (3) Security guarantees derived from system layering (4) Highly
composable semantics

Note that only (1) deals with security-specific code. The rest deals with
overall code quality.

------
nroose
I guess the ethos OS will not support any windows less than 1280 px wide.

~~~
JasonFruit
I'm sure there's something I'm not getting here. Can you explain?

~~~
xiaq
He/she is complaining about the webpage being too wide.

