Skip to main content

Restricting su Access to System and Shared Accounts

This chapter shows how to restrict people from su-ing to system and shared accounts even if they know the passwords.
Example for Restricting su Access to root
Create a new group for each set of users that are allowed to su to the root
# groupadd rootmembers
Add all users who are allowed to su to the root account to the new member groups created above.
The following requirement will be configured:
- Only the user named hari should be able to su to root
# usermod -G rootmembers hari
Next add the three authentication lines highlighted in bold to the /etc/pam.d/su file as shown below:
auth sufficient /lib/security/$ISA/
auth required /lib/security/$ISA/ service=system-auth
auth sufficient /lib/security/$ISA/ service=su-root-members
auth required /lib/security/$ISA/
account required /lib/security/$ISA/ service=system-auth
password required /lib/security/$ISA/ service=system-auth
session required /lib/security/$ISA/ close
session required /lib/security/$ISA/ service=system-auth
session required /lib/security/$ISA/ open multiple
session optional /lib/security/$ISA/

These additional authentication lines specify that nobody should be able to su to any account unless at least one of the PAM services or su-root-members returns
Success. The control flag sufficient means that a Success will bypass the remaining
authentication modules and overall Success is returned for the authentication part. Failure means that the failed authentication PAM service is ignored. If both authentication PAM services fail, then the last authentication module pam_deny is invoked which will deny all requests for any available authentication module. This will cause the authentication part to fail for the su command.

Next the new authentication PAM service configuration file /etc/pam.d/su-root-members needs to be created. The file /etc/pam.d/su-root-members referenced in /etc/pam.d/su should read like:

auth required /lib/security/ use_uid group=rootmembers
auth required /lib/security/ item=user sense=allow onerr=fail

The file /etc/security/su-rootmembers-access referenced in /etc/pam.d/su-root-members should read like:
# cat /etc/security/su-rootmembers-access

The control flag required which is specified for both modules means that both modules have to return Success. Otherwise this PAM service will return Failure to the "su" PAM service configured in /etc/pam.d/su. The first line returns Success only if the user is in the rootmembers groups.
second line allows only access (sense=allow) to those users specified in
/etc/security/rootusername, which is root, oracle, and postgres - these are the only users that will be accepted as a user argument to su. The item=user argument instructs pam_listfile that the entries in /etc/security/rootusername are usernames. If an error occurs, such as an unreadable configuration file, access is denied (onerr=fail).
NOTE: Once su access to root is working for users in the rootmembers, I recommend to avoid making any changes to the /etc/pam.d/su-root-members file in the future. Making a mistake in this file could revoke access to root for all users on the system. That's the reason why I created two PAM service files, /etc/pam.d/su-root-members for people in the rootmembers group, and /etc/pam.d/su-other-members (see below) for all other member groups since you will most probably add more member groups to this file in the future.
Now verify that user hari can su to root. No one else on the system should be able su to root even if they know the password.


Popular posts from this blog

Check remote UDP connectivity from Linux

Hi there, You all know how to check TCP port connectivity from a Linux or UNIX machine to a remote machine using telnet as per th example below $ telnet 25 but we can't adopt TELNET to check UDP connectivity. Linux and most of the UNIXes come with a network layer utility called nc (abbreviation for netcat) which is very useful to check UDP connectivity and to explore a lot with both TCP and UDP. An example is shown below # nc -v -u -z -w 3 123 Connection to 123 port [udp/ntp] succeeded!

The best putty package available

Bored of Black screened Task bar filling putty? Issues with porting Saved sessions from machine to machine? Do you like tabbed SSH sessions? Start using portaputty instead of normal putty and link it with puttycm . Puttycm supports sessions to be saved in its own Database files. You can use the Putty sessions you have saved already right inside putty. You can have any number of databases which allow you to arrange Remote servers in folders and convenient namings. I personally recommend creating Database with puttycm rather than using the sessions saved in putty which doesn't offer any option to create folders and saving sessions under that directory tree. You can even save username/password to get it logged automatically and there is an option to pass commands to be run soon after login. I can't recommend this since some bug was found with these options. Portaputty is a variant of putty which stores all the Configuration data in text files instead of MS Window

#!/usr/bin/env bash ## Ping all machines in a Network PING="$(which ping) -c 1 -W 1" echo "Enter Subnet(eg:192.168.0)" read Subnet echo "Do you want to PING the entire network or a RANGE of IPs ? Enter your choice" echo 1. Ping Entire Network echo 2. Ping a RANGE read choice if [ $choice = 1 ]; then { echo Pinging..... for((i=1;i<255;i++)); do ${PING} ${Subnet}.${i} > /dev/null 2> /dev/null if [ $? -eq 0 ]; then echo -e "${Subnet}.${i} is up" fi done } fi if [ $choice = 2 ]; then { echo Enter the Starting IP of Range read a echo Enter the Last IP of Range read b echo Pinging..... for((i=$a;i<$b;i++)); do ${PING} ${Subnet}.${i} > /dev/null 2> /dev/null if [ $? -eq 0 ]; then echo -e "${Subnet}.${i} is up" fi done } fi exit 0