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