Restrict root access

Development
,
32
1 Like
33
1 Like
34

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
35

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

1 Like
36

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

1 Like
37

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
38
2 Likes
39
1 Like
40

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
41

Yes, that works fine.

Group root is created by default.

I think we should just leave it as is and not add the user to the root group. I don’t see any reason why they should be able to use su instead of just using sudo.

1 Like
42

Please review:

New wiki page:

Indeed.

Reasons for making su work:

  • less things broken by default.
  • if sudo is broken, one can recover using su? (Otherwise the only option would be to boot into single user / recovery mode?)

Reasons against making su work:

  • attack surface su vs sudo? But also not really since one could still use sudo su?
1 Like
43

The root account will be locked so the user can’t use su to login to the root account. Unless the user is using su to switch to system accounts which is unlikely, nothing more will be broken.

Probably not since the root account is locked.

su requires the account you’re logging into’s password rather than sudo su which just requires the user’s password. If there is a weak password for other accounts but a strong one for the user account, an attacker can easily login to other accounts without needing to know the user’s password (the strong one).

1 Like
44

Makes a lot sense. Removed group=sudo.

2 Likes
45

Reverted above commit. Reasons:

As it was before, there was no more way to run commands as root. sudo something was broken. This is because of the way it is implemented now. Which is no longer editing /etc/pam.d/su (bad as explained above) but /usr/share/pam-configs/ (standard conform) mechanism. Therefore auth required pam_wheel.so debug does not only apply to su but any file using /etc/pam.d/common-auth which includes sudo.

In result members of the group sudo will be able to use both, su and sudo.

2 Likes
46

How to boot into recovery (single user) mode is now documented: Recovery - Kicksecure

The issue with locking and expiring root account is, that it breaks recovery mode.

Cannot open access to console, the root account is locked.
See sulogin(8) man page for more details.

Solution: passwordless recovery console
References:

One could argue this is insecure in very special situations (such as kios mode or without FDE) (see references above) but I think the balance locked/expired root account in regular boot mode and functional recovery mode is more important. Recovery mode on real hardware can still be secured by using some of the following combinations: BIOS password protection; grub password protection; FDE.

Expired root password breaks lxsu but not lxsudo which is ok.

When locking root account, when trying to login as root at virtual console will say:

Login incorrect.

Without previously asking for a password. This is not the worst case for usability. Better than asking for password and then failing. Will update /etc/issue.whonix to document this.

2 Likes
47

That’s weird. This might work:

su auth required pam_wheel.so
48

pam-configs doesn’t seem to work for me. I’m not being restricted at all but editing /etc/pam.d/su does work.

I don’t know if I’ve done something wrong or not.

49

Did you make a new build and install of the security-misc package? It should automate everything. (No package uninstallation required.)

/usr/share/pam-configs do not work on its own. That folder is ignored by pam. Running with root rights pam-auth-update --package is required. This is done in security-misc postinst.

A new line

auth        required        pam_wheel.so debug group=sudo

will be added in /etc/pam.d/common-auth.

Could you please put /etc/pam.d under (git) version control and/or share /etc/pam.d/common-auth?

The package is in the developers repository (among other packages which are not fully tested yet).

1 Like
50

madaidan via Whonix Forum:

That’s weird. This might work:

su auth required pam_wheel.so

Doesn’t work. To be expected. The syntax of usr/share/pam-configs/
goes like this:

Auth:
	required	pam_wheel.so debug group=sudo

Source code of pam-auth-update looks like it only edits
/usr/share/pam/common-* files.

1 Like
51

Not sure root account locking / expiration (either or both) is a good idea yet.

This is happening during boot (sanity test).

sudo --non-interactive -u root echo 'This is a test echo.'

sudo: unable to resolve host host: No address associated with hostname
sudo: account validation failure, is your account locked?

Either root account locking and/or root account expiration is the cause of this.

In other words, root can probably no longer run sudo -u root something. Might also be a non-issue.

(“sudo: unable to resolve host host: No address associated with hostname” very most likely non-issue - happening a lot during build without issue.)

1 Like