using minix 3 as dom0

[Deep Coder]

Seems to me that with all the NSA revelations these days, have a small code base in DOM0 is more important than having a history of bugs being patched in the dom0 os. Since this is the case, why not use minix 3 as the dom0 os? Its code base is small and a lot of unix apps work on it, surely it wouldn't be such a huge task to shift to use minix?

[Vincent Penquerc'h]

On 16/04/14 21:38, Deep Coder wrote:
> Seems to me that with all the NSA revelations these days, have a small code base in DOM0 is more important than having a history of bugs being patched in the dom0 os. Since this is the case, why not use minix 3 as the dom0 os? Its code base is small and a lot of unix apps work on it, surely it wouldn't be such a huge task to shift to use minix?

I think it's the other way round. Once you can reach dom0, you're
finished. You want to keep Xen (and the interactions between Xen and the
VMs) small. Failing that, you want to keep the domU VMs small, as a last
chance to decrease attack surface to Xen. But mostly Xen. Since once you
get Xen, it's trivial to get whatever you're running in dom0.


That said, sure! It doesn't matter, so if you can get minix3 to run
there and run the Qubes tools, whatever works.

[Deep Coder]

Not really. You assume the user trusts qubes os. I think we can all agree that qubes os would make the perfect honey pot. The only way to verify it isn't one is to inspect the code yourself and then compile the code. But one cannot do that if the code is so large.

[Joanna Rutkowska]

Currently Dom0 plays the two roles:
1) Admin domain for the whole system
2) GUI domain (desktop composition, trusted decorations, input handling,
GPU handling)

Making the GUI domain is a highly-nontrivial challenge -- see e.g. this
article:

http://theinvisiblethings.blogspot.com/2010/09/untrusting-your-gui-subsystem.html

At when your GUI domain must be ultimately trusted, then it makes little
sense to divide it from the Admin domain (which is also ultimately trusted).

Yet, the GUI domain must really be based on some mainstream OS, because
it must have all the latest graphics drivers for all the latest GPUs,
as well as some reasonably nice desktop environment (window manager plus
some basic things like e.g. "Start menu"), which in turns implies e.g.
Xorg and all its dependencies.

In case of Qubes OS it is however not-so-bad, because Dom0 doesn't have
any networking, and generally exposes only very limited interfaces to
the VMs, all strictly controlled. Thus, we believe, that a chance to
exploit a bug in, say, some KDE applications or Xorg, is negligible even
if all those apps are terribly buggy (which they surly are).

I don't see any benefit with replacing Linux in Dom0 with Minix, because
you will likely need to bring some kind of GPU drivers,
Xorg-replacement, and KDE-replacement anyway.

For Qubes R3 we're considering to actually move the GUI domain out from
the dom0, but this is mostly for maintenance and other reasons.

joanna.

[Deep Coder]

Yes but you haven't asnwered my question. What about the kernel code? What about inspecting the code and verifying qubes' security?

[Ph.T]

. if you didn't like that answer, 

you will will probably get a kick out of this:

http://amerdreamduh.blogspot.com/2014/03/privacy-not-purpose-of-qubes.html

On Wed, Apr 16, 2014 at 2:33 PM, Deep Coder <deep...@safe-mail.net> wrote:

Yes but you haven't asnwered my question. What about the kernel code? What about inspecting the code and verifying qubes' security?

--
You received this message because you are subscribed to the Google Groups "qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users...@googlegroups.com.
To post to this group, send email to qubes...@googlegroups.com.
Visit this group at http://groups.google.com/group/qubes-users.
For more options, visit https://groups.google.com/d/optout.

--
Americium Dream Documents
"(real opportunity starts with real documentation)

[cprise]

On 04/16/14 17:33, Deep Coder wrote:

> Yes but you haven't asnwered my question. What about the kernel code? What about inspecting the code and verifying qubes' security?
>

Given Qubes' architecture, it becomes a question of whether the dom0 OS
contains any active /malware/ (and not even the kind of malware that
would poke holes in traditional Linux security). We all have a certain
degree of trust that Linux doesn't have that problem (some might say its
'hope' instead of 'trust'). WRT Linux /vulnerabilities/, Qubes is
designed so those scarcely ever become a threat.

So the focus for hard core inspection/verification falls onto Xen and
certain Qubes-specific components.

Qubes 3 will shift the question of privileged OS trust even further away
from ITL, because they can say 'pick the one you trust the most'.

[01783'1943278'1094328'0194328]

Great idea to use the most stable robust kernel with less LoC as possible and additional with some implemented smart security concepts to harden dom0.

yes: MINIX 3 - had as less code as possible
yes: MINIX 3 - is understandable (education not Security by Obscurity is the purpose)
yes: MINIX 3 - has a high-security minded design
yes: MINIX 3 - the high-security minded design can be enhanced without limitations due to the BSD licence (just do it)
yes: MINIX 3 - is stable, the last 30 years there where no kernel updates. The coding is minimal and clean.
yes: MINIX 3 - is the perfect choice for embedded systems or harden systems, with the security focus in mind


but: MINIX 3 - user-interface don't exists
but: MINIX 3 - security features can be enhanced by
- RoT Root of Trust Hardware Security like the OpenTitan Chip
- RCB remote controlled browsing, like Puffin (to keep away all this web stuff during the random browsing via the Internet) and still have the better performance and fun via Flash & Co (top usability without any limitation)
but: made it's historical design decisions without MINIX 3 - which is quite new
but: to introduce MINIX 3 - will be a lot of extra work

So like always in the cybersecurity community, instead to find endless argument for and against some new deep tech, the best is to start a cybersecurity challenge, which will give the answer.

Team Minix 3 versus Team QubesOS classic

possible outcomes

i)  dom0 Minix wins against QubesOS
ii) dom0 QubesOS wins against Minix
iii) both are equal to protect the user and his/her data E2E

But sure, there must be some clear criteria, like:
- initial security level
- security level with live attacks and live updates
- security level in special disciplines (which services are on and off?)
- usability
- understandable
- enhanceable (design time?)
- customizable (switch off unused services)
- performance (run time)
- real-time performance (VoIP, UC, Screensharing like Puffin)

After some events, probably the user can choose which dom0 they trust more MINIX or Linux?

Looks like a lot of fun to find this out...

[109378409217834091782340928409]

If even sudo has vulnerabilities build in, than the former very good name of Linux due to it's reputation in the cybersecurity get questionable...

https://www.scmagazineuk.com/linux-sudo-bug-allow-hackers-root-access/article/1663022

A smart usage of MINIX is probably quite harder to protect all security goals on a high level.

[kerste...@gmail.com]

Since ALL are running MINIX as a co-host (MINIX allways inside) under ring - 3 and dom0 will run "only" ring 0 - the security or vulnerability of MINIX will dominate the Qubes-OS security ALWAYS.

Under this circumstances there will be no change due to the cybersecurity to run MINIX 3 also as dom0 (and learn more about MINIX 3 ring -3 security features as well).

[1823'04981203948'10293480]

Why not transfer dom0 to a hardened understandable hardwareplatform like the open Beaglebone0 black MINIX3?

https://wiki.minix3.org/doku.php?id=www:download:start

And then use some distributed computing (e.g. a second Beaglebone1 black MINIX3 to run the network drivers), to connect this core (dom0) with some GUI clients (PC) , which are running on different hardware-devices connected only via screensharing like the Remote Control Browser Puffin?

With the broken media protocol the Dom0 on the Beaglebone0 becames "untouchable"... even if many things went wrong...