Git-Mirrors/Qubes-Community-Content
1
0
Fork 0
mirror of https://github.com/Qubes-Community/Contents.git synced 2024-09-21 08:15:42 +00:00
Code Issues Packages Projects Releases Wiki Activity

Move core user docs back to appropriate sections; fix VM sudo title

Browse Source 
Minor spelling fix in VM sudo title and headings.

Requested by: https://github.com/QubesOS/qubes-doc/pull/823#issuecomment-496316322
Related to: QubesOS/qubes-issues#4693
This commit is contained in:
Andrew David Wong 2019-05-27 18:17:31 -05:00
parent ba479608f5
commit f3cc791460
3 changed files with 0 additions and 409 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

72
security-guides/device-handling-security.md
View File

@ -1,72 +0,0 @@
---
layout: doc
title: Device Handling Security
permalink: /doc/device-handling-security/
---
# Device Handling Security #
Any additional ability a VM gains is additional attack surface. It's a good idea to always attach the minimum entity required in a VM.
For example, attaching a full USB-device offers [more attack surface than attaching a single block device][USB security], while
attaching a full block device (e.g. `sda`) again offers more attack surface than attaching a single partition (e.g. `sda1`), since the targetVM doesn't have to parse the partition-table.
(Attaching a full block device offers the advantage that most file-managers will mount and display them correctly, whereas they don't expect single partitions to be added and therefore don't handle them correctly.)
## PCI Security ##
Attaching a PCI device to a qube has serious security implications. It exposes the device driver running in the qube to an external device (and sourceVM, which contains the device - e.g. `sys-usb`). In many cases a malicious device can choose what driver will be loaded (for example by manipulating device metadata like vendor and product identifiers) - even if the intended driver is sufficiently secure, the device may try to attack a different, less secure driver.
Furthermore that VM has full control of the device and may be able to exploit bugs or malicious implementation of the hardware, as well as plain security problems the hardware may pose. (For example, if you attach a USB controller, all the security implications of USB passthrough apply as well.)
By default, Qubes requires any PCI device to be resettable from the outside (i.e. via the hypervisor), which completely reinitialises the device. This ensures that any device that was attached to a compromised VM, even if that VM was able to use bugs in the PCI device to inject malicious code, can be trusted again. (Or at least as trusted as it was when Qubes booted.)
Some devices do not implement a reset option. In these cases, Qubes by default does not allow attaching the device to any VM. If you decide to override this precaution, beware that the device may only be trusted when attached to the first VM. Afterwards, it should be **considered tainted** until the whole system is shut down. Even without malicious intent, usage data may be leaked.
In case device reset is disabled for any reason, detaching the device should be considered a risk. Ideally, devices for which the `no-strict-reset` option is set are attached once to a VM which isn't shut down until the system is shut down.
Additionally, Qubes restricts the config-space a VM may use to communicate with a PCI device. Only whitelisted registers are accessible. However, some devices or applications require full PCI access. In these cases, the whole config-space may be allowed. you're potentially weakening the device isolation, especially if your system is not equipped with a VT-d Interrupt Remapping unit. This increases the VM's ability to run a [side channel attack] and vulnerability to the same.
See [Xen PCI Passthrough: PV guests and PCI quirks] and [Software Attacks on Intel VT-d] \(page 7) for more details.
## USB Security ##
The connection of an untrusted USB device to dom0 is a security risk since the device can attack an arbitrary USB driver (which are included in the linux kernel), exploit bugs during partition-table-parsing or simply pretend to be a keyboard. There are many ready-to-use implementations of such attacks, e.g. a [USB Rubber Ducky][rubber duck].
The whole USB stack is put to work to parse the data presented by the USB device in order to determine if it is a USB mass storage device, to read its configuration, etc.
This happens even if the drive is then assigned and mounted in another qube.
To avoid this risk, use a [USB qube].
Attaching a USB device to a VM (USB passthrough) will **expose your target qube** to most of the [security issues][USB security] associated with the USB-stack.
If possible, use a method specific for particular device type (for example, block devices described above), instead of this generic one.
## Security Warning On USB Input Devices
If you connect USB input devices (keyboard and mouse) to a VM, that VM will effectively have control over your system.
Because of this, the benefits of using a [USB qube] entrusted with a keyboard or other interface device are much smaller than using a fully untrusted USB qube.
In addition to having control over your system, such a VM can also sniff all the input you enter there (for example, passwords in the case of a USB keyboard).
There is no simple way to protect against sniffing, but you can make it harder to exploit control over input devices.
If you have only a USB mouse connected to a USB qube, but the keyboard is connected directly to dom0 (using a PS/2 connector, for example), you simply need to lock the screen when you are away from your computer.
You must do this every time you leave your computer unattended, even if there no risk of anyone else having direct physical access to your computer.
This is because you are guarding the system not only against anyone with local access, but also against possible actions from a potentially compromised USB qube.
If your keyboard is also connected to a USB qube, things are much harder.
Locking the screen (with a traditional password) does not solve the problem, because the USB qube can simply sniff this password and later easily unlock the screen.
One possibility is to set up the screen locker to require an additional step to unlock (i.e., two-factor authentication).
One way to achieve this is to use a [YubiKey], or some other hardware token, or even to manually enter a one-time password.
Support for [two factor authentication][qubes u2f proxy] was recently added, though there are [issues][4661].
[USB security]:https://blog.invisiblethings.org/2011/05/31/usb-security-challenges.html "ITL blog post on USB security"
[rubber duck]: https://shop.hak5.org/products/usb-rubber-ducky-deluxe
[USB qube]: /doc/usb-qubes/
[YubiKey]: /doc/YubiKey/
[qubes u2f proxy]: https://www.qubes-os.org/news/2018/09/11/qubes-u2f-proxy/
[4661]: https://github.com/QubesOS/qubes-issues/issues/4661
[side channel attack]: https://en.wikipedia.org/wiki/Side-channel_attack
[Xen PCI Passthrough: PV guests and PCI quirks]: https://wiki.xenproject.org/wiki/Xen_PCI_Passthrough#PV_guests_and_PCI_quirks
[Software Attacks on Intel VT-d]: https://invisiblethingslab.com/resources/2011/Software%20Attacks%20on%20Intel%20VT-d.pdf

160
security-guides/vm-sudo.md
View File

@ -1,160 +0,0 @@
---
layout: doc
title: VM Sudo
permalink: /doc/vm-sudo/
redirect_from:
- /en/doc/vm-sudo/
- /doc/VMSudo/
- /wiki/VMSudo/
---
Password-less root access in VM
===============================
Background ([/etc/sudoers.d/qubes](https://github.com/QubesOS/qubes-core-agent-linux/blob/master/misc/qubes.sudoers) in VM):
user ALL=(ALL) NOPASSWD: ALL
# WTF?! Have you lost your mind?!
#
# In Qubes VMs there is no point in isolating the root account from
# the user account. This is because all the user data is already
# accessible from the user account, so there is no direct benefit for
# the attacker if she could escalate to root (there is even no benefit
# in trying to install some persistent rootkits, as the VM's root
# filesystem modifications are lost upon each start of a VM).
#
# One might argue that some hypothetical attacks against the
# hypervisor or the few daemons/backends in Dom0 (so VM escape
# attacks) most likely would require root access in the VM to trigger
# the attack.
#
# That's true, but mere existence of such a bug in the hypervisor or
# Dom0 that could be exploited by a malicious VM, no matter whether
# requiring user, root, or even kernel access in the VM, would be
# FATAL. In such situation (if there was such a bug in Xen) there
# really is no comforting that: "oh, but the mitigating factor was
# that the attacker needed root in VM!" We're not M$, and we're not
# gonna BS our users that there are mitigating factors in that case,
# and for sure, root/user isolation is not a mitigating factor.
#
# Because, really, if somebody could find and exploit a bug in the Xen
# hypervisor -- as of 2016, there have been only three publicly disclosed
# exploitable bugs in the Xen hypervisor from a VM -- then it would be
# incidentally by one of the Qubes developers (RW) -- then it would be
# highly unlikely if that person couldn't also found a user-to-root
# escalation in VM (which as we know from history of UNIX/Linux
# happens all the time).
#
# At the same time allowing for easy user-to-root escalation in a VM
# is simply convenient for users, especially for update installation.
#
# Currently this still doesn't work as expected, because some idotic
# piece of software called PolKit uses own set of policies. We're
# planning to address this in Beta 2. (Why PolKit is an idiocy? Do a
# simple experiment: start 'xinput test' in one xterm, running as
# user, then open some app that uses PolKit and asks for root
# password, e.g. gpk-update-viewer -- observe how all the keystrokes
# with root password you enter into the "secure" PolKit dialog box can
# be seen by the xinput program...)
#
# joanna.
Below is a complete list of configuration made according to the above statement, with (not necessary complete) list of mechanisms depending on each of them:
1. sudo (/etc/sudoers.d/qubes):
user ALL=(ALL) NOPASSWD: ALL
(...)
- easy user->root access (main option for the user)
- qvm-usb (not really working, as of R2)
2. PolicyKit (/etc/polkit-1/rules.d/00-qubes-allow-all.rules):
//allow any action, detailed reasoning in sudoers.d/qubes
polkit.addRule(function(action,subject) { return polkit.Result.YES; });
and /etc/polkit-1/localauthority/50-local.d/qubes-allow-all.pkla:
[Qubes allow all]
Identity=*
Action=*
ResultAny=yes
ResultInactive=yes
ResultActive=yes
- NetworkManager configuration from normal user (nm-applet)
- updates installation (gpk-update-viewer)
- user can use pkexec just like sudo Note: above is needed mostly because Qubes user GUI session isn't treated by PolicyKit/logind as "local" session because of the way in which X server and session is started. Perhaps we will address this issue in the future, but this is really low priority. Patches welcomed anyway.
3. Empty root password
- used for access to 'root' account from text console (xl console) - the only way to access the VM when GUI isn't working
- can be used for easy 'su -' from user to root
Replacing password-less root access with Dom0 user prompt
---------------------------------------------------------
While ITL supports the statement above, some Qubes users may wish to enable
user/root isolation in VMs anyway. We do not support it in any of our packages,
but of course nothing is preventing the user from modifying his or her own
system. A list of steps to do so is provided here **without any guarantee of
safety, accuracy, or completeness. Proceed at your own risk. Do not rely on
this for extra security.**
1. Adding Dom0 "VMAuth" service:
[root@dom0 /]# echo "/usr/bin/echo 1" >/etc/qubes-rpc/qubes.VMAuth
[root@dom0 /]# echo "\$anyvm dom0 ask,default_target=dom0" \
>/etc/qubes-rpc/policy/qubes.VMAuth
(Note: any VMs you would like still to have password-less root access (e.g. TemplateVMs) can be specified in the second file with "\<vmname\> dom0 allow")
2. Configuring Fedora TemplateVM to prompt Dom0 for any authorization request:
- In /etc/pam.d/system-auth, replace all lines beginning with "auth" with these lines:
auth [success=1 default=ignore] pam_exec.so seteuid /usr/lib/qubes/qrexec-client-vm dom0 qubes.VMAuth /bin/grep -q ^1$
auth requisite pam_deny.so
auth required pam_permit.so
- Require authentication for sudo. Replace the first line of /etc/sudoers.d/qubes with:
user ALL=(ALL) ALL
- Disable PolKit's default-allow behavior:
[root@fedora-20-x64]# rm /etc/polkit-1/rules.d/00-qubes-allow-all.rules
[root@fedora-20-x64]# rm /etc/polkit-1/localauthority/50-local.d/qubes-allow-all.pkla
3. Configuring Debian/Whonix TemplateVM to prompt Dom0 for any authorization request:
- In /etc/pam.d/common-auth, replace all lines beginning with "auth" with these lines:
auth [success=1 default=ignore] pam_exec.so seteuid /usr/lib/qubes/qrexec-client-vm dom0 qubes.VMAuth /bin/grep -q ^1$
auth requisite pam_deny.so
auth required pam_permit.so
- Require authentication for sudo. Replace the first line of /etc/sudoers.d/qubes with:
user ALL=(ALL) ALL
- Disable PolKit's default-allow behavior:
[root@debian-8]# rm /etc/polkit-1/rules.d/00-qubes-allow-all.rules
[root@debian-8]# rm /etc/polkit-1/localauthority/50-local.d/qubes-allow-all.pkla
- In /etc/pam.d/su.qubes, comment out this line near the bottom of the file:
auth sufficient pam_permit.so
- For Whonix, if prompts appear during boot, create /etc/sudoers.d/zz99 and add these lines:
ALL ALL=NOPASSWD: /usr/sbin/virt-what
ALL ALL=NOPASSWD: /usr/sbin/service whonixcheck restart
ALL ALL=NOPASSWD: /usr/sbin/service whonixcheck start
ALL ALL=NOPASSWD: /usr/sbin/service whonixcheck stop
ALL ALL=NOPASSWD: /usr/sbin/service whonixcheck status
Dom0 password-less root access
------------------------------
There is also password-less user->root access in dom0. As stated in comment in sudo configuration there (different one than VMs one), there is really no point in user/root isolation, because all the user data (and VM management interface) is already accessible from dom0 user level, so there is nothing more to get from dom0 root account.

177
security-guides/yubi-key.md
View File

@ -1,177 +0,0 @@
---
layout: doc
title: YubiKey in Qubes
permalink: /doc/yubi-key/
redirect_from:
- /en/doc/yubi-key/
- /doc/YubiKey/
---
Using YubiKey to Qubes authentication
=====================================
You can use YubiKey to enhance Qubes user authentication, for example to mitigate
risk of snooping the password. This can also slightly improve security when you have [USB keyboard](/doc/device-handling-security/#security-warning-on-usb-input-devices).
There (at least) two possible configurations: using OTP mode and using challenge-response mode.
OTP mode
--------
This can be configured using
[app-linux-yubikey](https://github.com/adubois/qubes-app-linux-yubikey)
package. This package does not support sharing the same key slot with other
applications (it will deny further authentications if you try).
Contrary to instruction there, currently there is no binary package in the Qubes
repository and you need to compile it yourself. This might change in the future.
Challenge-response mode
----------------------
In this mode, your YubiKey will generate a response based on the secret key, and
random challenge (instead of counter). This means that it isn't possible to
generate a response in advance even if someone gets access to your YubiKey. This
makes it reasonably safe to use the same YubiKey for other services (also in
challenge-response mode).
Same as in the OTP case, you will need to set up your YubiKey, choose a separate
password (other than your login password!) and apply the configuration.
To use this mode you need to:
1. Install yubikey personalization the packages in your TemplateVM on which your USB VM is based.
For Fedora.
sudo dnf install ykpers yubikey-personalization-gui
For Debian.
sudo apt-get install yubikey-personalization yubikey-personalization-gui
Shut down your TemplateVM. Then reboot your USB VM (so changes inside the TemplateVM take effect
in your TemplateBased USB VM or install the packages inside your USB VM if you would like to avoid
rebooting your USB VM.
2. Configure your YubiKey for challenge-response `HMAC-SHA1` mode, for example
[following this
tutorial](https://www.yubico.com/products/services-software/personalization-tools/challenge-response/).
On Debian, you can run the graphical user interface `yubikey-personalization-gui` from the command line.
- Choose `configuration slot 2`.
- It is recommended to enable `Require user input (button press)` but this is optional.
- Note: Different from the above video, use the following settings select
`HMAC-SHA1 mode`: `fixed 64 bit input`.
- We will refer the `Secret Key (20 bytes hex)` as `AESKEY`.
- It is recommended to keep a backup of your `AESKEY` in an offline VM used as vault.
- Consider to keep a backup of your `AESKEY` on paper and store it in a safe place.
- In case you have multiple YubiKeys for backup purposes (in case a yubikey gets lost, stolen or breaks) you can write the same settings into other YubiKeys.
3. Install [qubes-app-yubikey](https://github.com/QubesOS/qubes-app-yubikey) in dom0.
sudo qubes-dom0-update qubes-yubikey-dom0
4. Adjust USB VM name in case you are using something other than the default
`sys-usb` by editing `/etc/qubes/yk-keys/yk-vm` in dom0.
5. Paste your `AESKEY` from step 2 into `/etc/qubes/yk-keys/yk-secret-key.hex` in dom0.
6. Paste your hashed password (other than your standard Qubes password) into
`/etc/qubes/yk-keys/yk-login-pass-hashed.hex` in dom0.
You can calculate your hashed password using the following two commands.
First run the following command to store your password in a temporary variable `password`.
(This way your password will not leak to the terminal command history file.)
read password
Now run the following command to calculate your hashed password.
echo -n "$password" | openssl dgst -sha1
7. Edit `/etc/pam.d/login` in dom0. Add this line at the beginning:
auth include yubikey
8. Edit `/etc/pam.d/xscreensaver` (or appropriate file if you are using other
screen locker program) in dom0. Add this line at the beginning:
auth include yubikey
9. Edit `/etc/pam.d/lightdm` (or appropriate file if you are using other
display manager) in dom0. Add this line at the beginning:
auth include yubikey
### Usage
When you want to unlock your screen...
1) Plug YubiKey into USB slot.
2) Enter password associated with YubiKey.
3) Press Enter.
4) If you configured so, YubiKey will request confirmation by pressing button on it (it will blink).
When everything is ok, your screen will be unlocked.
In any case you can still use your login password, but do it in a secure location
where no one can snoop your password.
### Mandatory YubiKey Login
Edit `/etc/pam.d/yubikey` (or appropriate file if you are using other screen locker program)
and remove `default=ignore` so the line looks like this.
auth [success=done] pam_exec.so expose_authtok quiet /usr/bin/yk-auth
Locking the screen when YubiKey is removed
------------------------------------------
You can setup your system to automatically lock the screen when you unplug your
YubiKey. This will require creating a simple qrexec service which will expose
the ability to lock the screen to your USB VM, and then adding a udev hook to
actually call that service.
In dom0:
1. First configure the qrexec service. Create `/etc/qubes-rpc/custom.LockScreen`
with a simple command to lock the screen. In the case of xscreensaver (used in Xfce)
it would be:
DISPLAY=:0 xscreensaver-command -lock
2. Allow your USB VM to call that service. Assuming that it's named `sys-usb` it
would require creating `/etc/qubes-rpc/policy/custom.LockScreen` with:
sys-usb dom0 allow
In your USB VM:
3. Create udev hook. Store it in `/rw/config` to have it
persist across VM restarts. For example name the file
`/rw/config/yubikey.rules`. Add the following line:
ACTION=="remove", SUBSYSTEM=="usb", ENV{ID_SECURITY_TOKEN}=="1", RUN+="/usr/bin/qrexec-client-vm dom0 custom.LockScreen"
4. Ensure that the udev hook is placed in the right place after VM restart. Append to `/rw/config/rc.local`:
ln -s /rw/config/yubikey.rules /etc/udev/rules.d/
udevadm control --reload
5. Then make `/rw/config/rc.local` executable.
sudo chmod +x /rw/config/rc.local
6. For changes to take effect, you need to call this script manually for the first time.
sudo /rw/config/rc.local
If you use KDE, the command(s) in first step would be different:
# In the case of USB VM being autostarted, it will not have direct access to D-Bus
# session bus, so find its address manually:
kde_pid=`pidof kdeinit4`
export `cat /proc/$kde_pid/environ|grep -ao 'DBUS_SESSION_BUS_ADDRESS=[[:graph:]]*'`
qdbus org.freedesktop.ScreenSaver /ScreenSaver Lock