Qubes sel4 and minix

[Lee Malek]

Does the ITL team plan on moving qubes away from using linux in the future?

Given all the talk of backdoors within the huge linux kernel, it seems like it would be the holy grail to have sel4 as dom0.

I've posted this on the minix group:

https://groups.google.com/forum/#!topic/minix3/Ve7RE84UduM

Any word on if this is the goal, and how long it would take to do this...

If only I had the money to fund the work needed :-)


-------- Original Message --------
From: WhonixQubes <whoni...@riseup.net>
To: leem...@safe-mail.net
Cc: qubes...@googlegroups.com
Subject: Re: [qubes-users] Qubes and learning linux
Date: Tue, 24 Feb 2015 07:31:13 +0000

> On 2015-02-24 1:48 am, Lee Malek wrote:
> > One more thing. About Gentoo. I would like to learn it, but currently
> > you can't turn Gentoo into a template vm. I WISH I could compile my
> > own Gentoo and have it templatized but it seems like there is more to
> > it?
> >
> > So the key here is I want to learn linux as it relates to qubes.
>
>
> FYI:
>
> @nrgaway is doing some awesome things with making new Linux TemplateVMs
> versions for Qubes lately.
>
> And has been succeeding with Debian, Ubuntu, Whonix.
>
> His repo of work can be found here: https://github.com/nrgaway
>
> The "qubes-builder" seems to be the primary Qubes dev component for
> building TemplateVMs.
>
> And there has been exploration of porting Whonix to Hardened Gentoo as a
> potential future prospect down the road.
>
> So, down the road, we may eventually see a Qubes + Whonix Gentoo
> Hardened template emerge.
>
> Maybe faster if someone achieves a Qubes Gentoo template in the
> mean-time.
>
> WhonixQubes

[cprise]

On 02/24/15 20:39, Lee Malek wrote:

Does the ITL team plan on moving qubes away from using linux in the future?

Given all the talk of backdoors within the huge linux kernel, it seems like it would be the holy grail to have sel4 as dom0.

I've posted this on the minix group:

https://groups.google.com/forum/#!topic/minix3/Ve7RE84UduM

Any word on if this is the goal, and how long it would take to do this...

If only I had the money to fund the work needed :-)

I don't know how much has changed since 2010, but you should read this:

http://theinvisiblethings.blogspot.com/2010/05/on-formally-verified-microkernels-and.html

Skepticism about formal verification aside... Since ITL is trying for a robust desktop environment with good hardware support, I'd guess ITL won't be doing anything with sel4 or minix anytime soon; They are more concerned with supporting Windows (which makes sense, to an extent).

As for "all the talk" about Linux, you do realize that a big expose was recently done on insidious attacks the NSA was making against Windows and OSX systems? Zero-days are involved, which for all we know could be sequestered by MS and Apple for the NSA's use. Now the FBI says they want in on this kind of action.

[Lee Malek]

Yes, I read that post. My main concern is getting the code base of dom0 as low as possible, making it easy to review.

[WhonixQubes]

On 2015-02-25 1:39 am, Lee Malek wrote:
> Does the ITL team plan on moving qubes away from using linux in the
> future?
>
> Given all the talk of backdoors within the huge linux kernel, it seems
> like it would be the holy grail to have sel4 as dom0.
>
> I've posted this on the minix group:
>
> https://groups.google.com/forum/#!topic/minix3/Ve7RE84UduM
>
> Any word on if this is the goal, and how long it would take to do
> this...
>
> If only I had the money to fund the work needed :-)

Lee,

This issue is actually a big concern of mine too.

Meaningful privacy/anonymity requires security.

Meaningful security requires integrity verification.

With tens to hundreds of millions of lines of code in Linux distros,
written and subverted by whomever, it is ripe for backdoor exploitation.

Xen helps cut that down to less than 150k lines of code, so ~1% of
Linux, but Linux is still trusted in Dom0, etc. And while Xen is much
much simpler and has better architecture than Linux, even running 150k
LOC of other people's trusted code is not ideal.

Microkernels like seL4 and Minix get the LOC count down under 10k lines
of code.

Even though the Xen and IOMMU/VT-d enforced domain architecture is about
paring down the TCB well beyond traditional monolithic systems, still
trusting big bloated Linux in Dom0 is an open invitation for immoral
masters of the universe to get control of Linux-based maintainers and
get their code put into all kinds of systems, like Qubes Dom0.

I see the LOC count and broad/loose organization of maintainers as a
generalized attack vector to backdooring bloated systems like Linux.
It's just way too much to credibly audit and should not be used for
strong security/privacy/anonymity.

I think security architectures like Qubes need microkernels in their
system-wide trusted domains. If not default, at least as an alternative.

Interestingly, in researching microkernels in recent weeks, I found this
blurb on the seL4 website...

https://sel4.systems/GettingStarted

"Qubes is an open source operating system designed to provide strong
security for desktop computing using virtualisation to provide
isolation. Qubes is based on Xen. seL4 is a much better fit for Qubes.
The project is to port Qubes to seL4 (or develop an alternative
Qubes-like system for seL4)."

That may be for focusing on replacing Xen as a hypervisor as well as
Linux in Dom0. I wish I knew more about what's going on with this!

But I've read that seL4 does have full virtualization capabilities (not
paravirtualization) and does not currently have 64-bit support, but some
work has been done on that.

Overall, Linux is a fat pig that I think could be easily owned on the
code level by those using ample money/power/force. And then that code
gets into Qubes Dom0.

It's just a perpetual problem that can never be resolved with Linux.

Microkernel super low LOC footprint allows for confidence in OS code
auditing.

Yes, microkernels does not solve the evil hardware/firmware problem as
addressed in ITL blogs. So I'm not saying it is a total answer to system
security.

But millions of lines of code written/influenced by *whoever* inside our
privileged Dom0 is a big practical security problem that needs to be
weeded out in order to achieve an *meaningfully* secure system, rather
than just a *reasonably* secure system.

OSes with MILLIONS of LOC is okay for properly isolated untrusted AppVM
use, but I hate the thought of all that code running in my TCB.

Would love to see or help a project get started that achieves this with
microkernels!


WhonixQubes

[Lee Malek]

So glad to have backup on this. :-)

The problem is even worst still. Because I imagine some very smart people (NSA) have a system for creating backdoors but making them APPEAR like "bugs"... so even if they WERE found, no one gets blamed...

Not only that, but compilers are also an issue.

Just read this:

http://www.dwheeler.com/trusting-trust/

-------- Original Message --------
From: WhonixQubes <whoni...@riseup.net>
To: leem...@safe-mail.net

Cc: qubes...@googlegroups.com
Subject: Re: [qubes-users] Qubes sel4 and minix

[WhonixQubes]

On 2015-03-04 8:56 pm, Lee Malek wrote:
> So glad to have backup on this. :-)
>
> The problem is even worst still. Because I imagine some very smart
> people (NSA) have a system for creating backdoors but making them
> APPEAR like "bugs"... so even if they WERE found, no one gets
> blamed...
>
> Not only that, but compilers are also an issue.
>
> Just read this:
>
> http://www.dwheeler.com/trusting-trust/

Absolutely...

There are people probably solely dedicated to crafting covert code
exploits/error strategies and implementations. If need be, they are told
they are simply "researching" them to "prevent" them in key critical
systems. Then taken and weaponized.

Yes, compiler trust is another issue too.

However, I see getting an OS footprint down to microkernel size is the
big general key that then allows for thorough verification to be
credibly pursued.

I don't think its even credibly attemptable on an ever-changing mass
codebase anymore, like Linux, etc.

Microkernels allow for a codebase size that can be managed for pursuing
a credible security verification.

Like seL4 with formal proofs.

And then open hardware/firmware enters the picture.

But Hypervisor and Dom0 codebase are probably, on some level, key
targets for covert code exploit.

At least, I'd target them, if I were an evil government, hacker,
cybercriminal, etc with incentives to do so.


WhonixQubes

[Jason Marinaro]

Have you checked out RancherOS?:
http://rancher.com/rancher-os/

[Lee Malek]

Has Joanna or Marek ever commented on this issue?

-------- Original Message --------
From: WhonixQubes <whoni...@riseup.net>
To: leem...@safe-mail.net
Cc: qubes...@googlegroups.com

Subject: Re: [qubes-users] Qubes sel4 and minix

[cprise]

AFAIK, the basic Xen hypervisor is about 60K LOC. When sel4 gets to a
comparable ability with hardware management and 64bit... then re-do the
comparison.

In reference to your general thrust, a primary question is how trivially
can a dom0 OS interfere with Xen? By that I mean, what kind of
'innocent' obscure little changes (if any) in the dom0 OS could cause
security problems for the hypervisor?

Something tells me the number of potential avenues for attack of that
sort may be very small or zero, since the normal administration of Linux
systems has nothing to do with Xen (and so attacks on the hypervisor
would have to be blatant). Maybe Joanna or Marek could chime in and tell
if my hunch is wrong...

The bigger risk to dom0 code is not signing the repo metadata,
especially since the latest NSA 'Equation Group' revelations show that
they will deny certain updates or roll them back in order to exploit
former 0days. So now a powerful example has been set for a 'theoretical'
attack which some of us argued about months ago, now apparently a viable
avenue for others to use as well.

BTW, I must disagree with the sentiment that many and widespread
developers are a liability. It sounds specious to me, like Security By
Obscurity. ITL would/will have Qubes development decentralized to an
extent that could make Linux appear locked-down by comparison, so there
is a basic difference of culture there.

I think limiting the amount of code and projects that are installed into
dom0 makes the most sense.

[Alex Dubois]

I believe ITL has taken very good architecture decision in abstracting the virtualisation it will run on with QubesOS 3 which may allow a greater choice for the OS interfacing with the end user.

I am drifting a bit off topic but having a qubes-dom0-update that only update the packages in Qubes TBC would be a huge improvement (particularly if any other package can contain code that main attempt to attack my storage firmware). This is right now what I believe would be the best return on investment for the Qubes R2 community.

We could also organise a collective review with different cells of peer reviewer to look into the Qubes ITL produced TBC then on the boot process code...

Alex

>
> --
> 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.
> To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/54F7F02B.6060903%40gmail.com.
> For more options, visit https://groups.google.com/d/optout.

[cprise]

On 03/05/15 03:52, Alex Dubois wrote:
>
> I believe ITL has taken very good architecture decision in abstracting the virtualisation it will run on with QubesOS 3 which may allow a greater choice for the OS interfacing with the end user.

Since it looks like the sel4 people have started a Qubes project... (or
are they just suggesting that?)

>
> I am drifting a bit off topic but having a qubes-dom0-update that only update the packages in Qubes TBC would be a huge improvement (particularly if any other package can contain code that main attempt to attack my storage firmware). This is right now what I believe would be the best return on investment for the Qubes R2 community.

That's an interesting idea. However, I've noticed a number of dom0 bugs
fixed outside the TBC since R2 was released. Maybe that kind of conflict
will be reduced in R3.

[WhonixQubes]

On 2015-03-05 12:57 am, Lee Malek wrote:
> Has Joanna or Marek ever commented on this issue?

I'm just aware of this blog post and the arch spec doc...

http://blog.invisiblethings.org/2010/05/03/on-formally-verified-microkernels-and.html

http://files.qubes-os.org/files/doc/arch-spec-0.3.pdf

Which I think are focused on considerations for the hypervisor or bare
metal level.


The consideration of what OS to run in Dom0 of Xen is a
different/important issue for current Qubes hypervisor architecture, I
think.

Millions of ever-changing Linux LOC in Dom0 is not a trustworthy
codebase for Dom0, IMHO.


WhonixQubes

[WhonixQubes]

On 2015-03-05 5:56 am, cprise wrote:
> AFAIK, the basic Xen hypervisor is about 60K LOC. When sel4 gets to a
> comparable ability with hardware management and 64bit... then re-do
> the comparison.

I took the 150k number from this page...

http://wiki.xen.org/wiki/Xen_Project_Software_Overview

"The Xen Project Hypervisor is an exceptionally lean (<150,000 lines of
code) software layer"

But maybe a bit less if ITL only implements part of Xen for Qubes.

But I receive your point that microkernels do not have all the same
hardware and architecture support and that is part of the difference in
10k vs. 150k LOC count.

> In reference to your general thrust, a primary question is how
> trivially can a dom0 OS interfere with Xen? By that I mean, what kind
> of 'innocent' obscure little changes (if any) in the dom0 OS could
> cause security problems for the hypervisor?

Further detailed investigations into technical vectors of attack is a
good thing. Just not my specialty though.

> Something tells me the number of potential avenues for attack of that
> sort may be very small or zero, since the normal administration of
> Linux systems has nothing to do with Xen (and so attacks on the
> hypervisor would have to be blatant). Maybe Joanna or Marek could
> chime in and tell if my hunch is wrong...

I receive your point. However, it IS the blatantly pursued -- but
potentially covertly coded -- exploits that I fear with putting millions
of LOC into Xen/Qubes Dom0.

There was a debate about this issue we had recently in the Qubes +
Whonix code, where I was able to come up with a method for covertly
hiding dual-purposed innocent looking code across two distinct software
packages that collude together. I'm no expert at such dark arts, but if
I can do it covertly with a couple hours of thought, then true experts
can certainly pull it off, especially with privileged maintainer
positions that under their direct control.

> The bigger risk to dom0 code is not signing the repo metadata,
> especially since the latest NSA 'Equation Group' revelations show that
> they will deny certain updates or roll them back in order to exploit
> former 0days. So now a powerful example has been set for a
> 'theoretical' attack which some of us argued about months ago, now
> apparently a viable avenue for others to use as well.

It's a bigger risk right now, because we use Xen and Linux in our TCB.

Every few days a new package update becomes a new potential attack on
Dom0. This straight up sucks for security.

I'd be happier with a super small slow moving TCB codebase that rarely
ever changes over years of time.

> BTW, I must disagree with the sentiment that many and widespread
> developers are a liability. It sounds specious to me, like Security By
> Obscurity. ITL would/will have Qubes development decentralized to an
> extent that could make Linux appear locked-down by comparison, so
> there is a basic difference of culture there.

This point is not a technological vulnerability point. It is a human
organizational vulnerability point. Especially with recent revelations
of covertly implanting people inside organizations to alter systems and
products.

With a bloated monolithic kernel, if one wants to compromise Linux, one
doesn't have to get Linus Torvaldds to do the dirty work. In fact, that
would be a dumb approach to try to corrupt him, due to his public
profile. Rather, it would be smarter to target or insert somebody who is
a package maintainer of code that has privileged rights in the system.
Could be a Linux kernel component. Could be a Fedora package. The
weakest links in the human organizational chain becomes a juicy exploit
vector to those who would want to corrupt them.

I don't see it as a stretch at all, since this form of human corruption
and infiltration has regularly gone on forever in humanity. And
governments, spies, militaries, cartels, organized criminals, etc around
the world are experts at getting their hands dirty in these ways to
takeover and get what they want. They do far more heinous things as part
of their daily business.

When there are hundreds to thousands of human corruptible entry points
into owning Linux OS distros, combined with sophisticated covert coding
techniques, why wouldn't several people around the globe be looking to
own this? Is rooting/backdooring all of Linux, Fedora, Xen, or Qubes not
a worthwhile target?

It's not an issue of technical security by obscurity. It is a real-world
practical reality of there being a high amount of human-level attack
surface.

It is a different world than our technical bits and bytes. And might be
a socially ugly reality for people to sit back and think about as being
a regular part of this world. But its a layer of human reality that
underlies and controls the production of our technical systems. And can
directly subvert and exploit us.

That's why I think tens to hundreds of MILLIONS of LOC, constantly
changing, expanded, and modified by god knows who is an organizational
mess that is ripe for human-level exploitation.

If I were an evil person with resources, I could almost guarantee you
that I could exploit Qubes Dom0 this way through Linux/Fedora code.

> I think limiting the amount of code and projects that are installed
> into dom0 makes the most sense.

Yes, this would be a great improvement.

And the further it can be stripped down to bare bones, I think the
better it is for security posture.

Why not run a microkernel inside Xen Dom0 or other non-user system
domains?


WhonixQubes

[WhonixQubes]

On 2015-03-05 12:55 am, Jason Marinaro wrote:
> Have you checked out RancherOS?:
> http://rancher.com/rancher-os/

Jason,

The homepage of the RancherOS site indicates that Linux is used on the
bare metal hypervisor level, similar to KVM architecture, I'd guess.

Something that Xen-based Qubes purposefully seeks to avoid.

And why we are focusing away from Linux towards microkernels here.

Linux is a MONSTER codebase that nobody can credibly audit for security
anymore.


WhonixQubes

[cle...@gmail.com]

What about MirageOS? http://openmirage.org/ Written in OCaml and runs on Xen.

[WhonixQubes]

On 2015-03-05 6:05 pm, cle...@gmail.com wrote:
> What about MirageOS? http://openmirage.org/ Written in OCaml and runs
> on Xen.

That is really cool! :)

I wasn't aware of these unikernel systems.

In principle, yes, this could be a potential answer, or at least a
fundamental improvement.

I'd wonder how big the toolchain is and how big the resulting unikernels
typically have to be, in comparison to other microkernels.

But, in principle, I like it. Certainly better than the full-blown Linux
monster.

It also gives me some really cool new ideas for a Qubes app I've started
developing.

I will have to research and play with these unikernel systems more.

Thanks!


WhonixQubes

[cprise]

On 03/05/15 12:04, WhonixQubes wrote:
> On 2015-03-05 5:56 am, cprise wrote:
>> AFAIK, the basic Xen hypervisor is about 60K LOC. When sel4 gets to a
>> comparable ability with hardware management and 64bit... then re-do
>> the comparison.
>
> I took the 150k number from this page...
>
> http://wiki.xen.org/wiki/Xen_Project_Software_Overview
>
> "The Xen Project Hypervisor is an exceptionally lean (<150,000 lines of
> code) software layer"
>
> But maybe a bit less if ITL only implements part of Xen for Qubes.
>
> But I receive your point that microkernels do not have all the same
> hardware and architecture support and that is part of the difference in
> 10k vs. 150k LOC count.
>

I took the 60K number from a Blackhat presentation discussing hypervisor
'ring 0' code.



> ...

>> The bigger risk to dom0 code is not signing the repo metadata,
>> especially since the latest NSA 'Equation Group' revelations show that
>> they will deny certain updates or roll them back in order to exploit
>> former 0days. So now a powerful example has been set for a
>> 'theoretical' attack which some of us argued about months ago, now
>> apparently a viable avenue for others to use as well.
>
> It's a bigger risk right now, because we use Xen and Linux in our TCB.
>
> Every few days a new package update becomes a new potential attack on
> Dom0. This straight up sucks for security.
>
> I'd be happier with a super small slow moving TCB codebase that rarely
> ever changes over years of time.

Have you considered not doing full dom0 updates? The QSBs like the one
Joanna just posted are a definitive guide for updating only the TCB bits.

Perhaps an alternate yum configuration that only updates components
mentioned in the QSBs is in the cards..?


> ...

> It's not an issue of technical security by obscurity. It is a real-world
> practical reality of there being a high amount of human-level attack
> surface.
>

Re-defining participants/contributors as 'human-level attack surface'
sounds like it could lead to alienation and other major problems for a
software project (even a proprietary one, but especially for OSS).

The desktop environment is an example of the kind of large, complex
codebase that is very much needed by Qubes. Its a bigger concern than
the kernel, IMO, because it is not shrouded in security culture although
_controlling_ _what_ _a_ _person_ _sees_ can profoundly affect security.
How does sel4 solve this? It doesn't!

Qubes cannot be a desktop OS without a good DE, so where does that leave
us? Like users of other distros, we trust certain upstream projects not
to do malicious or foolish things; Maybe over time we help them
strengthen their security culture. I am not sure what else can be done,
but I do know that a certain level of trust in community is required to
get anywhere; Otherwise it is the secretive militarist organizations
that win.

[Alex Dubois]

I don't think it has to be OCaml, however network stack and DNS has been recoded in OCaml... Almost a given for firewallVM :-) you get on top memory footprint and start-up time...

But Dom0 needs video driver and quite a lot more...

>
> --
> 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.

> To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/f36b0e68-8af9-4d5b-83ea-890001a32b13%40googlegroups.com.

[WhonixQubes]

Right. Regarding Dom0 updates, I personally do something similar --
somewhere in-between these two -- right now.

>> ...
>
>> It's not an issue of technical security by obscurity. It is a
>> real-world
>> practical reality of there being a high amount of human-level attack
>> surface.
>>
>
> Re-defining participants/contributors as 'human-level attack surface'
> sounds like it could lead to alienation and other major problems for a
> software project (even a proprietary one, but especially for OSS).
>
> The desktop environment is an example of the kind of large, complex
> codebase that is very much needed by Qubes. Its a bigger concern than
> the kernel, IMO, because it is not shrouded in security culture
> although _controlling_ _what_ _a_ _person_ _sees_ can profoundly
> affect security. How does sel4 solve this? It doesn't!
>
> Qubes cannot be a desktop OS without a good DE, so where does that
> leave us? Like users of other distros, we trust certain upstream
> projects not to do malicious or foolish things; Maybe over time we
> help them strengthen their security culture. I am not sure what else
> can be done, but I do know that a certain level of trust in community
> is required to get anywhere; Otherwise it is the secretive militarist
> organizations that win.

I do agree with the cultural sentiment of this. :)

But also realize that the "bad guys" will just laugh at such beliefs of
upstream trust and look for inroads to leverage this to exploit us all.

A sad reality of the distributed trust-based world we inhabit.

Strong trust-less / independently verifiable technology is ultimately a
better solution for us to develop instead.



Here's one potential option I'm thinking of in regards to Qubes...


Hypervisor: Xen
|
|---> Dom0: Microkernel or Unikernel
|
|---> GUI Domain: GUI on top of Microkernel or Unikernel
|
|---> AppVMs: Linux, BSD, Windows, Mac, Whatever


It'd be nice if other system-level domains, like network domain, storage
domain, etc had the option of a microkernel or unikernel.

Keep Linux as the default Dom0/GUI/system domain kernel, if most people
want that.

I'd just like to see an alternative option, even if it doesn't come from
ITL.

Like Minix can already run X as a desktop GUI system. Not sure about DE
or GUI support of other microkernel or unikernel systems.

And keep Linux, BSD, Windows, Mac, Whatever in the user AppVMs.


Why does Dom0 and/or GUI domains need Linux to operate Qubes?

Can't this microkernel/unikernel alternative be done for the Dom0 and/or
GUI domains?


Note: I'm not a CS grad or systems developer, just a self-taught
applications developer and security enthusiast, so I might be missing
something basic here.


WhonixQubes

[Franz]

We have two conflicting needs:

on one hand the need to use the huge effort already done with Linux, mainly in terms of hardware management. There is no point in having a super secure system that does not run on common new laptops;

on the other hand the need to control the trend towards increasing Linux bloating. Even Linus Torwalds advised against it. So this is not only a Qubes problem. It is a community long term huge problem and needs a proper community solution. But I do not feel that the Qubes group has the resources to face it.

But perhaps, with enough time,  the broader OSS community will be able to provide more modular manageable solutions, more in line with Qubes philosophy of separating working units.

 

Here's one potential option I'm thinking of in regards to Qubes...


Hypervisor: Xen
             |
             |---> Dom0: Microkernel or Unikernel
             |
             |---> GUI Domain: GUI on top of Microkernel or Unikernel
             |
             |---> AppVMs: Linux, BSD, Windows, Mac, Whatever


It'd be nice if other system-level domains, like network domain, storage domain, etc had the option of a microkernel or unikernel.

Keep Linux as the default Dom0/GUI/system domain kernel, if most people want that.

I'd just like to see an alternative option, even if it doesn't come from ITL.

Like Minix can already run X as a desktop GUI system. Not sure about DE or GUI support of other microkernel or unikernel systems.

And keep Linux, BSD, Windows, Mac, Whatever in the user AppVMs.


Why does Dom0 and/or GUI domains need Linux to operate Qubes?

Can't this microkernel/unikernel alternative be done for the Dom0 and/or GUI domains?


Note: I'm not a CS grad or systems developer, just a self-taught applications developer and security enthusiast, so I might be missing something basic here.


WhonixQubes

--
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+unsubscribe@googlegroups.com.

To post to this group, send email to qubes...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/d03aebb2568e3174cefcc82d92d054a1%40riseup.net.

[WhonixQubes]

On 2015-03-05 10:02 pm, Franz wrote:
> We have two conflicting needs:
> on one hand the need to use the huge effort already done with Linux,
> mainly
> in terms of hardware management. There is no point in having a super
> secure
> system that does not run on common new laptops;
> on the other hand the need to control the trend towards increasing
> Linux
> bloating. Even Linus Torwalds advised against it. So this is not only a
> Qubes problem. It is a community long term huge problem and needs a
> proper
> community solution. But I do not feel that the Qubes group has the
> resources to face it.
>
> But perhaps, with enough time, the broader OSS community will be able
> to
> provide more modular manageable solutions, more in line with Qubes
> philosophy of separating working units.

Regarding that conflicting need:

Personally, I'd rather start over with using one product line of open
verifiable hardware and ultra minimal bare bones TCB.

I'd rather primarily use secure basic computers than ultra high speed,
feature-rich computers.

But we will always have the proprietary and bloated systems offering the
latest and greatest in speed and features, due to mass market demand.

We just need one alternative complete hardware/firmware/software stack
for high security focused people/organizations.

Just one open minimal secure computing stack. :)


WhonixQubes

[Franz]

Regarding  a simple matter of personal preference I agree with you. A minimal but safe computer. But  your and mine preferences are of little importance. What matters is a project that may work and make sense on a broader audience and here we have mainly two ways:

Selling hardware (laptop) and software jointly. Following this way it may be easier to make what you suggest, because you have to get it working only on single hardware specifications. But even in this case, Apple that follows this model has to give support to a huge multitude of peripherals, printers, scanners, etc.. We have this stuff and need to use it.

Providing only the software as current Qubes project is. But you see on this mailing list that many people has problems running Qubes on ordinary laptops. I only buy Lenovo laptops to have less problems with that. And this is with Linux and its huge support base. What will happen using some experimental minimal OS? I am sure it will be much harder. Or not?

WhonixQubes

[WhonixQubes]

I think there are a number of people like us, who would want to have a
second alternative ultra lean security system side-by-side with their
typical over-bloated mass-market systems.

For this ultra high security computer, I'm willing to toss out a whole
bunch of peripherals to minify the hardware support issue.

No printers. No scanners. No webcams. No extra ports. No bells and
whistles. Just the truly bare essentials for a semi-modern networked
terminal.

But use the isolated Qubes VM desktop model where users can interface
with their Linux, BSD, Windows, Mac, etc desktops in VMs.

Of course, community people can develop and offer support for hardware
extras later on if they so choose. But, for security critical use, I
think many people of the right target audience would be happy even with
just the basics.

The key is that people would likely use such a security focused system
in-tandem with or in-addition to their other other traditional systems.

Like as a separate higher trust computing domain. Some, like me, may use
it more regularly than others, but I could imagine a large enough number
of people who would at least want to have a such a bulletproof security
system for trustworthy computing when they feel they need it.

Any "important person", or person who associates enough importance with
their personal or professional information, would probably want such a
secure secondary system available to them in their life.

If based on third party hardware, like Lenovo or Purism, then this would
add convenience for dual-booting.

Buying one new set of specific model components is probably a small cost
for at least many thousands of people around the globe who would
need/want the absolute highest in security.

Qubes HCL is probably confusing to people, compared to just simply
saying...

Buy X hardware. Install Y software. Possess strongest PC security in the
world for your own needs. Done and Done.

Just look at the crowdfunding success of Purism or Novena and the
interest in Qubes, Tor, Tails, Whonix, etc.

A decent subset of all these people would likely be interested in having
a system that can offer much higher assurances of bulletproof security.

And maybe it isn't that far away? Maybe with a few strategic open
software and driver ports, it could be achieved sooner than later?

With a bit more research in hand, I'd be happy to do a fundraising
campaign and manage a project to completion for providing such a strong
minified ultra security platform.

Or maybe we just need to launch a volunteer-based free software project
to do some research and write a handful of software and driver ports.


I'm game! :)


WhonixQubes

[Franz]

This depends on the kind of work you do on this computer.  In my case my safer domains involve printing and manually signing documents. Without a printer I'll lack an essential part of what I need to get my job done. Which is the purpose of having a super secure dom0 if I am unable to work with it? And the same I'll have to use the bloated Linux for my applVM. For me this is too extreme. The price to pay is too high.

WhonixQubes

[Axon]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

To expand on this point:

Your use-case for a super-secure minimal computer really does matter.
For example, financial cybercrime is currently a huge risk for a lot
of individuals and businesses, where legal protections are either weak
(e.g., banking/credit card fraud protection for businesses vs.
consumers in the US) or nonexistent (e.g., brokerage fraud in the US),
so it makes sense to care about computer security if you need to do
banking, stock trading, etc. online from own computer. But it doesn't
really do you any good to have an invincible endpoint computer when
you're then forced to use one of the major (bloated, buggy) supported
browsers to connect via (exploitable/CA-reliant) SSL/TLS to your
financial institution's
(minimum-security-to-satisfy-regulations/cut-corners-for-profits/controlled-by-some-third-party)
servers.

It's still beneficial, since at least you eliminate yourself/your
machine as a point of failure (e.g., spearphishing), but the benefit
of further hardening our endpoint, when it's already more secure than
99% of everything else, quickly drops off when we still have to rely
on the rest of the (insecure) world for most of the things we care about.


Imagine the supreme irony of the following scenario:

You're sitting at your computer, scrutinizing the source code of some
new formally verified microkernel in order to evaluate the suitability
of its use as dom0, when you suddenly choke to death on your glass of
water because hackers gained access to your city's critical
infrastructure, which runs on Windows XP.


I'm not saying that we shouldn't strive to secure ourselves to the
maximal extent possible. I agree that we should. I just think it's
worth taking a step back to gain some perspective on the big picture,
if only to laugh (and cry).


-----BEGIN PGP SIGNATURE-----

iQIcBAEBCgAGBQJU+TjuAAoJEJh4Btx1RPV8M+sP/2lU/5hmZ58ltIxWfbv/YGw6
m9NGc0dqrxKeyQDgVVlStpHZkTkgBPFLnHLh799OCW25L/bjKWerNTNY2DK1KlBR
kB9hOilmmYP+hFVFpXxI/h/zPxIgYhgreyEQxtQ6oNRhEoOkamM5on+ZOCRhwcN5
r4K2FULeFNfQRIA92hkxFKQmSEvcN7NNTxCkRhqh3O+xvhe5RfLRr31hcXDvPdAZ
0/pt5ZHUGuihQutgvY3QKW+aXbShyRP3ZJPsYtpliGW85snPfMkSSaPG9dYLqhtv
ZTAk/AeAOSq7P9SFxpn9lfElVlfzNAIo6e3CLBI1e1TnUd9QVmr0t3v4wwA7NPFp
rKuOodbSq7NWfen/Ogi4ikAX4VtQeuI02yivj/Rco+1y/S9VF5SjXUud6SdoCizc
Tcma+R3Gr2AFORUx1U2FhDOLUNl40MmS0i+V6RsnqW0xR4UOr9KmIEtZnmAhm0YZ
GI0ofeinWbQByCg9yDs43fFDt/AntffvhT5dFc1OcWamgD0HcUqDFwOV7UsBnomW
VmWOkZ7QPaMGPnv7HoAGbfgoMBPRh8SVHMzRFl7Zzjf06WOhEsrSGgz4EG8/i+pB
Ke+Gsm/e1x615pNvolnNlmHvp519uDNsTWwcHN/xpm0PoUaHvcnNdqmSsoaMLM+q
LgTdq7btXfNW23nDk17u
=GIx4
-----END PGP SIGNATURE-----

[Franz]

Yes cprise, there is a general law, I do not recall the exact name, but let us call it of decreasing interest or utility. For example you are starving, getting some food is critical for you, but after eating 3 plates your interest decreases. The same for money, the more you get, less useful are further increases, That is why Bill Gates, Warren Buffet, Soros etc donate important parts of their fortune. The same for computer security. If you are using a Windows computer full of trojans and viruses, even the small effort or reinstalling it and using an antivirus or moving to Linux may give huge improvements, but if you are already using Qubes with all the involved commitment, even extraordinary efforts will give you only very small additional improvements. Well, we are lucky to have this law because it gives us some balance, some moderation.

[WhonixQubes]

I take your points, Franz and Axon, very well.

I see the reality of these points being true in a number of contexts.

Basically security interest is relative to use case. Sure, I get that.

And not just use case, but also personal preference. Like humans do all
sorts of things to make themselves feel happy, comfortable, secure, etc.
Whatever people spend their time and money on can fall in line with
similar arguments of broad spectrum utility. Like people who want to
build bomb shelters.

But, there is a specific flip-side that applies here to this unique
attack vector, regarding Linux or bloated codebases in general.

It's not just a matter of adding "more security" to an "already secure"
system.

The issue is whether a system like Qubes IS or IS NOT secure in the
first place -- in the most basic of ways -- with a monster unverifiable
codebase in Dom0 (such as Linux)?

My contention is that a massive codebase like Linux can be fairly easily
subverted and dual-purposed as a Dom0 trojan horse.

Without a Dom0 codebase that is verifiable in size and complexity, who
can credibly claim that their Qubes box is secured?

Give me just 6 figures in cash, take away my morals, and I can guarantee
you that I could root every single Qubes user by using Linux as a trojan
horse.

For a number of people, I think having a clean alternative minimal TCB
codebase is important enough in the world.

For things like personal financial or legal tasks, I agree that even
this use case probably won't be important enough for most people to
care.

But, for people like security/anonymity critical whistleblowers,
activists, journalists, etc around the world it could mean saving their
life.

And there's probably many more people, organizations, and use cases that
would choose to run an ultra minimal TCB codebase if it was made
available.

Even 1 out of 10,000 people needing/wanting such security would still be
A LOT of people.

When the person or use case calls for it, I don't think a bloated --
potentially trojaned -- unverifiable Dom0 makes sense as a risk.

999 out of 1,000 or even 9,999 out of 10,000 may not care, but every 1
out of 10,000 is still hundreds of thousands of people.

Especially since this is the kind of level that various powerful
attackers are known to be actually operating on and attacking these
days.

Wouldn't be that hard for them to do. Wouldn't be surprised if its
already in place right now.


I think the future should exist with an option to verifiably not be
rooted out of the box.


And maybe unikernels would be a way to blend both worlds of having a
non-bloated minimal TCB along with broad Linux hardware support?


WhonixQubes

[Franz]

That would be the best

WhonixQubes

[Alex Dubois]

> On 6 Mar 2015, at 10:40, WhonixQubes <whoni...@riseup.net> wrote:
>
> I take your points, Franz and Axon, very well.
>
> I see the reality of these points being true in a number of contexts.
>
> Basically security interest is relative to use case. Sure, I get that.
>
> And not just use case, but also personal preference. Like humans do all sorts of things to make themselves feel happy, comfortable, secure, etc. Whatever people spend their time and money on can fall in line with similar arguments of broad spectrum utility. Like people who want to build bomb shelters.
>
> But, there is a specific flip-side that applies here to this unique attack vector, regarding Linux or bloated codebases in general.
>
> It's not just a matter of adding "more security" to an "already secure" system.
>
> The issue is whether a system like Qubes IS or IS NOT secure in the first place -- in the most basic of ways -- with a monster unverifiable codebase in Dom0 (such as Linux)?

Also I feel Dom0 is not that exposed to the outside world in a QubesOS environment (assuming you trust Xen and its hardware bindings):
- network drivers attacks are limited to NetVM
- Layer 3 or 4 attacks (IP and the layer above) is exposed in FirewallVM... MirageOS could limit the attack surface
- a ProxyVM (for outbound) or reverse ProxyVM (if you expose services) using a non Linux layer 3/4 stack could limit the impact at that level.

The main risk I see are only:
- Dom0 updates
- existing code in Dom0 (Fedora) hidden that detect Qubes user and "patch" Xen. (Is it this one you are referring to?)
- storage (and possibly other?) firmware attack
- The end user (who is the main external who accesses Dom0)
Or am I missing something?

>
> My contention is that a massive codebase like Linux can be fairly easily subverted and dual-purposed as a Dom0 trojan horse.
>
> Without a Dom0 codebase that is verifiable in size and complexity, who can credibly claim that their Qubes box is secured?
>
> Give me just 6 figures in cash, take away my morals, and I can guarantee you that I could root every single Qubes user by using Linux as a trojan horse.
>
> For a number of people, I think having a clean alternative minimal TCB codebase is important enough in the world.
>
> For things like personal financial or legal tasks, I agree that even this use case probably won't be important enough for most people to care.
>
> But, for people like security/anonymity critical whistleblowers, activists, journalists, etc around the world it could mean saving their life.
>
> And there's probably many more people, organizations, and use cases that would choose to run an ultra minimal TCB codebase if it was made available.
>
> Even 1 out of 10,000 people needing/wanting such security would still be A LOT of people.
>
> When the person or use case calls for it, I don't think a bloated -- potentially trojaned -- unverifiable Dom0 makes sense as a risk.
>
> 999 out of 1,000 or even 9,999 out of 10,000 may not care, but every 1 out of 10,000 is still hundreds of thousands of people.
>
> Especially since this is the kind of level that various powerful attackers are known to be actually operating on and attacking these days.
>
> Wouldn't be that hard for them to do. Wouldn't be surprised if its already in place right now.
>
>
> I think the future should exist with an option to verifiably not be rooted out of the box.
>
>
> And maybe unikernels would be a way to blend both worlds of having a non-bloated minimal TCB along with broad Linux hardware support?
>
>
> WhonixQubes
>

> --
> 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.

> To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/4f2bccc993f4692c00d6d6ed71b77ba8%40riseup.net.

[WhonixQubes]

On 2015-03-06 3:39 pm, Alex Dubois wrote:
> Also I feel Dom0 is not that exposed to the outside world in a QubesOS
> environment (assuming you trust Xen and its hardware bindings):
> - network drivers attacks are limited to NetVM
> - Layer 3 or 4 attacks (IP and the layer above) is exposed in
> FirewallVM... MirageOS could limit the attack surface
> - a ProxyVM (for outbound) or reverse ProxyVM (if you expose services)
> using a non Linux layer 3/4 stack could limit the impact at that
> level.
>
> The main risk I see are only:
> - Dom0 updates
> - existing code in Dom0 (Fedora) hidden that detect Qubes user and
> "patch" Xen. (Is it this one you are referring to?)
> - storage (and possibly other?) firmware attack
> - The end user (who is the main external who accesses Dom0)
> Or am I missing something?

Good vector segmentation thoughts!

These two:

- Dom0 updates
- existing code in Dom0 (Fedora) hidden that detect Qubes user and
"patch" Xen. (Is it this one you are referring to?)

Here's what I'm thinking...

I'm talking about trojaned code in Linux/Fedora (or Xen) but probably
Linux/Fedora that is either installed in Dom0 initially by Qubes or
installed by a Dom0 update, either way.

So I'm not talking about an innocent mistake that creates a
vulnerability. It may look like innocent code, but be put there on
purpose to trojan Dom0.

Not hard to pull off with a massively bloated open source codebase.

Then it has system-wide control, access to networking, the works.

It can do pretty much anything with your machine at this point from the
Dom0 position.

Firmware hacking. FDE weakening. Data exfiltration. Screen/Webcam/Mic
spying. Encrypted traffic shaping. Whatever it pleases.

And of course the motive would probably be to do the active machine
exploitation part very carefully and covertly, not over using machine
resources, etc, maybe even based on sensing targeted triggers.

And if it was found out, then there would be 10,000 other covert ways to
come back through another component of controlling the Linux/Fedora
codebase that aren't yet found out.

For powerful attackers, Linux/Fedora is fertile ground for directly
controlling Qubes Dom0.


Does that make sense and give a good answer to your question?


WhonixQubes

[Axon]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Agreed.

An additional thought:

As Joanna has often pointed out, one of the best things about Qubes is
that it allows us to run unmodified binaries, e.g., regular Firefox,
in an AppVM while still having secure GUI isolation. But in order to
accomplish this, naturally some sacrifices have to be made. There are
other academic and military OSes out there which also take a
security-by-isolation approach but which do *not* allow us to run
unmodified binaries in VMs the way we can in Qubes. I don't think
anyone would deny that if all you need is a set of securely isolated
terminals, then you can lock down the entire system much more tightly
and minimize your code base. It sounds like the use-cases you have in
mind might be more suited to one of these alternative OSes (which,
unfortunately, tend not to be available to the general public).

In other words: If you think of Qubes as allowing you to take a
"normal" digital life and divide it up into securely isolated buckets,
then Qubes has to be able to support the activities which constitute a
"normal" digital life. In your use-cases, the set of activities is
much smaller. It's a small, critical, life-and-death set of
activities. From that perspective, being able to support the big,
bloated set of "normal life" activities is just a liability. (From
that perspective, we don't want to trade any amount of security for
usability.)

Note that none of this is in disagreement with your main point, which
is that the code base of dom0 should be minimized, since there are
tons of packages installed (and constantly updated) in dom0 that we
never even use (nor are we supposed to use them, since we're supposed
to be doing our work in AppVMs), so they're kind of just sitting
there, adding to the attack surface while providing no benefit. (At
least, that's how I understand the situation. I'm welcome to be
corrected if I'm wrong.)

Of course, even if we were to cut away all the unnecessary cruft from
dom0, there are still some things we really do need, and those are
probably the things that would be targeted anyway. (From an attacker's
perspective, I would imagine that slipping a backdoor into a
cryptsetup update would be ideal, for example.)

-----BEGIN PGP SIGNATURE-----

iQIcBAEBCgAGBQJU+ilgAAoJEJh4Btx1RPV8+JQQAJUhTCF5Q3E4Nyl+M57Wr0FI
zzc0fEqNH/ARZGmQf5VbateZUymQ5FiEhcPhNw3qy2SOw8a61mI2Fny8gy38+WQW
LSZLgFwYcC54Bd5drVEx4J/vjZSRAEq//+zDMtuYsQuqQNh8TJrXJtl+R3dd9w+J
OIXnpNsiQxBemVdHV4sll9jlVG2NmyE+27ItnwcZdEO1f042mq4isUI8JXwEMDyH
DBShfEXLeU2XVg97UYlsztLOIaJjiywq1RkFiUC0eDQtN9+pWfafBFgIgWXfu3xS
grLIiUwR5wUBzQQ23k6zIYY7y6Uf50FqO2yDAgqDoAl/1Marqk67b2gFBiaFeU1h
Zt3IxPKE/vc4pbdX4lSLf5cN2Iyk0HcyGaWxM6n0HVOSx5pRQe6CChSkww8fRFph
slfoTyFxmjAyKYdulDnbFXN3Jy5VGt+9KkFY4oZ4CaVCbskjjRo9vnnbYlfJRsan
M97BhydTEIWqIVARqagS1tyjCZvG27eHPbKGG1OaWZeOTNjyDC/pAZdkbAsJWW9S
VNKZJQEsHBq73XkvjTRpd6JLD7y2g4w6Do8D/BekRJgHJIpE1TO2hb8F7CayTdRx
vMdX94NlTyZVZ4tHLEnZ7u4/x/Qju3RdyDPFL0+OGxz12XWXV0Infz1yper6ExbD
NlJpeUoBVionzE5+ldKJ
=5DMf
-----END PGP SIGNATURE-----

[WhonixQubes]

That's a great summary, Axon. :)

I'd just modify the life-and-death part a bit.

Yes, life-and-death scenarios are the quintessential hardcore use case
that demand minimal TCB attack surface.

But, I'm sure there would be demand for people or use cases beyond just
life-and-death scenarios.

Not that you weren't thinking of such additional possibilities, but just
wanted to express that.

And with that in mind, there is some in-between trade-offs for usability
and security, I think.

For example, I absolutely still want the usability of GUIs and graphical
web browsers, etc. So I'd accept a minimal GUI system as extra TCB.

But, I also still want to be able to achieve credible verification of
the TCB.

For me, if that means only using one specific model of computer to have
supported microkernel drivers for, then I'm personally willing to do
that for my secure computer, and then have my normal cutting-edge
bloated TCB computers happily sitting right next to it.

Then I have the option of which ones to use as I please.

So its really just about the principle of having a verifiable TCB, and
it being important due to the kinds of powerful attackers out there now.

While there may be greater costs to realizing that principle today, I
think the future should offer us the choice of a verifiable --
non-backdoored -- TCB and still have usable GUI internet systems.


I think having this option available is within reach.

Just probably need a handful of minds to develop the remaining few gaps.


WhonixQubes

[Alex Dubois]

I agree. Hide most of it via steganography+crypto in any project part of fedora and you just need a way to boot strap it (submit a patch to one of the projects that has code running at some point in Dom0). This is the hard part, but with a couple of zero days in such project can point to a first loader with steganography only hidden code.

First step is for Dom0 and Xen to go minimal and to be compiled from signed source not pulled via signed binary from Redhat (or anybody) as it does not have to be the product of the reviewed signed source (only).

But are we not paranoid? For me signing of what I do is more important than encryption.
I do not mind if some people can see what I have done. I do mind and not accept any compromise if somebody can change what I have said or done (good or bad).

[WhonixQubes]

On 2015-03-07 12:05 am, Alex Dubois wrote:
> I agree. Hide most of it via steganography+crypto in any project part
> of fedora and you just need a way to boot strap it (submit a patch to
> one of the projects that has code running at some point in Dom0). This
> is the hard part, but with a couple of zero days in such project can
> point to a first loader with steganography only hidden code.

And it really helps pave the implementation of this attack vector when
you have the simple ability to corrupt the human decision makers and
maintainers in various parts of these open source projects.

> First step is for Dom0 and Xen to go minimal and to be compiled from
> signed source not pulled via signed binary from Redhat (or anybody) as
> it does not have to be the product of the reviewed signed source
> (only).

Yes. Slipping exploits into binary builds after clean source is
published clearly has to be mitigated against to prevent this attack. So
one must compile from source or at least use a binary complied by a
person/machine/process that they absolutely trust.

> But are we not paranoid? For me signing of what I do is more important
> than encryption.
> I do not mind if some people can see what I have done. I do mind and
> not accept any compromise if somebody can change what I have said or
> done (good or bad).

We are being paranoid. And we are also being entirely logical based on
the reality of such open vulnerabilities that exist.

The only difference is what aspect of our own lives is worth going to
greater effort of safeguarding.

For some people that's...

- Having one's record of speech or action be modified
- Having one's personal data be erased
- Having one's private thoughts or communications publicly exposed
- Having one's intimate home photos & videos publicly exposed
- Having a whistleblower, activist, journalist be eliminated
- Having one's business's intellectual property stolen
- Having their money, identity, accounts, keys, etc stolen
- Having one's country leaders exploited by foreign intelligence
- Having one's inner sense of privacy taken away
- Having one's family members and children be targeted
- Just the principle of human rights, dignity, freedom, etc
- etc
- etc
- etc

It's a very individualized thing as to what is worth meaningfully
safeguarding in a person's life.

It's different and personal for each human being.

Having the available option to choose security in one's life is
important, I think, since there is no one-size-fits-all standard of
security priority.


WhonixQubes

[Axon]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

WhonixQubes wrote:
> On 2015-03-07 12:05 am, Alex Dubois wrote:
>> But are we not paranoid? For me signing of what I do is more
>> important than encryption. I do not mind if some people can see
>> what I have done. I do mind and not accept any compromise if
>> somebody can change what I have said or done (good or bad).
>
>
> We are being paranoid. And we are also being entirely logical based
> on the reality of such open vulnerabilities that exist.
>

"It's not paranoia if they really are out to get you."

;)

-----BEGIN PGP SIGNATURE-----

iQIcBAEBCgAGBQJU+lPRAAoJEJh4Btx1RPV8430P/3BlQ6BusoIC0LAQpf8dz00X
+mEn9c+PWfN/+vkg0xF2fkzvBCIw9qFfH/wdD0Y2/M78bA6PxrSwh1b7VQzyzK6B
HX20hRsZtNh2y1bFntUGVfCedDx9ejNq3bfEMlLb9qKhRaSFgV5pyErHOPr+UN6a
JEkUKywFpico7EIbI4ObOJgcQB2S/fDigWea8ff5Pq4eGRBJnw9B1YxOtYfujL/7
4acQ4vTVDsapYM+bqIVC8lMfZW5WV+Y7Nkc9IWJB+XQe1+Kn0ZNPkIvJQgX4zrZR
vsegyKrWoMrOTtcmfVgbi6kSTBdiqg6V+tdimofiVwSsdcu+KDirON8mK7MBPK3d
EvcbuMFJa+V18/JkEdO5nDyU8WHIU3K3eAcZrkQ7pJVSgwz4kwtzjPYvEfOkOD7E
Hgu/jdU/EcKhFf6fo3kvAWjCctJj7rq0ggPRtbP7FrBioyA6DSxAsTncgqIFkQdI
sXDHnqZfnlzR5kLiuFi//hftRK58yE1+GnYIL73hZZU3e8+PCsZWZPGhoWS6kL12
rlDVAEe97BF9fP6docy5Sh+WFhw3KZ3or6J/3kbkjnrC2Bd5BZ1XDbCHZ7NH+wrE
yZUawgFbi5b0A0F0anOW7bFcit0h+gtn/ZhCnn7sCQIZdzYnq/EoNyc5Oo1Qve0U
alhOP1W9HpFQLx8l9Raw
=65XB
-----END PGP SIGNATURE-----

[WhonixQubes]

On 2015-03-07 1:26 am, Axon wrote:
> WhonixQubes wrote:
>> On 2015-03-07 12:05 am, Alex Dubois wrote:
>>> But are we not paranoid? For me signing of what I do is more
>>> important than encryption. I do not mind if some people can see
>>> what I have done. I do mind and not accept any compromise if
>>> somebody can change what I have said or done (good or bad).
>>
>>
>> We are being paranoid. And we are also being entirely logical based
>> on the reality of such open vulnerabilities that exist.
>>
>
> "It's not paranoia if they really are out to get you."
>
> ;)

Yes, unfortunately a certain percentage of the world is predatory and
domineering towards others, where a growing number of these people are
high tech attackers of good people's private lives. Both on untargeted
and targeted baseis.

And people used to having ultimate authority over the lives of other
humans are often conditioned to believe that they are more important
than the stranger who they infiltrate or harm on the job, and so they
see it as their legitimate right to do so.

Overall, the costs of infiltrating people's lives have gone way down,
with electronic communications, personal computing and the internet. We
are still in an overall global struggle to raise those costs of attack
way back up and safeguard what we cherish of our personal and
professional lives.

Kick the bastards out.


WhonixQubes

[hadrien...@gmail.com]

I did read all the thread and couldn't agree more with WhonixQubes.
he's got my support full strength.

You all forgot 1 point: you assume that governments and militaries around the world have secured systems... well that's not entirely true. No need to look at Iran or North Korea. Just look at Switzerland, or France. French Army was using for it's secured tasks trusted Solaris (same problems as mentioned in this thread) (not to mention MS windows for it's non critical tasks...). some other more obscure french military sub groups were using ubuntu. (Same problem as above). There has been a scandal of the NSA spying on NATO networks.
the day that non US governments will realise that the impeachment doctrine against harden systems plays only in favor of the USA, and that it's a loosing game, it's gonna be a great day.
I challenge anyone to stand against this proposition.

Therefore I safely conclude that the audience is as well non US government operatives. I suggest they consider again my statement that breach induction & hardening impeachment is a loosing game that benefit only to the US military. Those should avoid the arrogance of believing that gov backdoors can only be exploited by govs, and not by criminals.

I am not that off topic; and wpuld we like it or not, governments need security.

You need to know that I am a libertarian; my political opinion just don't interfere with my perceptions of reality...

consider the irony of a military group who would discard the MILS proprietary OR it's suggested, preferring to work with a transparent secured OSS...

[georgew...@gmail.com]

I'm late to the thread, but I wanted to point out a few things that might be of interest to y'all:


First, regarding unikernels:
------------------------

Ms. Rutkowska has discussed moving some critical services (including Dom0) to MirageOS:

https://twitter.com/rootkovska/status/517689609250439169

That could be a big win: reduce the attack surface, cut down on ram requirements, and (because unikernel boot time is a few ms) process more untrusted inputs with disposable VMs. Sadly, it's hard/expensive to use MirageOS for hardware driver domains, since one would need to re-write the drivers in OCaml. That said, MirageOS is not the only unikernel around, and for this Rump Kernels might be a better fit:

Since 2010 or so, NetBSD has been an "anykernel" --its kernel drivers can be run in kernel space, user-space, on a remote computer, on top of Linux, on Xen, etc. Thus, NetBSD can be used as a monolithic kernel, a microkernel, or a unikernel. The core technology that makes that possible is called "rump," which refers to the tiny interfaces needed to use the (unmodified) kernel components.

Since NetBSD already has device driver, file system, network and Dom0 support, it might be a more productive avenue for meeting your concerns around SLOC count and rate-of-change in the kernels of privileged domains.

Through the "Rump-run" project, arbitrary C and Lua applications can be packaged up as tiny unikernel VMs and run on any of the targets rump kernels, including Xen. This could be useful for lightweight disposable service VMs, like the PDF renderer.

On the networking unikernel front, ClickOS from NEC is a unikernel router OS that might have applications for the firewall VM. The VMs are tiny, the documentation is good, the configuration language is sane, and the performance doesn't suck.


Second, regarding trusting trust:
--------------------------------------------
Yes, compilers can be backdoored, and yes, the attack is very clever, but your compilers probably aren't backdoored, and thanks to David Wheeler you can prove it to yourself if you're so inclined:

http://www.dwheeler.com/trusting-trust/

That said, I have witnessed a real-life application of the trusting-trust attack: scaring people into licensing the Green Hills C compiler! True story.


Third, regarding the threat model:
----------------------------------------------
I really liked Alex's analysis of Dom0 exploitation vectors. That there are so few of them (in spite of the millions of SLOC in the kernel) is a testament to Qubes' awe-inspiring architecture. Nothing else comes close.

NSA is afaik the best-funded cyber-actor in existence. Even so, we know from the Snowden leaks that even NSA is resource constrained, and they need to be careful to pick cost-effective targets (LinkedIn, Gemalto, Yahoo) --targets that yield tens of millions of users. Qubes is niche. Xen isn't niche --but it's a small and shrinking mature codebase that gets a lot of review, so it's a hard target (as we saw when NSA (perhaps inadvertently) backdoored the Xen security extensions and Joanna's team fixed it). And while the upstream Linux kernel is certainly a prominent target, (as Alex pointed out) the only points of ingress for malicious code into Dom0 that would be effective against a Qubes system would have to be targeted at Qubes. Since exploits that could target Qubes (e.g. Dom0 software updates that patch Xen) strain the limits of non-attribution, widespread deployment of such an attack vector would be incompatible with NSA TTPs.


A more cost effective attack against Qubes for NSA would be to prevent adoption by fragmenting the Qubes development and user community by building up perfection as the adversary of good, with meme's like "If it isn't verifiable, it will never be truly secure." Or, "I would happily give up (X application support or usability feature necessary for mainstream audiences) for a reduced TCB."

Such attacks (MIL-DEC) are standard operating procedure for the US defense establishment: Andrew W. Marshall, the most influential military thinker inside the beltway for over 50 years, earned his stripes convincing Soviets to allocate vast resources to counter fictional (or exaggerated) US capabilities.

The Snowden slides make it explicit that NSA is well aware that the biggest barrier to secure computing is usability. If NSA --or anyone at all-- is in your threat model, it's really the most important thing. Which is the most brilliant thing about Qubes (among many): it mitigates the impact of human errors in both software development and use. And it permits people to use the (insecure) applications they need to live their lives in a reasonably secure way.


With love,
George