read-only/disp dom0

[mihaig...@gmail.com]

Would it be possible to have the dom0 as read-only/disposable to prevent local attacks?...As I read on qubes-devel, passwords are easy to get, even OTP does not protect from local attacks after you already logged in. Sonner or later everyone will leave the machine unattended, or tricked into doing it. Isolation and templateVM are great, but if someone can so easily compromise dom0 account with local attacks...
Passwords do not sound like real security, since it's something you hide from the attacker. In real security I should willingly give my Qubes machine to anyone and they still won't be able to compromise its integrity, if such a thing is possible...That is why I was thinking at a dom0 that can be reset after restart (like DispVM, even if someone compromised it, I just reboot to the "clean" one) but don't know if it is technically possible once the attacker has root on dom0.
And for modifications (dom0 updates, config, etc) have a second boot entry that you use with OTP only when you are in a lower risk environment (alone at home, etc)...so no otp token to carry with you all the time, lower risk for hidden cams, sniffing, etc...Or a choice for a "logoff pwd" that will write the modifs on disk.
It seems a good thing to be able to leave your PC unattended and be sure its integrity is preserved, don't know if in reality it is possible though.

[Zrubecz Laszlo]

On 21 July 2014 19:44, <mihaig...@gmail.com> wrote:
> I should willingly give my Qubes machine to anyone and they still won't be able to compromise its integrity, if such a thing is possible...

Not that is simply not possible.

If an attacker has a physical access to your machine then game is
over. And you surely lost that battle.

Not even AEM will save you from compromising your machine but at least
warn you if that's happened.



--
Zrubi

[Joanna Rutkowska]

On 07/21/14 19:44, mihaig...@gmail.com wrote:
> Would it be possible to have the dom0 as read-only/disposable to
> prevent local attacks?

When you write "read-only" VM you probably mean just a read-only
filesystem (at least the root fs), right? Even if that was possible to
do (which it isn't easily I think) it would only provide you with an
illusion of security. This is because it's perfectly possible for the
attacker to subvert your Dom0 with memory-only rootkits and not to touch
your fs ever. The attackers rootkits will then be able to survive as
long as you don't reboot your system, which typically occur every few
weeks or even less often (we do have S3 sleep!). And even if you wanted
to restart your system everyday, there is still enough damage to be done
within just that time.

Disposable VM-based GUI domain (but not Dom0) might make more sense, but
see the discussion below.

> ...As I read on qubes-devel, passwords are easy to get,

You mean are easy to sniff via camera or h/w keystroke loggers? True.

> even OTP does not protect from local attacks after you
> already logged in.

Well, yeah... after you log in, you're entrusted. The computer can only
recognize you is you, because you can log in, using one way or another.

> Sonner or later everyone will leave the machine
> unattended, or tricked into doing it.

Auto screenlocking is your best friend.

> Isolation and templateVM are
> great, but if someone can so easily compromise dom0 account with
> local attacks... Passwords do not sound like real security, since
> it's something you hide from the attacker.

Every authentication mechanisms assumes there is something that one
"hides" from the attacker. It might be a password/passphrase, or it
might be a private key or secret seed stored deep in a OTP token or a
client cert.

> In real security I should
> willingly give my Qubes machine to anyone and they still won't be
> able to compromise its integrity, if such a thing is possible...

Not with giving them *admin* access.

> That is why I was thinking at a dom0 that can be reset after restart
> (like DispVM, even if someone compromised it, I just reboot to the
> "clean" one) but don't know if it is technically possible once the
> attacker has root on dom0.

With Qubes R2 architecture access to Dom0 gives full admin rights, so
this is not possible. Even if Dom0 access was limited -- e.g. the user
was interfacing with a de-privilieged GUI domain, still he or she would
get full access to the AppVMs, where the user data live. The only
benefit would be that the whole interaction could be now reliably logged
for forensics reasons.

> And for modifications (dom0 updates, config, etc)
> have a second boot entry that you use with OTP only when you are in a
> lower risk environment (alone at home, etc)...so no otp token to
> carry with you all the time, lower risk for hidden cams, sniffing,
> etc...Or a choice for a "logoff pwd" that will write the modifs on
> disk. It seems a good thing to be able to leave your PC unattended
> and be sure its integrity is preserved, don't know if in reality it
> is possible though.
>

With current Qubes R2 architecture we don't support such dual
non-admin/admin login, but might support it in R3. But again, note that
access to the user VMs is what would still be possible from such limited
non-admin GUI domain login.

joanna.

[Marek Marczykowski-Górecki]

On 21.07.2014 19:44, mihaig...@gmail.com wrote:
> Would it be possible to have the dom0 as read-only/disposable to prevent
> local attacks?...As I read on qubes-devel, passwords are easy to get, even
> OTP does not protect from local attacks after you already logged in. Sonner
> or later everyone will leave the machine unattended, or tricked into doing
> it. Isolation and templateVM are great, but if someone can so easily
> compromise dom0 account with local attacks...

There are two separate issues here:
1. Resistance for one-time physical attacks, i.e. attacker stole your laptop
and try to retrieve the data.
2. Resistance for installing backdoors - i.e. whether is it safe to use that
hardware after attacker had access to it.

You can try to protect against the first one (encryption, OTP etc), but the
second one is always lost cause (assuming sophisticated enough attacker).
He/she can always install some hardware keyloggers, screen-dumping device,
memory-dumping device, etc. The best what software can do here is to warn you
when such actions were detected (which can be impossible in some cases).

Read-only/disposable dom0 would not solve any of _those_ problems (but as
Joanna already said, we still might implement this in R3 for other reasons).
When the attacker have access to dom0, he/she can copy all your data,
regardless of read-only or read-write dom0. Also when attacker had access to
your hardware, even when your system prevented software-based attacks
(encryption, strong password, OTP, tokens etc), some hardware backdoors could
be installed.

BTW When attacker have access to dom0 (i.e. is authenticated), even if dom0 is
"disposable", it would not protect against rootkits in VMs itself. Templates
are often treated as security feature, but it isn't:
https://wiki.qubes-os.org/wiki/SoftwareUpdateVM#NoteontreatingAppVMsrootfilesystemnon-persistencyasasecurityfeature

--
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?

[mihaig...@gmail.com]

Thanks for all explanations, I think I understand there will never be such thing as complete security, since you create the problem yourself simply by using the computer. The only way is to never use it.:)

OK, so the part about giving the machine to someone and preserve its integrity is not real, but how about making the OS more resilient against trivial local attacks that most people can do, like installing a software rootkit.
For example, I am in public/work/clients with my machine and have to leave it unattended, what are my options right now?
From your posts I learned:
1) lock the screen with strong password (easily circumvented by hw keylogers, cams... that got the pass before)
2) lock the screen with OTP (can this be simply circumvented?)
3) use autoscreen locker (like for ex have a bluetooth device on you that locks screen once you get away from you laptop)...btw, this will not increase attack surface?

According to what you guys already said above, the attacker still can:
1) change VMs (but she/he can do that even remotely since they are normal windows/linux machines). And Qubes isolation feature works well here, because even with a keylogger in a VM, for example, the attacker will only get keystrokes when you work in that VM.
2) get your data (yes. like you said, this is a separate issue)
3) install sophisticated hw devices (maybe seal the laptop if possible, or there is really nothing to do. Anyway, most people don't have access to this kind of devices and people who have will find one way or another to your machine).
4) install rootkits in memory (they go away on reboot)
5) something I missed?

So, the conclusion so far, in a situation like above, the best way to secure your machine is to have a wireless token on you all the time that autolocks the machine once you get away from it AND to use OTP to unlock it. Did I get this right?
Disposable dom0/GUI sounds more elegant then all that, if it can provide the same level of security. With disposable dom0/GUI you just reboot your machine assuming someone tampered with it...This seems to integrate well into Qubes since this unusual OS once set up, you work mostly in VMs and only need to change dom0 once in a while for updates, etc. Also, less money to spend on OTP/autoscreen lock wireless devices for your clients that want protection from local trivial attacks, if you manage to sell the OS to companies with lots of people. :)

Do you guys get into situations like that (being in public/work/clients and have to leave the machine unattended) daily?...I am wondering what do you actually do to protect your laptops?

[Franz]

On Tue, Jul 22, 2014 at 5:05 PM, <mihaig...@gmail.com> wrote:

Thanks for all explanations, I think I understand there will never be such thing as complete security, since you create the problem yourself simply by using the computer. The only way is to never use it.:)

OK, so the part about giving the machine to someone and preserve its integrity is not real, but how about making the OS more resilient against trivial local attacks that most people can do, like installing a software rootkit.
For example, I am in public/work/clients with my machine and have to leave it unattended, what are my options right now?
From your posts I learned:
1) lock the screen  with strong password (easily circumvented by hw keylogers, cams... that got the pass before)

well this is not so easy. The webcam installed in my laptop is blinded by a black elastic tape. And the keyloggers should be in Dom0, which is superprotected and with no network access.

IMHO also a BIOS password may help for physical attacks. Even if there are backdoors in BIOS (most probably) the person trying to physically attack your computer should have access to these backdoors which also is not easy.

best

 

2) lock the screen with OTP (can this be simply circumvented?)
3) use autoscreen locker (like for ex have a bluetooth device on you that locks screen once you get away from you laptop)...btw, this will not increase attack surface?

According to what you guys already said above, the attacker still can:
1) change VMs (but she/he can do that even remotely since they are normal windows/linux machines). And Qubes isolation feature works well here, because even with a keylogger in a VM, for example, the attacker will only get keystrokes when you work in that VM.
2) get your data (yes. like you said, this is a separate issue)
3) install sophisticated hw devices (maybe seal the laptop if possible, or there is really nothing to do. Anyway, most people don't have access to this kind of devices and people who have will find one way or another to your machine).
4) install rootkits in memory (they go away on reboot)
5) something I missed?


So, the conclusion so far, in a situation like above, the best way to secure your machine is to have a wireless token on you all the time that autolocks the machine once you get away from it AND to use OTP to unlock it. Did I get this right?
Disposable  dom0/GUI sounds more elegant then all that, if it can provide the same level of security. With disposable dom0/GUI you just reboot your machine assuming someone tampered with it...This seems to integrate well into Qubes since this unusual OS once set up, you work mostly in VMs and only need to change dom0 once in a while for updates, etc. Also, less money to spend on OTP/autoscreen lock wireless devices for your clients that want protection from local trivial attacks, if you manage to sell the OS to companies with lots of people. :)

Do you guys get into situations like that (being in public/work/clients and have to leave the machine unattended) daily?...I am wondering what do you actually do to protect your laptops?

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

[syd2...@gmail.com]

If you are walking away from your computer, you need to be equally concerned about the proximity of CCTV cameras. They are good for security - but also good for hacking (instructions on youtube) since they are often wifi-enabled. I know of a group of computer hackers who regularly hack such cameras. They use them to shoulder surf, capture video, track people, and steal items (when people are away or distracted).

[mihaig...@gmail.com]

There is a easy but ugly way to put dom0 rootfs in read-only mode, using /etc/sysconfig/readonly-root. It needs some rwtab modifications specific to Qubes and it needs to move the appvms dir into another writable partition. The servicevms dir is mounted nonpersistent, this provides the benefit of clearing up any external exploits on net/fwvm upon system reboot to the expense of 400MB RAM (my servicevms dir size), a few more secs at boot time and not remembering new network configs. This can be done also for VMs, if private.img is small enough to fit into RAM.

This does not offer any protection against trivial local attacks since the user can always remount / rw, according to qubes sudoers. This was mostly to see if is possible to run the system with ro dom0 rootfs. There are some minor errors, but does work on my machine (only used it a couple of days). Now I am thinking to put a root password in dom0 to dissalow remount /rw for local user, but I read in sudoers.d/qubes that is trivial for the local user to escalate to root. Also found an 2010 post concering local dom0 root escalation: "...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."
I hope this means the local user can't manage (update, modify config,..) VMs without introducing attack surface?

The way I am planning to use this: In public places where local attacks are possible, I want to use the readonly-root and only need to start/stop VMs (no need ever to type the root pwd). In private, where there are no local attackers and it is harder to be filmed/ keylogged..., I will remount / rw and do further configs, updates, etc. Does it make sense?

Is there any other trivial way to remount root rw for a local attacker with no root privilege (besides the known single user boot mode)?

As already stated, I am looking for a way to prevent trivial local attacks (I don't care about access to my files, only about my dom0 being modified), I fully understand now there will never be possible to secure your machine against skilled attackers, as long as you keep using it.

If someone is interested in implementing readonly-root (http://fedoraproject.org/wiki/StatelessLinux) in Qubes:
1) change /etc/sysconfig/readonly-root
2) mount / and /boot ro in fstab
3) move /var/lib/qubes/appvms on another rw partition
4) add "files /var/lib/qubes/servicevms (also backup,updates you want) /var/lib/upower /etc/xen" to /etc/rwtab.d/qubes ..maybe you need to add something else, according to your machine.
5) reboot and watch logs for errors caused by RO rootfs

[Pablo Costa]

On 22 July 2014 22:05, <mihaig...@gmail.com> wrote:

> Do you guys get into situations like that (being in public/work/clients and have to leave the machine unattended) daily?...I am wondering what do you actually do to protect your laptops?

If you are willing to reboot your laptop every time you feel it might
have been 'touched', you should not have any objection to put it to
sleep (some <10 seconds) or powering it off (some 1 to 2 minutes) and
slipping it in your backpack or briefcase when you have to leave your
desk. This is what I usually do. I don't feel like shutting down (or
rebooting, of course) because restoring my working desktop is far from
trivial.

Also about this OTP and shoulder surfing and stuff: I feel it would be
more convenient to carry a smartcard on your lanyard that combines
with your regular password to unlock the screensaver. I don't know how
Qubes/KDE can handle this because my laptops have shitty smartcard
readers that work only with windoze crap. I don't feel like trusting
BT for that matter, either.

[Joanna Rutkowska]

This (i.e. 2-factor authentication for Dom0 login) is doable and it was
discussed previously on this list. You should be able to keep the
blutetooth + whatever otp drivers/stacks in some VM (say, usbvm) and
have a trivial qrexec service that sends out the one time password to a
also-trivial service in Dom0.

joanna.

[Joanna Rutkowska]

What you wrote above makes little sense. If somebody is able to get code
running in Dom0, they would be able to disable/get around whatever
read-onliness of the filesystem you have there.

A better way to preserve Dom0 filesystem cleanness across reboots would
be to have a mechanism similar that we have for our AppVMs (effectively
read-only root filesystem based on a clean template). This would
require, I think, to have Storage Domain working, which is planned for
R3 or maybe even later, because is highly non-trivial.

However, in shorter perspective, the Dom0 split into GUI domain and
minimal, user-inaccessible Admin domain, should provide good enough
solution to your problem.

joanna.

[mihaig...@gmail.com]

> However, in shorter perspective, the Dom0 split into GUI domain and
>
> minimal, user-inaccessible Admin domain, should provide good enough
>
> solution to your problem.
>
>
>
> joanna.

Thanks, that is good news...although I don't understand how GUI dom0 separation will work:

> "1) GUI domain: running the real X server with a passthrough-GPU assigned
>
> 2) Admin domain (the real Dom0) which likely will not be even accessible
> to the user normally (i.e. will require special booting to login into
> Admin domain).
>
> The GUI domain could be then based on whatever Linux distro (and on
> Windows even in some commercial variants) we want -- i.e. one with good
> GPU support and latest KDE eye candy. The Qubes Manager and qvm-tools
> would all be running in the GUI domain too."

For the GUI domain to be disposable, I think it needs to keep its root.img in dom0? If so, how will it be updated?
All other VM will have their root.imgs in GUI domain?

If the Qubes VMM runs in GUI domain, it needs write access to all VM's .img files, according to the way Qubes Manager runs now. How could the GUI and other domains be isolated, then?