PAM errors after disabling password-less root

[Chris Laprise]

Following the instructions for the 'vm-sudo' doc, I get the following
error in Debian 9:

/usr/lib/qubes/qrexec-client-vm failed: exit code 1
sudo: PAM authentication error: System error


Also, in the Debian 8 template the instructions don't match, as there
appears to be no file '/etc/pam.d/common-auth'.

Chris

[Unman]

Where did you get that template? The file is present in the default 3.2,
and even in a minimal-no-recommends template for Debian-8.

I'll look at the Debian-9 issue now.

[Unman]

I'm afraid I don't see this issue in a Debian-9 template.
Can you check your editing?

Also, try manually running the qrexec-client-vm dom0 qubes.VMAuth
command, and making sure you get the expected output.
You should see the prompt(from the policy) and then output from dom0.

unman

[Chris Laprise]

Thanks for checking. However, I triple-checked my editing in Debian 9
and Debian 8 template is 'stock' basically nothing added to it.

The qubes.VMAuth request said 'Request refused'. The doc appears to have
a typo for the second command in Step 1. "Adding Dom0 “VMAuth” service"
that causes '$anyvm' to disappear from the output. This line should use
single quotes instead.

Chris

[Unman]

You're right about that typo. Once you fixed it what happened?

[Chris Laprise]

It works now for Debian 9, submitted PR to fix the doc. I don't know
what the issue is with the missing file in Debian 8... The template's
basic form may not have a necessary package.

Chris

[3n7r...@gmail.com]

FWIW, the instructions work when applied to Whonix-Debian-8.

If I may piggyback on this thread with a related issue... The instructions (pre-typo) worked fine for both Fedora & Whonix VMs. But while the Fedora VMs would spin up silently, each Whonix VM required 4 sudo authorizations at each boot. Do you have any idea what that might be or how I could trace it? I don't have any user scripts / rc.local configured. The authorization requests sometimes appear while the VM light is yellow and other times won't appear until it's green. I'm worried that they might need to be clicked in the proper order and there's not enough identifying information on the dialogue to know what I'm authorizing. Would it be possible to pass the name of the triggering command to the dom0 sudo prompt?

[Andrew]

3n7r...@gmail.com:

I think not without modifying the Qubes RPC code itself, which is
probably a non-starter. Anyway you would be relying on untrusted
self-reported information in the trusted Dom0 prompt, so maybe not a
good idea.

If you just want to investigate, this should be logged on the VM itself,
anyway, no? Maybe I'm wrong. Look through journalctl and see.

Andrew

[Chris Laprise]

The typo causes the string '$anyvm dom0 ask' to be stored as ' dom0 ask'
because the shell expands $anyvm to nothing.

So its definitely a bug, IMHO.

The Whonix issue sounds like a decision they made to use sudo from a
user startup script...? I think Patrick may know which ones they are.

Chris

[entr0py]

Andrew:

Andrew, thanks for the pointers.

Chris resolved before I even looked:

https://forums.whonix.org/t/fixing-whonix-boot-issue-after-securing-qubes-root-auth/3155
https://github.com/QubesOS/qubes-doc/pull/176#issuecomment-261407737

[Chris Laprise]

On 11/18/2016 02:03 AM, entr0py wrote:
> Andrew:

>>
>> I think not without modifying the Qubes RPC code itself, which is
>> probably a non-starter. Anyway you would be relying on untrusted
>> self-reported information in the trusted Dom0 prompt, so maybe not a
>> good idea.
>>
>> If you just want to investigate, this should be logged on the VM itself,
>> anyway, no? Maybe I'm wrong. Look through journalctl and see.
>>
>> Andrew
>>
> Andrew, thanks for the pointers.
>
> Chris resolved before I even looked:
>
> https://forums.whonix.org/t/fixing-whonix-boot-issue-after-securing-qubes-root-auth/3155
> https://github.com/QubesOS/qubes-doc/pull/176#issuecomment-261407737

I ended up having one remaining prompt during sys-whonix VM startup
(based on whonix-gw template).

So the full resolution of the issue involves creating a file
'/etc/sudoers.d/zz99' in the whonix templates and adding *both* of these
lines:

ALL ALL=NOPASSWD: /usr/sbin/virt-what
ALL ALL=NOPASSWD: /usr/sbin/service whonixcheck *


Chris

[Patrick Schleizer]

Chris Laprise:

Probably related issues:
- https://github.com/QubesOS/qubes-doc/pull/176
- https://github.com/QubesOS/qubes-doc/pull/228

Which lead to some changes to https://www.qubes-os.org/doc/vm-sudo/
[which was reported to work now] (and the qubes-whonix package).

I may not work much on this issue however due to Qubes project policy,
explained in detail here:
https://github.com/QubesOS/qubes-doc/pull/176#issuecomment-242894132

Btw I almost missed this mail. As of now, best way to get my attention
btw is adding my e-mail address adre...@riseup.net or adding Whonix to
the subject. Otherwise I cannot monitor / read all on this kinda high
traffic mailing list.

Cheers,
Patrick

[Chris Laprise]

On 11/28/2016 05:27 PM, Patrick Schleizer wrote:
> Probably related issues:
> - https://github.com/QubesOS/qubes-doc/pull/176
> - https://github.com/QubesOS/qubes-doc/pull/228
>
> Which lead to some changes to https://www.qubes-os.org/doc/vm-sudo/
> [which was reported to work now] (and the qubes-whonix package).
>
> I may not work much on this issue however due to Qubes project policy,
> explained in detail here:
> https://github.com/QubesOS/qubes-doc/pull/176#issuecomment-242894132
>
> Btw I almost missed this mail. As of now, best way to get my attention
> btw is adding my e-mail address adre...@riseup.net or adding Whonix to
> the subject. Otherwise I cannot monitor / read all on this kinda high
> traffic mailing list.
>
> Cheers,
> Patrick
>

I'm having one remaining issue after restricting root in the templates...

dom0 is logging tons of PAM 'audit' messages which makes the log very
noisy. I think the auth requests are originating from dom0. I'd like to
find a way to squelch them.

Chris

[Marek Marczykowski-Górecki]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

It's a "feature" of systemd-journald:
https://github.com/systemd/systemd/issues/959

In short: add "audit=0" to VM kernel command options, or run "auditd -s
disable". Personally I have "auditd -s disable" in /rw/config/rc.local
in some (most?) VMs.

- --
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?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQEcBAEBCAAGBQJYPzypAAoJENuP0xzK19csgcQH/33ad5ho12qjUhzxI4j+1CJE
H6h+MdQXbKdgM+oYxyTsK8ET9x5ybrhkpPjnADyZP9SNcyb+IH2pI9FGZhtLpdph
5959inOLysYi1tiO/hYcUElKNQzjNFrGFBvlVNu4L25WSJT/hxueGNCDWrjF+fC6
bDO/tKt8ilCajCDnAijTp37Sk6kPIiFX+eMDafpgjli7SDhzALPo/ypc3KcCfow9
BQ19bW4WIYTOC4XTZWUDvffLvTtVZPBoHLXmW/g90GgOZXRTHeSCqLUJDi4qYbZ/
wzcFapVS02Jc5IvdfHzGwNqYj1ZAbEqAk+KnPqwJHFRjpaWpsXCm1wOrYcJvNJc=
=6dXl
-----END PGP SIGNATURE-----

[Chris Laprise]

I added 'audit=0' to my domU kernelopts, but after restarting all VMs
I'm still getting the same amount of audit lines in dmesg.

Chris

[Chris Laprise]

Would it have anything to do with upgrading to kernel 4.8 (both dom0 and
domU)?

Chris