fix, forbid non-root users using 'su'

[adrelanos]

fix, forbid non-root users using 'su'

(this changes nothing related to Qubes default passwordless sudo)

port to /usr/share/pam-configs

QubesOS/qubes-issues#1128 (comment)

Untested.

[codecov-io]

Codecov Report

Merging #171 into master will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master     #171   +/-   ##
=======================================
  Coverage   65.48%   65.48%           
=======================================
  Files           2        2           
  Lines         394      394           
=======================================
  Hits          258      258           
  Misses        136      136

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update da3c22b...2856396. Read the comment docs.

[adrelanos]

QubesOS/qubes-issues#1128 (comment)

[adrelanos]

Can you make file misc/passwordless end up in package qubes-core-agent-passwordless-root as /usr/share/pam-configs/passwordless?

It belongs into package qubes-core-agent-passwordless-root rather than qubes-core-agent-linux.

[marmarek]

Can you make file misc/passwordless end up in package qubes-core-agent-passwordless-root as /usr/share/pam-configs/passwordless?

It's enough to add it to debian/qubes-core-agent-passwordless-root.install. Note that right now, the package build fails, because this file isn't mentioned by any debian/*.install.

But even with the above handled, this behaves strangely:

• su - from user logged in xl console works - switches to root without password prompt
• su - from user on xterm/gnome-terminal prompts for the password

I don't see why it's happening.

[adrelanos]

With or without package security-misc installed? security-misc has higher priority. This interaction isn't perfectly sorted out yet. Perhaps qubes-core-agent-passwordless-root should have higher priority. Just now tested again to comment out "auth sufficient pam_permit.so" from /etc/pam.d/su, to add file "passwordless" to /usr/share/pam-configs/passwordless and then to run `sudo pam-auth-update --package". Works both for me.

[marmarek]

Without security-misc. I think I know what is going on here:
According to logs, pam_wheel deny any of those attempts, because user is not a member of sudo group. What works, is qubes-core-agent-passwordless-root package setting root's password to empty. Then pam_unix.so line has nullok_secure option, which accepts empty password only on terminal listed in /etc/securetty (which happen to include hvc0, but not pts/*).

[marmarek]

What about using auth sufficient pam_listfile.so item=tty sense=allow file=/etc/security/passwordless-tty.conf and /etc/security/passwordless-tty.conf containing just hvc0 (and maybe tty1?)?

This would allow passwordless login on xl console to any user (including root and user), without setting empty password. Should also not interfere with qubes-core-agent-linux-passwordless-root package (or lack of it).

[marmarek]

On the other hand, it will allow anything running on hvc0 to use this passwordless auth. For example if you login as user there, then you can su - to root without being asked for the password. But not on other consoles. Also, I think you can't easily delegate it elsewhere - for example if you use screen or tmux, a session inside won't have this property.

[adrelanos]

On the other hand, it will allow anything running on hvc0 to use this passwordless auth. For example if you login as user there, then you can su - to root without being asked for the password.

That would make package qubes-core-agent-passwordless-root (somewhat) superfluous and going against QubesOS/qubes-issues#2695.

Not great but may be better then the very bad implementation right now that any non-root user is allowed to use su as a temporary solution if we cannot think of a proper solution and/or move towards QubesOS/qubes-issues#2695.

My end goal is purging qubes-core-agent-passwordless-root + QubesOS/qubes-issues#2695 + DispVM and/or Qubes-VM-Hardening for strong linux user account based isolation.

[marmarek]

This is handled in #228