Disable su/sudo access unless sudo explicitly enabled for a specific user using GRANT_SUDO.

[GrahamDumpleton]

This is a follow up to the PR #654.

That prior PR was intended to lock down a very specific corner case where the notebook images were run as an arbitrary user which had no user ID in the /etc/passwd.

In that situation, the user would run with group ID of 0, since there also was no group for the unknown user ID. The prior PR removed the write access to /etc/group that had previously been added for group ID of 0 to prevent them from adding themselves to any groups, and requiring a user be in wheel group in order to run su. This was to prevent a user adding a password hash into /etc/passwd for root and then using su to become root.

What has been overlooked in the prior PR, is that a user could change the primary group in /etc/passwd and still add themselves to the wheel group.

There is also a further problem with being able to update the group. That is that a user could change their primary group to sudo or admin and then run sudo if they add a password has to /etc/passwd file for themselves.

This PR does a couple of things to lock this down further.

The first is that instead of requiring users be in wheel group to use su, the ability to use su is blocked outright for anyone but root. This is achieved by dropping from /etc/pam.d/su:

auth required pam_wheel.so use_uid

and adding instead:

auth requisite pam_deny.so

This means that the only auth that can apply is:

# This allows root to su without passwords (normal operation)
auth       sufficient pam_rootok.so

That is only root can use su.

The second change is to /etc/sudoers and disables sudo for people in sudo or admin groups. This is done by commenting out the lines:

# Members of the admin group may gain root privileges
#%admin ALL=(ALL) ALL

# Allow members of group sudo to execute any command
#%sudo	ALL=(ALL:ALL) ALL

Although this is done, it doesn't conflict with GRANT_SUDO because when that is used the /etc/sudoers.d/notebook file is created containing:

jovyan ALL=(ALL) NOPASSWD:ALL

which is configuring sudo access for jovyan.

Further, the changes don't block a user when GRANT_SUDO is being used from running:

sudo su -

as after the sudo, the su command is being run as root.

All up, this locks down ability to become root for the corner case when arbitrary user ID is used, but shouldn't stop GRANT_SUDO working. It is not believed there are other ways of becoming root than GRANT_SUDO.

Note that these changes are an extra level of protection. Under normal use, running as an arbitrary user ID wouldn't usually be done. The one case known of where it is done is when deploying to OpenShift, but in that case, Linux capabilities for SETUID and SETGID are also dropped, so you couldn't become root anyway even before this change to lock things down further.

Thanks go to @javabrett who raised the issue via #560 (comment) that this PR addresses, and testing the solution.

[parente]

Thanks for the explanation and continued work to tweak these images for the better.

The build failure is unrelated. Let's get this merged.