|
| 1 | +# Passwordless in-qubqube admin authorization |
| 2 | + |
| 3 | +By default all users in the `qubes` group (usually only the standard `user` |
| 4 | +user) are allowed to execute things as root via sudo/su/pkexec. This is allowed |
| 5 | +without a password prompt. |
| 6 | + |
| 7 | +Separating the user isn't that meaningfull since Qubes' primary |
| 8 | +compartimentalization layer are qubes and `user` in a qube has access most |
| 9 | +things there anyway (user data, GUI I/O, etc). But some advanced users want |
| 10 | +more options therefore this mechanism has been extended. |
| 11 | + |
| 12 | +## Modes |
| 13 | + |
| 14 | +There are 3 modes: |
| 15 | + |
| 16 | + - `allow`: Always allow admin access. |
| 17 | + - `deny`: Always deny admin access. |
| 18 | + - `qrexec`: Make a qrexec call and use it's result to allow/deny. The main |
| 19 | + usage is to have a trivial qrexec service in dom0 and use the qrexex policy |
| 20 | + with the ask action to allow only after prompting. |
| 21 | + |
| 22 | +"Admin access" here means being able to run things as another user (including |
| 23 | +root), via sudo, su and polkit. This is always limited to users in the `qubes` |
| 24 | +group. |
| 25 | + |
| 26 | + |
| 27 | +## Config |
| 28 | + |
| 29 | +When the `qubes-core-agent-passwordless-root` is installed the |
| 30 | +pam_qubes_admin_authz.so is always enabled. This module asks the |
| 31 | +`qubes-admin-authzd` daemon which does the actual logic (see below for |
| 32 | +technical details). |
| 33 | + |
| 34 | +The mode can be set via /usr/local/etc/qubes/admin-authzd.conf for per-qube |
| 35 | +setting or more common via /etc/qubes/admin-authzd.conf in a template (setting |
| 36 | +in /usr/local has precendce). |
| 37 | + |
| 38 | +There config file have a very simpley syntax. The first line needs to contain |
| 39 | +one of the listed mode above without anythings else. Currently the rest of the |
| 40 | +file is ignored. Please prefix comments with `#` to allow extension of this |
| 41 | +configuration file should the need arise. |
| 42 | + |
| 43 | + |
| 44 | +## qrexec policy |
| 45 | + |
| 46 | +After setting the mode to qrexec, you need to configure the qrexec policy in |
| 47 | +dom0. For example: |
| 48 | + |
| 49 | +``` |
| 50 | +qubes.AuthorizeInVMAdminAccess * * @default ask target=dom0 default_target=dom0 |
| 51 | +``` |
| 52 | + |
| 53 | +asks for requests from any VM. |
| 54 | + |
| 55 | +Note that in dom0 only a trivial service is run that returns a fixed string |
| 56 | +such that the qube knows the result of the policy evaluation. The idea here is |
| 57 | +that this way the existing qrexec policy can be reused, including it's ask |
| 58 | +prompt. |
| 59 | + |
| 60 | + |
| 61 | +## Limitaions |
| 62 | + |
| 63 | +Keep in mind that if you have allowed admin access and the qube was compromised |
| 64 | +at that point persistence is trivial. |
| 65 | + |
| 66 | + |
| 67 | +## Technical details |
| 68 | + |
| 69 | +We implement a PAM module named `pam_qubes_admin_authz.so` to permit the |
| 70 | +access. Since PAM modules can be run in a setuid context (when called by |
| 71 | +sudo/su) we want to keep the code simple there. Therefore we use just some |
| 72 | +existing PAM helper functions to check for the requsting users group membership |
| 73 | +and check the PAM "service" (`sudo`, `su-l`, etc.) and if they match we make a |
| 74 | +connection to an abstract unix socket. With `SO_PEERCRED` we check that this |
| 75 | +socket has been opened by root. The rest, including config file handling and |
| 76 | +invoking qrexec-client-vm is then handled by the `qubes-admin-authzd` at the |
| 77 | +other end of the socket (started by qubes-admin-authzd.service). |
| 78 | + |
| 79 | +## Recovery |
| 80 | + |
| 81 | +Should you have locked you self out you should still be able to use |
| 82 | +`qvm-console-dispvm` and login as root there without a password. |
0 commit comments