Is it important in Qubes OS to have a strong user password?

[adrelanos]

Hi,

how important is it to use a strong password for the operating system
user account? (The thing used at login.)

Which disadvantages would one have for using a weak one?

Would it matter if root password = user password?

Cheers,
adrelanos

[cprise]

The only important function for the dom0 user password I can think of is
the screen lock.

"Weak" depends on the context. IMHO, the threat model for a screen lock
is less demanding in terms of length/complexity (its only going to be
used to guard against an attacker on a keyboard, with input severely
limited by the unlock screen's constraints).

If this were a normal system (not Qubes) the threat model for the user
password is greatly expanded to brute force attempts via multiple
interfaces, and malware running as unprivileged trying to get admin
access. In Qubes, those attackers just hit the vm wall and don't get any
chance to even try a dom0 user password.

Adding a root password and making it the same as the normal dom0 user
sounds like it would keep casual users with physical access to the
system from making changes to the system. I haven't tried it but if you
have other people using the system it may be worth trying. However,
since the passwords are the same, anyone who knows how to unlock the
screen would also know the password for superuser functions (i.e.
freedom to change the core system).


Side note: Discussing this make me think that adding an option in Qubes
to require a password to change vm settings would be useful for certain
situations.

[Zrubecz Laszlo]

On 20 December 2013 00:42, adrelanos <adre...@riseup.net> wrote:
> Which disadvantages would one have for using a weak one?
>
> Would it matter if root password = user password?

root password is out of scope because the user can run any application
with sudo.



--
Zrubi

[Joanna Rutkowska]

On 12/20/13 06:35, cprise wrote:
>
> On 12/19/13 18:42, adrelanos wrote:
>> Hi,
>>
>> how important is it to use a strong password for the operating system
>> user account? (The thing used at login.)
>>
>> Which disadvantages would one have for using a weak one?
>>
>> Would it matter if root password = user password?
>>
>> Cheers,
>> adrelanos
>>
>
> The only important function for the dom0 user password I can think of is
> the screen lock.

Correct. In other words, preventing physical attacks: somebody capturing
your screenlocker password using a video monitoring, then stealing your
laptop when it is in sleep mode.

joanna.

[Joanna Rutkowska]

Yes, by default in Qubes we assume user == root in the Linux AppVMs
based on the default template, as well as in Dom0:

http://git.qubes-os.org/?p=joanna/core-admin-linux.git;a=blob;f=system-config/qubes.sudoers;h=23086ede18e2de8c7c369e73fbe6e8df4d158b58;hb=HEAD

http://git.qubes-os.org/?p=joanna/core-agent-linux.git;a=blob;f=misc/qubes.sudoers;h=8087a90a8c0a6f81d4fe45905a6aa9462de2a7ce;hb=HEAD

joanna.

[Axon]

cprise:

>
> On 12/19/13 18:42, adrelanos wrote:
>> Hi,
>>
>> how important is it to use a strong password for the operating system
>> user account? (The thing used at login.)
>>
>> Which disadvantages would one have for using a weak one?
>>
>> Would it matter if root password = user password?
>>
>> Cheers,
>> adrelanos
>>
>
> The only important function for the dom0 user password I can think of is
> the screen lock.
>

Agreed.

> "Weak" depends on the context. IMHO, the threat model for a screen lock
> is less demanding in terms of length/complexity (its only going to be
> used to guard against an attacker on a keyboard, with input severely
> limited by the unlock screen's constraints).
>

Yes, but in order to make a decision about how long and complex the
screen locker password should be (and this is an important decision,
since many users will be typing that password dozens of times every
day), we must know what kind of security the screen locker provides.
Obviously, the screen locker is only relevant to attackers with physical
access to the system. But physical access comes in degrees. For example,
if it's a desktop computer, the keyboard and mouse might be freely
accessible while the tower is locked in a metal box. In this case,
attacks which require access to internal components of the computer
(like cold boot attacks) are significantly more difficult (the degree of
difficulty depends on things like how hard it is to cut through the
metal box or break/pick/bump the lock). In this scenario, the screen
locker might be very useful *if* there really is no way to gain access
without the correct password. If it's easy to bypass the screen locker,
then the owner of the computer will probably have a false sense of
security (and have wasted money and effort on putting the tower in a
locked metal box!).

> If this were a normal system (not Qubes) the threat model for the user
> password is greatly expanded to brute force attempts via multiple
> interfaces, and malware running as unprivileged trying to get admin
> access. In Qubes, those attackers just hit the vm wall and don't get any
> chance to even try a dom0 user password.
>

(Unless, of course, the attacker can break out of the VM.)

> Adding a root password and making it the same as the normal dom0 user
> sounds like it would keep casual users with physical access to the
> system from making changes to the system.

The key word here being "casual." Even then, I would hesitate to say
this, as we really don't want to give anyone the impression that someone
with access to dom0 doesn't effectively own the system.

> I haven't tried it but if you
> have other people using the system it may be worth trying. However,
> since the passwords are the same, anyone who knows how to unlock the
> screen would also know the password for superuser functions (i.e.
> freedom to change the core system).

The problem with this is that Qubes is not intended to be a multi-user
system, and as soon as you introduce multiple users, you also introduce
a whole slew of complicated security issues that it would take us
forever to even begin to cover.

> Side note: Discussing this make me think that adding an option in Qubes
> to require a password to change vm settings would be useful for certain
> situations.

See above. This will only be useful against the most casual of people
with physical access. Only if they really have no idea what they're
doing (or have no desire to subvert your system) would a measure like
this be at all effective. And, even then, as a point of human
psychology, you probably shouldn't assume that someone who conveys the
appearance of ignorance or harmlessness can be trusted and isn't
secretly a smart, evil adversary.

[Axon]

Joanna Rutkowska:

But in the scenario you describe, the physical attack would *not* be
prevented. Since the laptop is in sleep mode, the disk has already been
decrypted, so all the attacker needs is the screen locker password,
which he already possesses due to the video monitoring.

[Joanna Rutkowska]

The point was: it should be hard to capture a strong screenlocker
password using some simple, accidental Video monitoring and unlock the
machine later. (Remember "Sneakers"?).

j.

[cprise]

Good point about impressions. However, there are many (very novice)
users on whom that impression would be lost anyway.

>> I haven't tried it but if you
>> have other people using the system it may be worth trying. However,
>> since the passwords are the same, anyone who knows how to unlock the
>> screen would also know the password for superuser functions (i.e.
>> freedom to change the core system).
> The problem with this is that Qubes is not intended to be a multi-user
> system, and as soon as you introduce multiple users, you also introduce
> a whole slew of complicated security issues that it would take us
> forever to even begin to cover.

No, not multiuser... just setting it up and maintaining it for someone
else (e.g. a client or a friend).

>> Side note: Discussing this make me think that adding an option in Qubes
>> to require a password to change vm settings would be useful for certain
>> situations.
> See above. This will only be useful against the most casual of people
> with physical access. Only if they really have no idea what they're
> doing (or have no desire to subvert your system) would a measure like
> this be at all effective. And, even then, as a point of human
> psychology, you probably shouldn't assume that someone who conveys the
> appearance of ignorance or harmlessness can be trusted and isn't
> secretly a smart, evil adversary.
>

But if your threat model only includes casual people at the physical
level (with the sophisticated attackers out on the Internet), then Qubes
fits the bill, and the root password fits that application of Qubes.

[Alex Dubois]

A good way to type the qubes password is to use a yubikey in static password mode as you do not type anything on the keyboard

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.
> Visit this group at http://groups.google.com/group/qubes-users.
> For more options, visit https://groups.google.com/groups/opt_out.

[Jonathan Miller]

On Sunday, December 22, 2013 5:01:23 AM UTC-5, Joanna Rutkowska wrote:

(Remember "Sneakers"?).

Too many secrets... 

Have you spent any mind on including qubes support for any of the yubikey authentication methods?

ref: http://www.yubico.com/applications/computer-login/linux/

ref: https://code.google.com/p/yubico-pam/wiki/ReadMe

-Jonathan

[Alex Dubois]

I implemented PAM support long ago. Should be straight forward to apply it to Dom0

Alex

--

[Jonathan Miller]

Thanks for engaging Alex.

Apologies, I have wasted a few of your moments. I left out a whole paragraph (and the train of thought that should have went along with it) above.

The basic PAM modules and configuration provide for the basic requirements of including the module, and requiring it for success or making it permissible to login with. One of the issues that arises from using the Yubikey as a 2FA provider is that sshd will need to be able to connect out to verify the OTP from the yubikey against a validation server reachable by IP. Would there be a reasonable way to permit this access out?

If this can be permitted, then the 2FA unlock screen could be provided and nullify the simple accidental observation of a password issue raised above. Additionally, if HOTP or TOTP could be used the time-series requirements of the 2FA would further protect from password-replay attacks in the future untrusted possession case. 

Secondly, and almost separately, there is an issue with selinux that blocks this outbound connection before it leaves the kernel. An sebool was added into f18+ to allow sshd to make the outbound connection through selinux. Will selinux be rolled into dom0 in the future, requiring changes such as this?

-Jonathan

[cprise]

On 12/31/13 11:14, Jonathan Miller wrote:

Thanks for engaging Alex.

Apologies, I have wasted a few of your moments. I left out a whole paragraph (and the train of thought that should have went along with it) above.

The basic PAM modules and configuration provide for the basic requirements of including the module, and requiring it for success or making it permissible to login with. One of the issues that arises from using the Yubikey as a 2FA provider is that sshd will need to be able to connect out to verify the OTP from the yubikey against a validation server reachable by IP. Would there be a reasonable way to permit this access out?

If this can be permitted, then the 2FA unlock screen could be provided and nullify the simple accidental observation of a password issue raised above. Additionally, if HOTP or TOTP could be used the time-series requirements of the 2FA would further protect from password-replay attacks in the future untrusted possession case. 

Secondly, and almost separately, there is an issue with selinux that blocks this outbound connection before it leaves the kernel. An sebool was added into f18+ to allow sshd to make the outbound connection through selinux. Will selinux be rolled into dom0 in the future, requiring changes such as this?

-Jonathan

I'm curious what the reason would be for using such a strong password for the dom0 user? Unless there is a successful VM-breakout, I can't see how there would be any brute-force attack against the password... going through the unlock/login prompt should slow down even an automated attacker to a snail's pace.

AFAIK, the root volume passphrase is where Qubes needs a long/entropic string.

[Jonathan Miller]

The encryption passphrase for the root volume should indeed be strong in most cases. Protecting the data at rest is of utmost importance to the mobile workstations most of us are accustomed to. A lost laptop with weak protection would be trivial to gain privileged access to potentially sensitive data. 

Furthermore, if travelling and power-conscious, I may not be able to sacrifice the power to perform a complete shutdown and restart of a laptop while running qubes. It may also be impractical due to risk of lost work efforts, or possible corruption of sessions due to hibernate/suspend complications. Some hardware and software just refuse to get along when it comes to suspend and hibernate.

Understanding that physical security is paramount to reducing overall exposures, one must also concede that it is simply not practical to completely shutdown a workstation every time you walk away from the keyboard. I believe that the sound way of protecting the interactive environment behind the dom0 root login is by means of strong authentication schemes.

Say a user in a cube farm had someone snooping over the wall, and observes the static password a few times, and can recount it with a reasonable accuracy. Maybe four or five attempts it would take if they were well organized and had observed it enough times. If I get up to refresh my coffee, this motivated and determined attacker can sit at my workspace, (exploiting the human trust of those around them as "so/so's cool with it, we're working on a project together" will usually get you by most people), knock around for a few moments while I'm AFK, and potentially get in. It's a first-time only type of attack, as the well organized and determined attacker can pull off, having observed enough. Could be days of surveillance, could be weeks. Even some of the most aggressive password schemes don't change a login password more often than 30 days. 

If I take my OTP token with me AFK, it would be impossible for this static password attack to succeed. The typical assembly of some static piece of password concatenated with the OTP provides the dynamic password, that can be (in the case of TOTP) time sensitive as well; so even if someone observed (in the case of an RSA or Verisign pin token) the numerical digits, they would only be viable for a finite period of time.

I'm not afforded the private workspace that I'd like, and am relatively security conscious with regard to snooping and eavesdropping, but complacency and familiarity creep up every so often. I believe that for the same reasons a corporation would expect to make benefit of 2FA on an shared ssh server, a typical linux user would make benefit of the same in shared meatspace.

A further iteration of this thought leans towards the ability of password protecting each appvm with differing credentials, thus allowing a trusted human to interact with a DispVM while not affording them the leeway to make a bad decision and snoop around some other VM.

I'd appreciate any feedback or pick-aparting you can do. I hope to learn as much from your scholarly criticism as I may be able to provide to you.

Thanks,

Jonathan

[cprise]

On 12/31/13 16:37, Jonathan Miller wrote:

The encryption passphrase for the root volume should indeed be strong in most cases. Protecting the data at rest is of utmost importance to the mobile workstations most of us are accustomed to. A lost laptop with weak protection would be trivial to gain privileged access to potentially sensitive data. 

Furthermore, if travelling and power-conscious, I may not be able to sacrifice the power to perform a complete shutdown and restart of a laptop while running qubes. It may also be impractical due to risk of lost work efforts, or possible corruption of sessions due to hibernate/suspend complications. Some hardware and software just refuse to get along when it comes to suspend and hibernate.

Understanding that physical security is paramount to reducing overall exposures, one must also concede that it is simply not practical to completely shutdown a workstation every time you walk away from the keyboard. I believe that the sound way of protecting the interactive environment behind the dom0 root login is by means of strong authentication schemes.

Say a user in a cube farm had someone snooping over the wall, and observes the static password a few times, and can recount it with a reasonable accuracy. Maybe four or five attempts it would take if they were well organized and had observed it enough times. If I get up to refresh my coffee, this motivated and determined attacker can sit at my workspace, (exploiting the human trust of those around them as "so/so's cool with it, we're working on a project together" will usually get you by most people), knock around for a few moments while I'm AFK, and potentially get in. It's a first-time only type of attack, as the well organized and determined attacker can pull off, having observed enough. Could be days of surveillance, could be weeks. Even some of the most aggressive password schemes don't change a login password more often than 30 days. 

If I take my OTP token with me AFK, it would be impossible for this static password attack to succeed. The typical assembly of some static piece of password concatenated with the OTP provides the dynamic password, that can be (in the case of TOTP) time sensitive as well; so even if someone observed (in the case of an RSA or Verisign pin token) the numerical digits, they would only be viable for a finite period of time.

I'm not afforded the private workspace that I'd like, and am relatively security conscious with regard to snooping and eavesdropping, but complacency and familiarity creep up every so often. I believe that for the same reasons a corporation would expect to make benefit of 2FA on an shared ssh server, a typical linux user would make benefit of the same in shared meatspace.

A further iteration of this thought leans towards the ability of password protecting each appvm with differing credentials, thus allowing a trusted human to interact with a DispVM while not affording them the leeway to make a bad decision and snoop around some other VM.

I'd appreciate any feedback or pick-aparting you can do. I hope to learn as much from your scholarly criticism as I may be able to provide to you.

Thanks,

Jonathan

As it happens, I'm not a scholar nor am I affiliated with ITL/Qubes. Others here may have something interesting to say about passwords, though.

Your surveillance concern sounds quite valid. Its too bad that translates into added complexity.

[Alex Dubois]

On Tuesday, 31 December 2013 16:14:08 UTC, Jonathan Miller wrote:

Thanks for engaging Alex.

Apologies, I have wasted a few of your moments. I left out a whole paragraph (and the train of thought that should have went along with it) above.

From my point of view, Yubikey in static password mode to unlock screen is sufficient to mitigate the risk of camera observing. You type let's say 8 characters password (to mitigate the risk of you loosing the yubikey), and then press the Yubikey to autotype let's say 24 characters "rest of the password" and auto type the enter key.
Using PAM + TOTP increase the attack surface with not much benefit.
With this set-up you increase your attack surface by having a USB port exposed to Dom0 but hide you unlock password.

The basic PAM modules and configuration provide for the basic requirements of including the module, and requiring it for success or making it permissible to login with. One of the issues that arises from using the Yubikey as a 2FA provider is that sshd will need to be able to connect out to verify the OTP from the yubikey against a validation server reachable by IP. Would there be a reasonable way to permit this access out?

If you implement the PAM module. The TOTP symetric key is stored in Dom0 and the Yubikey Library perform the match locally. There is no outbound connection to 3rd party server.
You will have to review the increased attack surface of PAM + YubikeyLib.

As I said above, I am not convinced that it is a better solution.
A long static password + PAM config to double next input time at each input is sufficient.
 

[Jonathan Miller]

Thank you.

With regard to OP's question, a strong password should be used for dom0 login, I think we are in agreement there?

I do believe that 2FA at the login is beneficial, especially with a OTP generated from something like a hardware token that must be in possession of the user, within a reasonable time constraint. I for instance have an NFC enabled Yubikey Neo that provides me the ability to generate OTP's on a mobile device, authenticated against a yubikey, that I can provide as a second auth factor at login time. This provides the 2FA without exposing the USB of dom0. 

I don't want to hijack the rest of this in a discussion about the Yubikey methods and their virtues. Rereading what I posted earlier I seem to have some scattered thoughts and obviously muddled login with sshd considerations. Out of respect to the OP and the rest of the participants, I'll take my discussion up at a later time or elsewhere if it proves to be more Yubikey centric than qubes limited. 

Thanks again for indulging

[Alex Dubois]

On Wednesday, 1 January 2014 15:50:47 UTC, Jonathan Miller wrote:

Thank you.

With regard to OP's question, a strong password should be used for dom0 login, I think we are in agreement there?

I do believe that 2FA at the login is beneficial, especially with a OTP generated from something like a hardware token that must be in possession of the user, within a reasonable time constraint. I for instance have an NFC enabled Yubikey Neo that provides me the ability to generate OTP's on a mobile device, authenticated against a yubikey, that I can provide as a second auth factor at login time. This provides the 2FA without exposing the USB of dom0. 

2FA has benefit if:
1 - the OS you are running is subject to compromise. You therefore need a something you have to "protect" your identity. In the case of Qubes, once the dom0 password is compromised, it is game over, therefore the second factor has not benefit.
2 - The system is usable by multiple users and the IT administrator want to limit the capability to share password between users. This is not the case here. Qubes is a single user system.

[pow(n00b, 3)]

I have to agree with both Jonathan and Alex here. It's game over if dom0 is compromised, both through remote and physical means. We also know that keystrokes can be captured by many different side channel methods so I believe in the extra security offered by 2FA.

I haven't tried it myself but FreeOTP (https://fedorahosted.org/freeotp/) offers OTP generation on mobile devices without using additional propriatry hardware, like Yubikey NEO. Also it should be fairly simple to roll your own OTP device using an airgapped Arduino/RasPi/Beaglebone + dot matrix LCD, or https://en.wikipedia.org/wiki/Skytone_Alpha-400 (because running FreeOTP on an always online Android/iOS just shifts the problem :/). What do you guys think about it?

[Joanna Rutkowska]

I think it would make sense to use a USB-bases security token that
generates OTP and which is handled by an (untrusted) usbvm. This way we
could have a convenience of a USB-based token device (as well as
resistance to remote sniffing methods via cameras or EM leaks), but
still preserve Dom0 from USB-based attacks (something that surely is
very practical and IMHO should be avoided at all costs).

So, the setup would involve a normal (untrusted) usbvm which would be
having the USB controller where one normally plugs the token assigned to
(in practice it might just have all the USB controllers assigned), and
the USB-token-specific software would be running in the VM. The output
from this software, i.e. the OTP password, would need to piped to Dom0
via qrexec service. I think the qrexec protocol would be just trivial,
comprising just one line of the password ("echo $OTP" on the client side).

Then in Dom0, the receiving server, after getting the OTP from the usbvm
(by doing: "read $OTP") would need to somehow pipe it to e.g. a PAM
module, just like the USB-token-specific software would do normally if
it run in Dom0.

This could probably work for Smart Card-based tokens, and perhaps even
NFC based tokens, because I suppose these are all USB devices. And if
they are true PCI devices, then it makes no difference either, because
we can also assign it to the "usbvm" still.

Seems very simple and useful. Anybody interested in implementing this?

Cheers,
joanna.

[Alex Dubois]

Happy to.

 

I would first do the static password yubikey (which is basically a USB Keyboard) (i.e. no processing in Dom0 of the OTP).

However I think it is important that the architecture allows for various authentication device type.

 

Once this first one is done it would be trivial to swap it for the YubikeyOTP PAM library.

However we will need to review the code, attack surface is fairly small, protocol is public and well documented. Are you happy for this to run in Dom0?

 

Joanna, any doc or other implementation to "copy" from for the qrexec client/server?

 

Note on Yubikey: Proper implementation should require 2 OTP at a defined random interval. This is to prevent for the case of a Yubikey OTP being collected on another system (i.e. while you log-in to a web-site at a friends place while your Qubes Laptop is somewhere else and being attacked) replaying at the exact same time the OTP on your Qubes system. The attacker would need to collect 2 OTP at the same time interval. Yubikey frequency is 8Hz.

Yubikey must be configured to not allow the double [TAB] key to generate OTP.

 

[Axon]

Joanna Rutkowska:

Doesn't the fact that the usbvm is untrusted entail that an attacker
could easily learn the OTP from the usbvm? If so, then how does
requiring the OTP meaningfully enhance security? Am I missing something?

[Joanna Rutkowska]

The OTP verification should be done in Dom0. The software in usbvm only
receives the OTP from the token and pipes it to Dom0 via qrexec service.

If the OTP gets sniffed (by a malcious usbvm), then, well it can only be
used for this very login (and probably within a certain timeframe only),
which doesn't give much to the attacker. After all this is the whole
idea behind OTP, no?

joanna.

[Axon]

Jonathan Miller:

"Motivated" and "determined" are relative terms in this context. If your
attacker were truly motivated and determined, he would just take your
computer and use a cold boot attack to learn the disk encryption keys
(thereby circumventing any multi-factor authentication scheme you've set
up).

[Joanna Rutkowska]

If one uses their Qubes-login USB token to "log-in to a web-site at a
friends place", then this person is just asking to be 0wned. And should
be! Certain amount of stupidity cannot be workaround. It's just like
using the same password for different services.

joanna.

[Joanna Rutkowska]

This thread has now been moved to qubes-devel list. Please do not
respond here.

j.

[Axon]

Joanna Rutkowska:

What prevents an attacker who owns your usbvm from feeding his own OTP
to dom0?

> If the OTP gets sniffed (by a malcious usbvm), then, well it can only be
> used for this very login (and probably within a certain timeframe only),
> which doesn't give much to the attacker. After all this is the whole
> idea behind OTP, no?

"This very login" is all the attacker needs. Gaining access to dom0 a
single time is sufficient to own it forever (without the real owner even
knowing it).

>
> joanna.
>

[Joanna Rutkowska]

But the attacker doesn't know how to generate a valid OTP (=One Time
Password), without having the original token...

>> If the OTP gets sniffed (by a malcious usbvm), then, well it can only be
>> used for this very login (and probably within a certain timeframe only),
>> which doesn't give much to the attacker. After all this is the whole
>> idea behind OTP, no?
>
> "This very login" is all the attacker needs. Gaining access to dom0 a
> single time is sufficient to own it forever (without the real owner even
> knowing it).
>

Yeah, but this can happen only if a proper USB token got inserted (and
optimally, additional short password entered in Dom0), and this is
exactly the use model for the security OTP tokens, right? So, if the
attacker steals your token (and optionally: also knows your short
password), then the attacker always would be able to log in, no matter
if usbvm was used or not).

j.

[Axon]

Joanna Rutkowska:

I sent my reply before I received this message. I have re-sent my reply
on qubes-devel.

[Joanna Rutkowska]

Don't reply here anymore! :)