>>dreemt+(OP)
This sounds quite interesting. Joanna Rutkowska has some some serious low level security work, including work on Xen.

Xen was chosen for a minimal TCB, with the plan of moving stuff out of Dom0 like networking now and filesystem(s?) next?/later.

Of particular interest is the graphics system, where the code running in Dom0 was kept as small as possible (2,500 LOC, with no plans for fancy 3D).

ADDED: From a message on the mailing list, an explicit decision was made that each VM would have its own X server: applications sharing one are not isolated, trying to fix that would be "non-trivial" (quite an understatement!) and "the X protocol and X server alone present a huge attack surface". Indeed....

If I had a spare machine that could run it I'd be kicking the tires right now.

>>dreemt+(OP)
This seems analogous, in principle, to a system with fully utilized role-based access control - like security-enhanced linux or similar - although easier to grok perhaps?

Is there a fundamental difference? (I understand the technical difference - I'm asking more in terms of semantics - what makes this a better security model?)

>>dedwar+L1
I think the granularity is so different that it's a difference in kind.

And the granularity is at a very high level; I gather few want to wade into the details of SELinux, and if I hadn't been exposed to the concepts for 30 years (sic, I started learning Multics in 1979) I probably would have just turned off SELinux when I was using Fedora last year.

>>dreemt+(OP)
I'm not sure how putting things on different VMs improves security - If the VMs can communicate with each other seamlessly enough for the system to be usable, then there's a hole big enough for the virus to just kind of step through and damage the other machines without even running on them.

On the other hand, if usability drops because the VMs are actually isolated - and this seems to be the approach that was taken - users will simply consolidate more applications on one machine, and infect everything at once this way.

>>ori_b+o4
Perhaps you could define "seamlessly enough for the system to be usable"?

The architecture envisions consolidating applications by domain, e.g. one for your social networking, one for banking (and that would be very locked down, e.g. http(s) only), etc.

It accepts that there will be comprise (or so I gather) and is explicitly designed to mitigate it. For me, that improves security significantly (I already do a form of this by running three browser instances on two machines).

It's a very pragmatic approach, and I can see from the lead's background why she'd take it.

>>dreemt+(OP)
Can we please, please stop saying that things are "ultra secure" before they've been adequately beaten on? Saying that your goal is a very high level of security is fine (I do the same), but saying that directly translates to security out the gate is very deceptive. This has great potential for security, but it's not known to be secure yet; only time will give you that.

>>daeken+Nd
I fear your goal will be achieved in the computer press about the same time the tabloids stop giving us headlines such as "HEADLESS BODY IN TOPLESS BAR" (the New York Post on a murder in 1983).