Qubes vs. PIGA-OS

[Timo Juhani Lindfors]

Hi,

http://www.youtube.com/watch?v=hJpiJii44oo

seems to discuss a desktop security solution that uses XSELinux instead
of virtualization. I did not find the source code yet so it is bit hard
to assess their implementation but I think the presentation alone was
quite informative. They do talk about Qubes a bit too.

[Mikko Jakonen]

This is interesting..thanks :)

M
________________________________________
From: qubes...@googlegroups.com [qubes...@googlegroups.com] on behalf of Timo Juhani Lindfors [timo.l...@iki.fi]
Sent: Friday, September 21, 2012 6:04 PM
To: qubes...@googlegroups.com
Subject: [qubes-devel] Qubes vs. PIGA-OS

[7v5w7go9ub0o]

Interesting indeed (to this newbie). ISTM most items have been covered
in "invisible" postings.

Heh.. I was a little put off by their "can we trust XEN?" comment. In
fact we can't completely "trust" anything, so designing Qubes' critical
dependence around a *thin* bare-metal hypervisor seems the most
trustworthy way to deal with this: it is almost audit-able and has less
coding to go wrong - think they completely missed that crucial design
consideration.

[Danny Fullerton]

Personally I believe they are simply moving the problem around instead of really fixing it. The real problem we have with current system is the isolation layers big/complex/buggy APIs (RING 0/3). This is what we have been doing for years and it simply doesn’t work.

SELinux provide more granularities but it doesn’t solve the isolation mechanism problem. It still has a very large and complex attack surface. This is where a hypervisor make sense, something as small and simple as possible. Sure the problem from that point is to define what is small/simple enough - the tradeoff between security and features but the magnitude of critical code is far less.

I feel they did not outlined this different enough and in fact they seems to be questioning the security of XEN in favor of something big and complex (the traditional approach) which for me is complete nonsense.

Sent from Mobile

[Joanna Rutkowska]

On 02/20/13 14:37, program...@gmail.com wrote:
> Hi Guys,
>
> I'm one of the guys (Martin Peres) presenting in the talk you liked to.
>
> My answers are inlined.

>
> Le vendredi 21 septembre 2012 18:50:33 UTC+2, Danny Fullerton a écrit :
>>
>> Personally I believe they are simply moving the problem around instead of
>> really fixing it. The real problem we have with current system is the
>> isolation layers big/complex/buggy APIs (RING 0/3). This is what we have
>> been doing for years and it simply doesn’t work.
>>
>

> XEN isn't doing anything more than using a new ring (-1).

Technically this is not true, because Xen might very well use only Ring
0 if no HVMs are used (PV runs as ring 3 then).

> Rings are the only proper way to add real isolation that I know of.
> Do you have anything else in mind?
>

Well, rings, working together with MMU, are only a mechanism to isolate
processes from each other and from the super/hypervisor. You need more
than rings to e.g. isolate devices, and this is provided by IOMMU/VT-d,
which crucial if one wants to deprivilige networking and USB subsystems,
as we do in Qubes (essentially, since day one).

>
>>
>> SELinux provide more granularities but it doesn’t solve the isolation
>> mechanism problem. It still has a very large and complex attack surface.
>> This is where a hypervisor make sense, something as small and simple as
>> possible. Sure the problem from that point is to define what is
>> small/simple enough - the tradeoff between security and features but the
>> magnitude of critical code is far less.
>>
>

> In a way, I fully agree with you. Xen is like a kernel for kernels, but a
> simpler one. However, there is one thing you blatantly ignore. How can you
> provide a complex policy for interactions between your different domains
> (Xen's virtual machines) if you cannot actually understand in what context
> is an interaction (let's say syscall or whatever changes the state of
> anything) made from? Very often, a syscall can be clearly acceptable, but
> given the right context, it is unacceptable. Sure, we can find some
> interactions that are illegal all the time and some which are legal all the
> time, but most of them are in the grey area, and we cannot make a good
> decision without knowing this information. So, to me, the big size of the
> kernel is a necessary evil.
>

I don't quite follow your argument about the "gray area"? Can you
provide a specific example?

>>
>> I feel they did not outlined this different enough and in fact they seems
>> to be questioning the security of XEN in favor of something big and complex
>> (the traditional approach) which for me is complete nonsense.
>>
>

> Well, in order to understand my statement, you need to understand that a
> system's security isn't to be analysed only from a CPU/RAM point of view.
> Most of the peripherals from your computer have RAW access to your host
> memory.

What you saying is not true. Read about IOMMU/VT-d technology.

> Since we can access those devices and reprogram them from ring 0
> (unless you decide to give up any kind of acceleration), telling that
> adding ring -1 adds security is to me a non-sense since these peripherals
> can be reprogrammed from ring 0 to change the content of the RAM.
>

Again, not true.

> So, to me, XEN is just adding more complexity to solve basically nothing,
> unless you decide to give up all acceleration and you only want to
> implement a MLS-like policy (BIBA or Bell-Lapadula) even though we already
> know it doesn't work well in computer science because we lack a secure way
> of declassifying data which tends to put all the files with the same
> security level.
>

Xen provides isolated containers, that's all. Period. (Well at least
"striped" Xen that we use in Qubes OS). Xen knows nothing about devices
(except for the MCH, CPU), nothing about file systems, nothing about
networking, nothing about USB, nothing about display server, etc.

Now, how can we use those isolated containers, and e.g. create a secure
desktop system, is what Qubes OS is all about...

> Finally, let's have a look at the vulnerabilities and exploits found on
> XEN. Let's have a look at this one:
> http://www.informationweek.com/security/application-security/new-virtualization-vulnerability-allows/240001996
> We see that in this case, XEN was most likely programming the hw in a
> certain way which wasn't secure showing that hardware shouldn't be left out
> of the equation at all! I don't have the time right now to have a look at
> all the exploits found on XEN or any other system, but in the end, I feel
> like whenever some piece of code can access the hardware, security is
> compromised. So, for all these reasons, I think security should be
> implemented between rings 3 and 0 and not above.
>

Well, that's the exploit discovered by Rafal. Sure, it was fatal to
Qubes and Xen, in fact it has been the only fatal exploit against Qubes
I'm aware of, as well as for other OSes out there (with a notable
exception of Linux), but this has had little to do with "allowing access
to hardware"...? Do you even know how the attack worked? Many people
argue that this bug was in fact a processor bug, although Intel never
admitted it.

> Anyway, I'm glad to meet some people caring about security :) I would be
> happy to keep on discussing it with you!
>
> PS: you may be interested in the following;
> - latest presentation about the current projects to add security to the
> Linux graphics stack:
> http://www.x.org/wiki/fosdem2013/Slides?action=AttachFile&do=get&target=peres_ravier-fosdem-2013.pdf
> - How a PCIE express device can acceess the RAM (slide
> 16): http://phd.mupuf.org/files/toulibre2012_deeper_look.pdf
>

Hey, no offense, but it seems to me (by grepping your slides for the
words: "IOMMU" and "VT-d") like you just discovered the "lethal power"
of DMA attacks (better later than never!) and got, quite understandably,
totally shaken by this.

But hey, people (notably my team) has been researching this topic for
many years. Not only we analyzed the DMA attacks in the past, both for
offense, as well as defense (forensic, as well as cheating DMA
forensic!), and also methods of DMA attacks prevention (VT-d) as well as
attacks on those methods of prevention. See e.g. this paper I'm
specifically proud about:

http://www.invisiblethingslab.com/resources/2011/Software%20Attacks%20on%20Intel%20VT-d.pdf

But I digress -- so what is that you propose instead of Qubes?

Cheers,
joanna.

[Dario Faggioli]

On Wed, 2013-02-20 at 11:59 -0800, program...@gmail.com wrote:

> I agree that XEN is the only way I see to securely isolate complete
> non-Linux systems.
>
> I also agree that my slide telling "can we trust xen?" was stupid in
> many ways and I didn't even try to explain why (and kind of started
> this thread).
> However, I don't feel like we should always delegate domains isolation
> to XEN and the Linux kernel should keep thriving towards better
> security
> even if Xen/Qubes OS is always possible for those who don't mind the
> performance cost in certain scenarios.
>
Really interesting discussion, even for me that am not at all a security
guy!

So, you probably both/all you know about this already, but I thought it
could have been worthwhile to mention that, with Xen, you can combine
isolation and 'policing' (and forgive if it's not 100% accurate
terminology, I just said above that security disagrees with me :-P).

That is possible by using XSM and FLASK. So, basically, XSM is the
collection of hooks --just like LSM in Linux. FLASK provides the
policing --just like SELinux (AFAIU, they even share the same compiler,
etc.)

Some pointers:
http://xenbits.xen.org/docs/unstable/misc/xsm-flask.txt
http://wiki.xen.org/wiki/XSM
http://www.xen.org/files/xensummit_4/xsm-summit-041707_Coker.pdf

This all is already possible with Xen 4.2, but will be even better in
4.3.

Regards,
Dario

--
<<This happens because I choose it to happen!>> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://about.me/dario.faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)

[Joanna Rutkowska]

I have always thought that XSM is actually a stupid thing -- adding a
layer of complexity on top of something (Xen), whose sole purpose should
be to be... simple (this is what gives Xen an advantage over any
monolithic kernel). The hypervisor should provide only one "service":
isolated containers, no more, no less.

(And do you remember the *fatal* bug in FLASK found by Rafal, of course,
back in 2008, and which allowed to 0wn the hypervisor?)

Can you provide an example of how can XSM possibly be used in a scenario
of a system like Qubes?

joanna.

[Dario Faggioli]

On Thu, 2013-02-21 at 16:05 +0100, Joanna Rutkowska wrote:
> I have always thought that XSM is actually a stupid thing -- adding a
> layer of complexity on top of something (Xen), whose sole purpose should
> be to be... simple (this is what gives Xen an advantage over any
> monolithic kernel).
>

I see what you mean, and I think I agree with you on the risks of
complexity. However, I really know way too few about XSM to even have an
opinion on whether it is stupid or useful.

As I said, reading the thread it seemed like something that was being
neglected, and I just thought it was worth to mention it, to see what
you think about it. It looks I at least succeeded in that, as I now know
you don't like it! :-P

> The hypervisor should provide only one "service":
> isolated containers, no more, no less.
>

Again, I'd tend to agree, but, again, can't claim an authoritative
opinion, so I think I'll just pass.

> Can you provide an example of how can XSM possibly be used in a scenario
> of a system like Qubes?
>

Well, given all I said above, I just have no idea. However, if you're
interested, I can route the question to the NSA guy that maintains it,
point him to this thread (or have a new one started for the occasion)...
Should I?

[Joanna Rutkowska]

On 02/20/13 20:59, program...@gmail.com wrote:

(...)

>> I don't quite follow your argument about the "gray area"? Can you
>> provide a specific example?
>>
>

> Sure. It has to do with direct and indirect information flux.
>
> To understand what it means, we can imagine a system where an SELinux rule
> could force a user to run binaries owned by root only and placed in the
> (/usr)/bin directories.
> If the user manages to download/compile a binary and tricked one root app
> to place this program in /usr/bin/, then the user could run this app.
> SELinux didn't track that the program was written by the said root-app that
> had, in the past, accessed a file from the user.
>
> What I'm trying to describe here is the functionning of PIGA
> (http://www.labri.fr/perso/solanki/publications/honeypot_piga.pdf) which
> enables system administrators to write security properties and instanciate
> them. The resulting security properties are then met with the SELinux
> policy already in place and a compiler will try to find all the ways to
> violate the security properties and record the chain of syscalls needed.
>
>

(...)

>> Xen provides isolated containers, that's all. Period. (Well at least
>> "striped" Xen that we use in Qubes OS). Xen knows nothing about devices
>> (except for the MCH, CPU), nothing about file systems, nothing about
>> networking, nothing about USB, nothing about display server, etc.
>>
>

> Yes, and that was the reason why I started talking about the lack of
> context from which the hypercalls are made from.
> This context is necessary for handling indirect information fluxes.
>
>
>

(...)

This is basically a discussion of: can we use MAC or similar formally
defined security policy, as implemented e.g. by SELinux to secure a
desktop OS? I believe the answer is no, because coming up with a good
policy is too complex a process to expect desktop users to be able to do
it themselves. Besides understanding how the actual policy mechanisms
work, it usually also requires good understanding of how specific
application (for which we would like to write a policy) work, in the
first place.

Perhaps the apps should come with proper policies already, then? This is
essentially what OSX is doing with their sandboxing technology (also
based on MAC, BTW). But this approach assumes we... trust the app
developer: that he or she came up with a correct, as well as
non-malicious, policy.

So, comparing this to Qubes, I think such approaches could still be
useful *inside* Qubes domains (VMs) to harden them. I still believe that
domain separation (say: "personal", "work", "banking",
"secret-project-X") is the most important "security policy" on a desktop
system. This is because it's the simplest and most intuitive way. After
all we're used to it very well: e.g. it's common for people to have
"work phone" and "personal phone", "work email" and "personal email",
"office friends", and "private life", etc. So, why should I now put all
my stuff into one "machine"?

Of course Qubes also provides some additional benefits, that none of the
traditional kernel-based security policy could provide today -- these
are things such as untrusted networking stacks, USB stacks, etc. All
those things are only possible if we can "move" the specific devices
(NICs, USB controllers, other) into untrusted VMs. And this is what we
do in Qubes.

Additionally, implementation wise, Qubes isolation has an edge over any
isolation imposed by monolithic kernel, because the interfaces exposed
to untrusted entities (so, what is exposed to a VM on Qubes, or what is
exposed to a process on, say, Linux w/ SELinux) are much leaner on
Qubes. And here we talk about orders of magnitude smaller interfaces...

(...)

>> But I digress -- so what is that you propose instead of Qubes?
>>
>

> I agree that XEN is the only way I see to securely isolate complete
> non-Linux systems.
>
> I also agree that my slide telling "can we trust xen?" was stupid in many
> ways and I didn't even try to explain why (and kind of started this
> thread).
> However, I don't feel like we should always delegate domains isolation to
> XEN and the Linux kernel should keep thriving towards better security
> even if Xen/Qubes OS is always possible for those who don't mind the
> performance cost in certain scenarios.
>

As I wrote above the two levels of isolation could be combined:
domain-level isolation ("work", "personal", etc...) provided by
Qubes/Xen or other hypervisor, and apps-level isolation within one
domain, provided by whatever kernel we use in this VM (SELinux, OSX
sandboxing).

> As for Qubes OS, I actually find the GUI effort to be pretty nice and
> self-explanatory but in the end,
> Qubes OS puts all the security decision onto the user when there is
> information sharing between the VMs).

Qubes has a centralized policy that allows to e.g. disallow any
interactions of select VMs between each other (save for the exotic
covert channels, such as via CPU caches). E.g. I can easily forbid any
file or clipboard transfers between by "work" and "personal" VMs (which
I actually do).

Right now this policy is defined by the user, but there is nothing
fundamental in the architecture that would not allow for this policy to
be defined and provided by system administrators (= IT department). This
would require changes to the Window Manager, among other things. This is
one of the considered features for commercial spinoffs, BTW.

(...)

> You also spoke about trusting XEN only, but what about the GUIs that are
> meant to provide the user with the visual cues about what is going on?
> I know you worked on GUI isolation (in a blog post) and this is nice but I
> fear you relied on the fact that Kwin/plasma-desktop would run in a separate
> VM and wouldn't interact with any other applications so no outside
> malicious app could interract with it. However, plasmoids can be written in
> C++ and
> a user could use a malicious one and loose the visual cues. Don't think it
> could do anything more though but I don't know the exact design used in
> Qubes OS.
>

Qubes GUI domain is currently the same as Dom0. Everything that runs in
Dom0 is trusted and this includes the Window Manager (KDE or Xfce4
customized for Qubes) that is responsible for drawing window decorations
that provide visual indicators as to which domain a given window belongs
to (colorful frames, titelbars with domain name). This mechanism is
unspoofable, if we assume Dom0 is trusted (and without this assumption
everything falls down). All user apps run in AppVMs, not in Dom0. There
is no support for installing any new Window Manager plugins, such as
plasmoids you mentioned. There is even no networking in Dom0 -- think of
Dom0 (and X and the Window Manager that runs there) as of a trusted thin
client that is used to access and display AppVMs windows.

(Of course, a determined user can always copy some files to Dom0 using
"manual" methods, and run custom code there. This is because we don't
treat the user as an enemy. Although, as mentioned above, there are
plans for commercial versions where user will not have full control over
Dom0).

> Another big issue I have with XEN is concerning performance, especially in
> Graphics.
> I'm an X.org dev and it is saddens me to see a lot of work not being put
> into use in a secure system especially since the hw
> has everything we need to provide a safe interface to the userspace/other
> virtual machines. There must be a way to provide nice
> acceleration and greater security (albeit unlikely as effective as Qubes OS
> when the applications barely communicate with each others).
>

The lack of accelerated graphics (GPU in general) exposed to AppVMs is
the single biggest drawback of Qubes, I fully agree. It's just that we
don't know (yet) how to securely share GPU among many (untrusted) VMs. I
would be happy to discuss approaches to safe GPU virtualization
(preferably in a new threat).

joanna.

[Alex Dubois]

There is difference between research and implementation. 

To me Qubes is a pragmatic answer with current tools to provide an answer to a number of problems around isolation of domains while offering an UI to a user.

It could certainly be an answer to a commercial company which wants to provide isolation of its data and processes from Internet within few man years of effort devoted to the implementation of domain isolation policies.

And it is right now the most secure OS (vs amount of management effort) for any tech Savy.

Right now the fire is in the user workstation. You will find far less server exploits than client, because if you own the target, in one case you are locked in 20 layers of DMZ, in the other...

This is only the view of a Qubes user. But such a thread should not be in dev mailing list. 

Alex

On 26 Feb 2013, at 15:45, sidn...@gmail.com wrote:

Hi all,

I'm allowing myself to join the conversation.. I'm a PhD student at UCL, I worked on some aspects of PIGA during my undergrad (admin tools). I now look into how HCI theories can inform the design of desktop isolation mechanisms because I wasn't exactly happy with the way users are treated in the "state of the art" (i.e. PIGA and Qubes). My comments embedded below.

On Sunday, February 24, 2013 9:06:58 PM UTC, joanna wrote:

This is basically a discussion of: can we use MAC or similar formally
defined security policy, as implemented e.g. by SELinux to secure a
desktop OS? I believe the answer is no, because coming up with a good
policy is too complex a process to expect desktop users to be able to do
it themselves. Besides understanding how the actual policy mechanisms
work, it usually also requires good understanding of how specific
application (for which we would like to write a policy) work, in the
first place.

I 100% agree with you on the fact that users cannot come up with policies. Sysadmins barely can, either (http://z.cliffe.schreuders.org/academic.htm). And users are most likely not going to invest time in defining complex, burdening policies for a potential benefit that cannot be seen or quantified by them (http://dl.acm.org/citation.cfm?id=1595684, http://dl.acm.org/citation.cfm?id=1719050). Besides this there are plenty of indirect information flows, policy objects and subjects that users cannot come up with at specification time (see Shamal Faily and Ivan Flechais's research at Oxford on this, hopefully they will have publications precisely on this point soon).

Now that hits Qubes as well in a sense since users have to define high-level domains meant to contain their activities on the computer. And this according to HCI and CSCW literature is fairly unrealistic (I'll provide refs on demand since they're rather scattered. Best reads are probably Suchman 87 and Nardi 96 on this). There is also a level of interleaving of tasks related to different activities that has been pointed out by field studies (see Benbunan-Fich et al 11, Czerwinski et al 04, Mark et al 05, and Gonzalez and Mark 04, + some data here and there in other papers). Because people are used to window-centric and file-centric desktops, they tend to mix up things together and this is for me one of the main challenges to address for desktop security that isolates users' activities.

 

Perhaps the apps should come with proper policies already, then? This is
essentially what OSX is doing with their sandboxing technology (also
based on MAC, BTW). But this approach assumes we... trust the app
developer: that he or she came up with a correct, as well as
non-malicious, policy.

Correct policies and trustworthy developers are not enough. What has not been formally proved to correctly handle *any* input is not secure. By this I mean that an app that does something contrary to the user's desires as a consequence of its features being illegitimately used because of input coming from a malicious third-party is definitely not correct. e.g. macro in a malicious file that triggers unwanted behaviour, but this behaviour is performed only using "legitimate" syscalls for a given MAC policy. However formal systems poorly handle proofs that include things such as "human beings" :)

Qubes proposes here to restrict the damage caused to an AppVM, and PIGA to a PIGA-Systrans domain. The quality of the security the user enjoys in this case, for me, resides in the quality of the domain specifications...

 

So, comparing this to Qubes, I think such approaches could still be
useful *inside* Qubes domains (VMs) to harden them. I still believe that
domain separation (say: "personal", "work", "banking",
"secret-project-X") is the most important "security policy" on a desktop
system. This is because it's the simplest and most intuitive way. After
all we're used to it very well: e.g. it's common for people to have
"work phone" and "personal phone", "work email" and "personal email",
"office friends", and "private life", etc. So, why should I now put all
my stuff into one "machine"?

I was in touch two years ago with a French industrial who wanted to evaluate Qubes and PIGA and possibly using PIGA within Qubes VMs. I refused working with them for a number of reasons including signing NDAs and not disseminating findings to research communities but I can put you in touch. Email me if interested.

For the rest, you know from above what I think about the limitations of "putting all one's stuff into one machine" when the stuff is specified in advance by the user.

 

Of course Qubes also provides some additional benefits, that none of the
traditional kernel-based security policy could provide today -- these
are things such as untrusted networking stacks, USB stacks, etc. All
those things are only possible if we can "move" the specific devices
(NICs, USB controllers, other) into untrusted VMs. And this is what we
do in Qubes.

Additionally, implementation wise, Qubes isolation has an edge over any
isolation imposed by monolithic kernel, because the interfaces exposed
to untrusted entities (so, what is exposed to a VM on Qubes, or what is
exposed to a process on, say, Linux w/ SELinux) are much leaner on
Qubes. And here we talk about orders of magnitude smaller interfaces...

(...)

I am not getting into discussions about the kernel or hardware. I plead I am incompetent on the matter so I prefer to use my "not proved = not secure" assumption. Xen is orders of magnitude more likely to be secure than Linux, according to fair metrics since as TCB size / number of contributors, but it is not *secure* either. However I think Martin asking whether Xen can be trusted in the middle of a presentation explaining some of the many security-oblivious aspects of Linux was ill-advised. :)

I think "users are not the enemy" is precisely why in the end PIGA and Qubes cannot be compared.

> Another big issue I have with XEN is concerning performance, especially in
> Graphics.
> I'm an X.org dev and it is saddens me to see a lot of work not being put
> into use in a secure system especially since the hw
> has everything we need to provide a safe interface to the userspace/other
> virtual machines. There must be a way to provide nice
> acceleration and greater security (albeit unlikely as effective as Qubes OS
> when the applications barely communicate with each others).
>

The lack of accelerated graphics (GPU in general) exposed to AppVMs is
the single biggest drawback of Qubes, I fully agree. It's just that we
don't know (yet) how to securely share GPU among many (untrusted) VMs. I
would be happy to discuss approaches to safe GPU virtualization
(preferably in a new threat).

joanna.

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

[Marek Marczykowski]

On 26.02.2013 21:02, Alex Dubois wrote:
> There is difference between research and implementation.
>
> To me Qubes is a pragmatic answer with current tools to provide an answer to a number of problems around isolation of domains while offering an UI to a user.
>
> It could certainly be an answer to a commercial company which wants to provide isolation of its data and processes from Internet within few man years of effort devoted to the implementation of domain isolation policies.
>
> And it is right now the most secure OS (vs amount of management effort) for any tech Savy.
>
> Right now the fire is in the user workstation. You will find far less server exploits than client, because if you own the target, in one case you are locked in 20 layers of DMZ, in the other...
> This is only the view of a Qubes user. But such a thread should not be in dev mailing list.

Currently we have only one ML - qubes-devel, so it is the right place for such
discussion (which is about general system architecture and concepts, so it
fits perfectly in devel ML scope).

--
Best Regards / Pozdrawiam,
Marek Marczykowski
Invisible Things Lab

[Joanna Rutkowska]

On 02/26/13 16:45, sidn...@gmail.com wrote:
> Hi all,
>
> I'm allowing myself to join the conversation.. I'm a PhD student at UCL, I
> worked on some aspects of PIGA during my undergrad (admin tools). I now
> look into how HCI theories can inform the design of desktop isolation
> mechanisms because I wasn't exactly happy with the way users are treated in
> the "state of the art" (i.e. PIGA and Qubes). My comments embedded below.
>
> On Sunday, February 24, 2013 9:06:58 PM UTC, joanna wrote:
>>
>>

>> This is basically a discussion of: can we use MAC or similar formally
>> defined security policy, as implemented e.g. by SELinux to secure a
>> desktop OS? I believe the answer is no, because coming up with a good
>> policy is too complex a process to expect desktop users to be able to do
>> it themselves. Besides understanding how the actual policy mechanisms
>> work, it usually also requires good understanding of how specific
>> application (for which we would like to write a policy) work, in the
>> first place.
>>
>

> I 100% agree with you on the fact that users cannot come up with policies.
> Sysadmins barely can, either (http://z.cliffe.schreuders.org/academic.htm).
> And users are most likely not going to invest time in defining complex,
> burdening policies for a potential benefit that cannot be seen or
> quantified by them (http://dl.acm.org/citation.cfm?id=1595684,
> http://dl.acm.org/citation.cfm?id=1719050). Besides this there are plenty
> of indirect information flows, policy objects and subjects that users
> cannot come up with at specification time (see Shamal Faily and Ivan
> Flechais's research at Oxford on this, hopefully they will have
> publications precisely on this point soon).
>
> Now that hits Qubes as well in a sense since users have to define
> high-level domains meant to contain their activities on the computer. And
> this according to HCI and CSCW literature is fairly unrealistic (I'll
> provide refs on demand since they're rather scattered. Best reads are
> probably Suchman 87 and Nardi 96 on this). There is also a level of
> interleaving of tasks related to different activities that has been pointed
> out by field studies (see Benbunan-Fich et al 11, Czerwinski et al 04, Mark
> et al 05, and Gonzalez and Mark 04, + some data here and there in other
> papers). Because people are used to window-centric and file-centric
> desktops, they tend to mix up things together and this is for me one of the
> main challenges to address for desktop security that isolates users'
> activities.
>
>

This is (partitioning into domains), of course, a big challenge. Perhaps
the single biggest challenge that a system like Qubes must face.

However, in many cases it could be made reasonably acceptable, I think:

1) Most people will find it quite natural to separate "work" from
"personal", and perhaps from "banking", so using 2-3 domains should be
quite natural for many users. I believe if we could get people to use
just such 2-3 domains that would be a big win already. Because what's
the alternative? It's use just *one* domain for everything.

2) In corporate environments it's the IT department that should be
responsible for domain partitioning and setting up policies (e.g. which
networking resources can be accessed from which domains, which domains
can exchange files, clipboard, etc.). Qubes generally allows for that,
although the current implementation do not separate the user from the
administrator/policy manager. But as I said before, this is one of the
planned features for a commercial spinoff.

We also try our best to automate the use of domains via mechanisms such
as Disposable VMs, or the recently presented untrusted file converters.
More such mechanisms are underway, and the idea is that they all
(should) work somehow "automagically" hidden from the user.

>>
>> Perhaps the apps should come with proper policies already, then? This is
>> essentially what OSX is doing with their sandboxing technology (also
>> based on MAC, BTW). But this approach assumes we... trust the app
>> developer: that he or she came up with a correct, as well as
>> non-malicious, policy.
>>
>

> Correct policies and trustworthy developers are not enough. What has not
> been formally proved to correctly handle *any* input is not secure. By this
> I mean that an app that does something contrary to the user's desires as a
> consequence of its features being illegitimately used because of input
> coming from a malicious third-party is definitely not correct. e.g. macro
> in a malicious file that triggers unwanted behaviour, but this behaviour is
> performed only using "legitimate" syscalls for a given MAC policy. However
> formal systems poorly handle proofs that include things such as "human
> beings" :)
>
> Qubes proposes here to restrict the damage caused to an AppVM, and PIGA to
> a PIGA-Systrans domain. The quality of the security the user enjoys in this
> case, for me, resides in the quality of the domain specifications...
>

That's correct. Partitioning is very important -- one person using Qubes
might very well be orders of magnitude less secure than another person
using the same Qubes, but just using a different partitioning scheme.

>> Of course Qubes also provides some additional benefits, that none of the
>> traditional kernel-based security policy could provide today -- these
>> are things such as untrusted networking stacks, USB stacks, etc. All
>> those things are only possible if we can "move" the specific devices
>> (NICs, USB controllers, other) into untrusted VMs. And this is what we
>> do in Qubes.
>>
>> Additionally, implementation wise, Qubes isolation has an edge over any
>> isolation imposed by monolithic kernel, because the interfaces exposed
>> to untrusted entities (so, what is exposed to a VM on Qubes, or what is
>> exposed to a process on, say, Linux w/ SELinux) are much leaner on
>> Qubes. And here we talk about orders of magnitude smaller interfaces...
>>
>> (...)
>>
>

> I am not getting into discussions about the kernel or hardware. I plead I
> am incompetent on the matter so I prefer to use my "not proved = not
> secure" assumption. Xen is orders of magnitude more likely to be secure
> than Linux, according to fair metrics since as TCB size / number of
> contributors, but it is not *secure* either.

(...)

Ohoho, formally proven, you say? Such claims always make me smile... If
you want to prove a piece of system code to be safe/secure, then you
should start with proving the CPU first, and then the chipset, at least
the MCH. At the very least build a formal model of the CPU and the MCH.

And can you quote at least one paper that would provide a formal model
for any of the modern Intel CPUs and MCHs? I have reasons to believe
that even Intel themselves (and believe me, there are lots of smart
people at Intel) lacks such formal models...

And once you deal with CPU and MCH, then you, sadly, must prove the BIOS
to be safe, because, sadly today even if one uses Intel TXT for trusted
boot, the BIOS is still part of the TCB :/

We (ITL), as well as Loic and his team, have had our part in showing _in
practice_ why this all is so important.

So, I think that "formally proven" systems, based on contemporary
hardware (processors, chipsets, GPUs) are a myth and will _never_ be a
reality, at least not within the lifespan of my (current) life. Unless
there was a big revolution in how CPUs and chipsets are made...

Anyway, just out of curiosity, what OS do you use on your primary machine?

joanna.

[bradbury9]

I know this post is a bit old, but this is an interesting doc in the dangers of complex systems http://www.ctlab.org/documents/How%20Complex%20Systems%20Fail.pdf

I totally agree with Joanna on security though isolation + keeping things simple.

[Zrubecz Laszlo]

On 26 February 2013 21:58, Joanna Rutkowska

<joa...@invisiblethingslab.com> wrote:

> 1) Most people will find it quite natural to separate "work" from
> "personal", and perhaps from "banking", so using 2-3 domains should be
> quite natural for many users. I believe if we could get people to use
> just such 2-3 domains that would be a big win already. Because what's
> the alternative? It's use just *one* domain for everything.

Every systesm just as secure as the weakest link in that system.

As I see Qubes is the only system where the weakest link is always the
user. Even if the user is a highly educated security specialist!



And the other hand I still belive that technical solutions will newer
save the lasy users from their own mistakes.



--
Zrubi

[Joanna Rutkowska]

Well, Qubes is "only" _tools_ for people to protect themselves. At least
at this stage. Just like, say GPG...

Although I still think it's actually easier to use Qubes in a somehow
sensible manner, for an average person (save for occasional hardware
compatibility issues during installation that are typical for most Linux
systems), than it is to learn and properly use... GPG!

Shocking, huh?

joanna.

[7v5w7go9ub0o]

On 02/28/13 05:51, Joanna Rutkowska wrote:
> On 02/28/13 11:43, Zrubecz Laszlo wrote:
>> And the other hand I still belive that technical solutions will
>> newer save the lasy users from their own mistakes.
>

> Although I still think it's actually easier to use Qubes in a
> somehow sensible manner, for an average person (save for occasional
> hardware compatibility issues during installation that are typical
> for most Linux systems), than it is to learn and properly use...
> GPG!

Yes. Especially when increasingly-security-aware governments and
businesses have their IT shops thoughtfully set up Qubes-based machines
for their "lazy"* users (*actually, thoughtful, productive, non-geeky
users who are very busy getting their primary jobs done, and will always
look for shortcuts).

There is a new and growing national awareness here (U.S.) regarding
cyber theft (e.g. spear phishing), network break-ins, and other
mischief. Qubes can offer some significant protection and seems to be
emerging at a perfect time .

>
> Shocking, huh?

Heh.... true - it is almost impossible to "sell" GPG to any other than
techie types of a certain age. Which partially explains the recent
emergence of, e.g., <https://silentcircle.com/> .

Predictably Silent Circle or other will become a corporate standard and
migrate to laptops for more serious work - these will be the same
businesses interested in Qubes - and their ITs will develop a Qubes
"template" (perhaps a domain?) for best use of Silent Circle on a
Qubes-secured box. This could happen very quickly.

(If this vision makes sense, is it too soon for someone from ITL to
introduce Qubes to Silent Circle for mutual awareness, and possible
mutual benefit (they consult with security-oriented corporate customers;
you will soon consult with security-oriented corporate customers - they
don't want their communications product compromised by a focused
Trojan)? Perhaps one of their techies is on this list?)