[qubes-devel] securing netvm and dom0

[Peter Moody]

Howdy,

I have a somewhat strange use-case; I like to try and use qubes (or
something like qubes) to protect not only the user applications (and
appvms) from each other, but as an administrator, I also want to set
this up so that the user can't bypass my additional policy.

So, I want to see if it's possible (currently, or in the future on the
roadmap) to use qubes to simulate air-gapped machines with distinct
security policies. I hope that makes sense. Basically, I want to
emulate a setup where a user has two machines, one which can access
trusted resources and one which can't.

After spending a little less than a day with this (very cool, btw!),
it seems like I can probably do this, but it would require some
hacking on qubes to make it possible. Before I spend a lot of time
getting dirty, I would like to see if:

1) there's an easier way :)
2) it makes sense from your perspective (and you'd be willing to
review patches)

The high-level is that I'd like to be able to set up two appvms in
which I fully expect an empowered user will need to sometimes run as
root (to install software, etc). I need there to be different network
policies applied to each app-vm (say, one can talk to the SCM, and the
user can run gcc/make/etc there and the other can only browse the
internet), and I need the user to not be able to tweak those network
policies.

So first question is, does this make sense as a potential use-case for
qubes? From an 'enterprise' (I detest that word almost as much as
'apt', so apologies for using it) perspective, this would be very
useful.

It seems like I can do this if I can lock down dom0 and netvm;
specifically, I think I'd need to be able to prevent users from being
able to run qvm-run with --user=root. The intent here is so that I
can apply my network policy on the netvm, which I note somewhat
contravenes the stated goals in your spec-doc. for handling root on
the appvms, I expect that I can tweak the template images (and
possibly qvm-create?) to include an /etc/sudoers. This would seem to
require that I modify the spec for sending commands to the vms to
remove the user portion.

So my last question is, would you fine folks be amenable to reviewing
patches along these lines?

Cheers,
/peter

[Joanna Rutkowska]

On 05/01/2010 01:11 AM, Peter Moody wrote:
> Howdy,
>
> I have a somewhat strange use-case; I like to try and use qubes (or
> something like qubes) to protect not only the user applications (and
> appvms) from each other, but as an administrator, I also want to set
> this up so that the user can't bypass my additional policy.
>

Qubes does not pretend to be a multi-user system.

We originally discussed some possibilities of creating unprivileged
(multi) user account(s) in Dom0, so that e.g. user Alice didn't have
access to user's Bob's AppVMs. But Rafal immediately came up with a
dozen on of potential attack vectors from such unprivileged user
accounts to system admin (root), that we decided to give up on this. The
biggest problem here is that the Xen infrastructure, e.g. the Xen Daemon
(xend)'s management interface, has not been designed to allow for secure
control of Xen by an unprivileged user. So, there doesn't seem to be a
secure way to e.g. allow user Alice to talk to Xend in order to control
her VMs, but at the same time to not introduce huge attack surface that
might let her escalate to root.

Plus, there are many other avenues for a user that has physical access
to the machine to escalate themselves to root. E.g. they can boot system
in single user mode (this will be in the future prevented as a side
effect of using Intel TXT trusted boot). Or the user might insert a
Firewire/PCCARD and again gain full control over the system (this will
be in the future prevented via more fine-grained VT-d permissions and
isolated storage domain).

So, for the above reasons, we currently do not plan to implement support
for multi-users for Qubes. We just know it cannot be done securely in
the moment.

We currently try to protect the user from various threats, rather than
protect the system from the user.

Obviously other OSes, like Windows or Mac, are not any better in terms
of multi-user security.

joanna.

[Peter Moody]

On Mon, May 3, 2010 at 3:33 AM, Joanna Rutkowska
<joa...@invisiblethingslab.com> wrote:
> On 05/01/2010 01:11 AM, Peter Moody wrote:
>> Howdy,
>>
>> I have a somewhat strange use-case; I like to try and use qubes (or
>> something like qubes) to protect not only the user applications (and
>> appvms) from each other, but as an administrator, I also want to set
>> this up so that the user can't bypass my additional policy.
>>
>
> Qubes does not pretend to be a multi-user system.
>
> We originally discussed some possibilities of creating unprivileged
> (multi) user account(s) in Dom0, so that e.g. user Alice didn't have
> access to user's Bob's AppVMs. But Rafal immediately came up with a
> dozen on of potential attack vectors from such unprivileged user
> accounts to system admin (root), that we decided to give up on this. The
> biggest problem here is that the Xen infrastructure, e.g. the Xen Daemon
> (xend)'s management interface, has not been designed to allow for secure
> control of Xen by an unprivileged user. So, there doesn't seem to be a
> secure way to e.g. allow user Alice to talk to Xend in order to control
> her VMs, but at the same time to not introduce huge attack surface that
> might let her escalate to root.

So one point to note is that I'm not actually asking about having this
be a multi-user system, i'm just looking for a way to lock the single
user out of root on the two system vms. I wouldn't ever plan to
support more than one user on the system, so I shouldn't need to
protect against other unprivileged users in dom0. I'm trying to
emulate having two distinct single-user machines running on the one
piece of metal.

Does that change anything?

> Plus, there are many other avenues for a user that has physical access
> to the machine to escalate themselves to root. E.g. they can boot system
> in single user mode (this will be in the future prevented as a side
> effect of using Intel TXT trusted boot). Or the user might insert a
> Firewire/PCCARD and again gain full control over the system (this will
> be in the future prevented via more fine-grained VT-d permissions and
> isolated storage domain).

Yeah, the booting problem is one that I know is outside of the domain
of qubes, but it does sound like you already have plans to 'fix' both
of these issues in the future :)

> So, for the above reasons, we currently do not plan to implement support
> for multi-users for Qubes. We just know it cannot be done securely in
> the moment.
>
> We currently try to protect the user from various threats, rather than
> protect the system from the user.
>
> Obviously other OSes, like Windows or Mac, are not any better in terms
> of multi-user security.

true. :-/

> joanna.
>
>

Cheers,
/peter

[Joanna Rutkowska]

Not really, because the main problem is how to stop Alice -> root
attacks, not e.g. Alice -> Bob. So, whether you want to have just one
vs. more-then-one unprivileged user in Dom0, is basically the same
problem with the same challenges.

I'm not saying they're not solvable, but are currently not planning on
investing our efforts into this directions, as I think there are more
important things to do first.

But of course, if you have an idea of how to lock down xend, so that we
could grant securely access to it (and only to some operations) to an
unpriviliged user, we would most likely be willing to incorporate your
patches.

joanna.

[Peter Moody]

On Mon, May 3, 2010 at 9:45 AM, Joanna Rutkowska

Sounds good.

Cheers,
/peter

>
> joanna.
>
>

[jan....@gmail.com]

Hi,

is there a way to connect to appvm console directly from qubes login screen? The reason for doing this is to give access to internet to other user while not giving him possibility to access anything else, he will be locked in virtual machine, neither usb copying will be allowed.
What is your opinion on this? What about security issues?

thanx for advice.

jan

Dňa pondelok, 3. mája 2010 12:33:07 UTC+2 Joanna Rutkowska napísal(-a):

[pixel fairy]

On Tuesday, October 11, 2016 at 3:16:45 PM UTC-7, jan....@gmail.com wrote:

Hi,

is there a way to connect to appvm console directly from qubes login screen? The reason for doing this is to give access to internet to other user while not giving him possibility to access anything else, he will be locked in virtual machine, neither usb copying will be allowed.
What is your opinion on this? What about security issues?

thanx for advice.

jan

 This is more the domain of tails, or a liveusb (linux installer). of course, if your going to do this, you should also lock the bios, set up anti evil maid, etc.

[Manuel Amador (Rudd-O)]

On 10/11/2016 09:47 PM, jan....@gmail.com wrote:
> Hi,
>
> is there a way to connect to appvm console directly from qubes login
> screen? The reason for doing this is to give access to internet to
> other user while not giving him possibility to access anything else,
> he will be locked in virtual machine, neither usb copying will be allowed.
> What is your opinion on this? What about security issues?
>
> thanx for advice.

There might be a way to create a special user session that, all it does,
is start a VM, connect to its Qubes GUID, and display whatever the
session has. No controls, no terminals, no Qubes Manager. You just
have to create your session as a script and add it to
/usr/share/xsessions. The guest user you are thinking of must be a
member of the qubes group, and under no circumstances may your guest
session program open any sort of application on dom0.

Best of luck.

> --
> 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
> <mailto:qubes-devel...@googlegroups.com>.
> To post to this group, send email to qubes...@googlegroups.com
> <mailto:qubes...@googlegroups.com>.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/qubes-devel/e557bb7e-b258-49e2-b3e4-af578614b73e%40googlegroups.com
> <https://groups.google.com/d/msgid/qubes-devel/e557bb7e-b258-49e2-b3e4-af578614b73e%40googlegroups.com?utm_medium=email&utm_source=footer>.
> For more options, visit https://groups.google.com/d/optout.


--
Rudd-O
http://rudd-o.com/

[Ilpo Järvinen]

On Wed, 12 Oct 2016, Manuel Amador (Rudd-O) wrote:

> On 10/11/2016 09:47 PM, jan....@gmail.com wrote:
> >
> > is there a way to connect to appvm console directly from qubes login
> > screen? The reason for doing this is to give access to internet to
> > other user while not giving him possibility to access anything else,
> > he will be locked in virtual machine, neither usb copying will be allowed.
> > What is your opinion on this? What about security issues?
>

> There might be a way to create a special user session that, all it does,
> is start a VM, connect to its Qubes GUID, and display whatever the
> session has. No controls, no terminals, no Qubes Manager. You just
> have to create your session as a script and add it to
> /usr/share/xsessions. The guest user you are thinking of must be a
> member of the qubes group, and under no circumstances may your guest
> session program open any sort of application on dom0.

Won't the login manager actually spawn another X with different DISPLAY
for the second user/session? At least earlier they seemed to work like
that. If so, it will likely fail as qubes_guid/shmoverride depend on
DISPLAY being :0?

It would be possible to extend qubes_guid/shmoverride to handle other
DISPLAYs too, however, the shmoverride tricks run so early in the init
chain that environment is not yet set up so the "DISPLAY" needs to be
acquired by parsing the commandline (also libc init seems incomplete
that early so I'm not sure if atoi()/strtol() can be safely called yet).


--
i.