Restrict root access

All. As in original post. (Hence I made an almost full quote.)
Please also document each change so those who don’t like it can reverse it.

Yes, I see no reason against that yet. user user should be able to use sudo, sudo su. When that works, not sure if “standalone” (no sudo) su is still required. Please let me know if blocking su given us further hardening under which threat model.

sudo passwd -l root and/or setting login shell to /sbin/nologin? Either, or? Or both advisable?

Where would that be implemented? In https://github.com/Whonix/anon-base-files/blob/master/debian/anon-base-files.postinst?

1 Like

Setting the login shell to /sbin/nologin won’t help much. You can still run sudo -u root bash and get shell access. We could implement both but I’m not sure how. I highly doubt there is a passwd.d.

That sounds like the best way.

1 Like

/etc/pam.d/passwd contains nothing except an include rule for /etc/pam.d/common-password so I edited that instead.

I created a pull request for all these.

2 Likes

And after that I just merged that I got a different version on my system due to another package. Contents in /etc/pam.d are influences through a mechanism using configuration drop-in folder /usr/share/pam-configs/. So config-package-dev is quite possibly the wrong approach to implement (most) of our pam changes. Could you look into this please?

1 Like

Those files have weird formatting.

user@host:~$ cat /usr/share/pam-configs/mkhomedir 
Name: Create home directory on login
Default: no
Priority: 0
Session-Type: Additional
Session-Interactive-Only: yes
Session:
	optional	pam_mkhomedir.so

There’s a section on the Ubuntu wiki that might be useful.

https://wiki.ubuntu.com/PAMConfigFrameworkSpec

I’m not sure how this could be implemented.

1 Like

There are two folders:

  • /usr/share/pam
  • /usr/share/pam-configs
1 Like

/usr/share/pam just seems to duplicate some files from /etc/pam.d and give md5 hashes of them.

1 Like

madaidan via Whonix Forum:

/usr/share/pam just seems to duplicate some files from /etc/pam.d and give md5 hashes of them.

Duplicate might be an understatement. /usr/share/pam looks to be the
template from which /etc/pam.d is build and then supplemented with
/usr/share/pam-configs.

Also /usr/sbin/pam-auth-update is involved. But also some other tool
much be involved since I did not see yet what reads from /usr/share/pam.

Our current implementation of changing /etc/pam.d directly using
config-package-dev seems really bad, breaking the usual mechanism for
populating that folder. Not fit for release since hard to later move
back to the proper mechanism, also breaking things for any user/package
using the standardized pam-auth-update mechanism.

1 Like

We could make a script that appends the needed lines to the existing files but that seems a bit hacky.

1 Like

Really hacky indeed. We first need to understand and exhaust the usual mechanism which all other pam related packages are using (as mentioned above). There are a ton of packages interacting with pam in a proper way.

https://packages.debian.org/search?suite=default&section=all&arch=any&searchon=names&keywords=libpam

2 Likes

If you look at the list of files in the packages, you can see that some of those packages are using /usr/share/pam-configs or are putting their module directly in /lib/security.

/usr/share/pam-configs seems to be the best way.

2 Likes
1 Like
1 Like

Instructions for experimentation:

Get rid of all previous modifications firsts.

Put folder /etc/pam.d under git version control (or similar) so you can see what files get changed in which way.

Get a file into folder /usr/share/pam-configs such as for example /usr/share/pam-configs/wheel into place.

Here is a link below to a version in the git history. It might be removed/updated at a later point.

To simulate what the package would do during installation:

sudo pam-auth-update --package

Or for manual experimentation:

sudo pam-auth-update

Then check which changes happened in /etc/pam.d folder using git version control or similar.


What’s happening in last commit is instead of editing /etc/pam.d/su directly, in effect /etc/pam.d/common-auth gets modified. This is the diff:

diff --git a/common-auth b/common-auth
index 1ed8786..fcaf1b3 100644
--- a/common-auth
+++ b/common-auth
@@ -14,8 +14,7 @@
 # pam-auth-update(8) for details.
 
 # here are the per-package modules (the "Primary" block)
-auth   required        pam_wheel.so 
-auth   [success=1 default=ignore]      pam_unix.so nullok_secure try_first_pass
+auth   [success=1 default=ignore]      pam_unix.so nullok_secure
 # here's the fallback if no module succeeds
 auth   requisite                       pam_deny.so
 # prime the stack with a positive return value if there isn't one already;

So the line

auth   required        pam_wheel.so 

gets added above “quite early”. Early enough?

Another important difference is that most if not all pam config files import /etc/pam.d/common-auth. So this change does not only effect /etc/pam.d/su but also sudo, login, cron, polkit-1, others. Is this ok or could cause some issues?

2 Likes

upstream bug report:
improve key strengthening, add rounds=65536 to /etc/pam.d/common-password

1 Like

Appropriate place to ask questions on how Debian derivatives would best interact with Debian’s implementation of pam?

1 Like

A clean implementation might require to config-package-dev displace /usr/share/pam-configs/unix. I don’t think it’s worth the risk of this implementation. All this does is better protect the hashed password in /etc/shadow from an attacker who got an offline copy of /etc/shadow and runs an offline cracking attack against it. Cases where this applies:

  • someone not using full disk encryption (FDE) and /etc/shadow leaked
  • broken FDE but no knowledge of root password (but also no longer by attacker required to view any file)
  • an attacker who didn’t manage to get the root password through a keylogger (unrealistic since it assumes attacker can already read /etc/shadow)
  • an attacker who thinks that the password used for linux user authentication is being used elsewhere and while having full disk access still wants to crack that password too

To add the delay against online bruteforcing we are better off using something like tally / tally2 as discussed here:

I will revert our current implementation.

After Appropriate place to ask questions on how Debian derivatives would best interact with Debian’s implementation of pam? was answered, I will ask how to cleanly implement this. Already prepared a draft for that:

How to append rounds=65536 in /etc/pam.d/common-password as a Debian derivative?

In /etc/pam.d/common-password we would like to change from

password [success=1 default=ignore] pam_unix.so obscure sha512

to

password [success=1 default=ignore] pam_unix.so obscure sha512 rounds=65536

How would we do that? Fork libpam-runtime and edit /usr/share/pam-configs/unix ? [1] [2] Or is there some more elegant solution using a /usr/share/pam-configs drop-in or so?

Kind regards,
Patrick

[1]
dpkg -S /usr/share/pam-configs/unix
libpam-runtime: /usr/share/pam-configs/unix

[2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=931994

2 Likes
2 Likes

1 Like

Restrict access to the root account by madaidan · Pull Request #22 · Kicksecure/security-misc · GitHub

auth required pam_wheel.so

I don’t think that by itself would have worked? Did you test that?

# Uncomment this to force users to be a member of group root
# before they can use `su'. You can also add "group=foo"
# to the end of this line if you want to use a group other
# than the default "root" (but this may have side effect of
# denying "root" user, unless she's a member of "foo" or explicitly
# permitted earlier by e.g. "sufficient pam_rootok.so").
# (Replaces the `SU_WHEEL_ONLY' option from login.defs)
auth       required   pam_wheel.so

So we would have had to create a group root and add user user to that group root too.

(And hopefully pam_wheel.so in Debian wouldn’t default to group wheel for historic reasons either (potential bug).)

It seems required to add group=sudo.
For debugging I’ve also added debug.

Do you think we should create group sudo and add user user to group root? I am wondering which is the better implementation?

  • More groups don’t make thing simpler for users, developers, auditors.
  • Not much point to differentiate between sudo and root nowadays, less so when we preconfigure the whole system with locked down, secure defaults?
  • Not using root group is less standard conform could be more confusing for something?
1 Like