Restricting Direct Login Access for System and Shared Accounts

On an audited production system it is very important to know who switched to which system or shared account. Therefore it is prudent to restrict direct logins for all system and shared account where more than one individual knows the password. All users should do a direct login using their own account and then switch to the system or shared account.

However, there are situations where you have to allow direct logins for system or shared accounts. For example, within an Oracle RAC cluster you have to enable direct ssh logins for oracle. But in such an environment you have to protect the whole cluster as a single entity against incoming ssh connection, i.e. direct oracle logins should not work if you come from a node that is not part of the cluster. In the following example I will show how to achieve this goal as well.

Usually all system and shared accounts have one thing in common, that is they are not in the "users" group. The following example assumes that all individual user accounts are in the "users" group but system and shared accounts like root and oracle are not. If you want to go a step further, a good solution would be to implement a new 'logingroup' users group which would require users to be given explicit access.

In this example I will show how to restrict direct logins for:

- SSH (/etc/pam.d/sshd)
- Console Login (/etc/pam.d/login)
- Graphical Gnome Login (/etc/pam.d/gdm
- or for all logins (/etc/pam.d/system-auth)


To accomplish this goal I will add the pam_access module to the PAM configuration files listed above. This module provides logdaemon-style login access control based on login names, host names, IP addresses, etc. The PAM module type that has to be used in the configuration files is account. This module type does the authorization, i.e. is the user allowed to login (e.g. time, day)? Don't confuse the PAM module type account with auth which does the authentication, for example checking the password. And the control flag I will use is required. It specifies that Success is required, Failure means that it will still call the remaining modules, but the result is already determined.

For SSH Logins add the pam_access module to /etc/pam.d/sshd as follows:

auth     required     pam_stack.so     service=system-auth
auth     required     pam_nologin.so
account   required     pam_access.so
account  required     pam_stack.so       service=system-auth
password required     pam_stack.so       service=system-auth
session  required     pam_stack.so       service=system-auth

For Console Logins add the pam_access module to /etc/pam.d/login as follows:

auth       required     pam_securetty.so
auth       required     pam_stack.so service=system-auth
auth       required     pam_nologin.so
account    required     pam_access.so
account    required     pam_stack.so service=system-auth
password   required     pam_stack.so service=system-auth
session    required     pam_selinux.so close
session    required     pam_stack.so service=system-auth
session    optional     pam_console.so
session    required     pam_selinux.so multiple open

For Graphical Gnome Logins add the pam_access module to /etc/pam.d/gdm as follows:

auth       required     pam_env.so
auth       required     pam_stack.so service=system-auth
auth       required     pam_nologin.so
account    required     pam_access.so
account    required     pam_stack.so service=system-auth
password   required     pam_stack.so service=system-auth
session    required     pam_stack.so service=system-auth
session    optional     pam_console.so

Now add the following line to the /etc/security/access.conf configuration file:

-:ALL EXCEPT users :ALL

The /etc/security/access.conf configuration file is read by the pam_access module. This entry specifies that no users are accepted except users that are in the "users" group. Since the pam_access module has been configured for "Authorization" (account) in the above PAM configuration files, it denies direct logins for all accounts except the ones that are in the "users" group.

Now on some systems like Oracle RAC clusters you have to enable direct ssh logins for oracle within the cluster. On such systems you can enable direct ssh logins for oracle within the cluster by adding/changing the following lines in /etc/security/access.conf:

-:ALL EXCEPT users oracle:ALL
-:oracle:ALL EXCEPT rac1cluster.example.com rac2cluster.example.com rac3cluster.example.com

The first line has been edited to include the oracle account which will allow general direct logins. However, the second line specifies that direct logins for oracle are only allowed from Oracle RAC nodes (rac1cluster, rac2cluster, and rac3cluster) that are part of the cluster.

NOTE:

In RHEL4 pam_access is already configured for crond:

# grep pam_access /etc/pam.d/*
/etc/pam.d/crond:account required pam_access.so accessfile=/etc/security/access-cron.conf
#

This means that the above entries in /etc/security/access.conf will stop cron from working. Note that it is very prudent to always check whether pam_access is configured for any other service on the system!

To ensure that all users on the system can still run cron jobs you can add the following argument to pam_access in /etc/pam.d/crond:

account required pam_access.so accessfile=/etc/security/access-cron.conf

This ensures that the /etc/security/access.conf configuration file is not invoked by crond. Since pam_cracklib does not grant permissions if the configuration file does not exist, execute the following command to create an empty file:

# touch /etc/security/access-cron.conf

Now verify that cron jobs can be launched by any user on the system.

NOTE:

The above example will only work if there exists no "users" account in the /etc/passwd file on the system, which is usually the case. Otherwise you have to either delete the "users" account or you have to designate or create another group name.