Restricted logins

[Santosh Nair_1]

Hi,

Long posting ahead

I've been working on writing a script to restrict logins on specified accounts. I have a script which checks to see if an account is restricted and if so, only users belonging to a particular group can log into that account. Further, the user MUST su to the account, no direct logins are allowed. I know I can accomplish this with /etc/securetty for root, but I have other users that I want to restrict, such as oracle and several application users.

To demostrate, in order to log into the oracle account, the user must log into a regular user account and then su to oracle. When su-ing, my script checks to see if the user is in the su-oracle group, then it checks that the parent process is a valid shell (thus proving that the account is being su-ed into and not a direct login). If both of these conditions are met, the script allows the user to log in as oracle.

The script is run from /etc/profile, so there is no way to get around running it. However, I've come across a few limitations with my script.

1. The user has to su - otherwise the /etc/profile is not run and therefore my script is not run thus defeating my security measures.

2. Because of the way the script works, it does not allow su-ing from other scripts.

Does anyone know a way around this?

I'm willing to post the script if anyone is interested.

-Santosh Nair (snair@graffiti.net)

[John Palmer]

Hi,

Some initial thoughts...

You can stop regular login and enforce the use of su by setting the encrypted password in /etc/passwd to *.

You can differentiate between login and su in your .profile by the setting of ${0}. For su this will be set to '-su' and for login '-sh'.

You could also investigate checking whether or not there is a terminal associated with the process 'if [[ -t 0 ]];' so that if there isn't then you don't restrict. This may fix your script calling su problem.

Regards,
John

[Santosh Nair_1]

John,

I'm afraid I don't understand. If you set the passwd to '*', then no one can log into that account (other than root). That was not my intent. I wanted users to be able to log in if they are authorized (i.e. in a particular group).

As for $0, that only works if the shell specified in /etc/passwd is /usr/bin/sh. Otherwise $0 is set to -shellname or shellname depending on whether the user su-ed with the '-' option or not.

Finally, as the tty, since this script is run after the user has logged in (since its being run from /etc/profile), there is always a tty assigned. So this doesn't really help.

Thanks for the input though.

[Rick Garland]

In the $HOME/.profiles, you could have the grget command executed and depending on the result, test to see if the user is part of the group.

If a member of group DBA, then OK, they can login and enter data (or whatever). If not a member, then echo back a comment and exit out or something to that effect.

[Santosh Nair_1]

Rick,

That is essentially what I am doing and that part works just fine. The problem that I'm
having is:

1. The user has to su - otherwise the /etc/profile is not run and therefore my script is not run thus defeating my security measures.

2. Because of the way the script works, it
does not allow su-ing from other scripts.

[Victor BERRIDGE]

have you thought putting in you users .profile or .kshrc an alias of su ?

alias su='su -'

Just thoughts...
Regards
Victor

[John Palmer]

I thought of that Victor but they can get past it with '/usr/bin/su'.

Without using restricted shells, I believe that the only way around it is to make /usr/bin/su unavailable to normal users by changing its permissions and writing a 'wrapper' script which has the setuid bit set to allow it to call su but which checks the calling user's credentials first.

Regards

[Victor BERRIDGE]

Or using sudo to do su- since you have changed perms on /usr/bin/su to be executable to root only?

What do you think John (and again congratulation...)
Best regards
Victor

[Santosh Nair_1]

These are very good answers wrt to the su
situation. I didn't want to have to resort to using sudo, but I like the idea of the wrapper script to replace su.

My bigger problem right now is that I can not run any scripts that su to other accounts. This is a big handicap since I work in a development environment where they are constantly installing things as different users and typically I've had to disable my script so that they could install the product and I sometimes forget to re-enble my script (I admin over 60 machines). Any help in this would be GREATLY appreciated.

[Vinit Adya]

Hi,
You could use a restricted shell for the user logins and allow only " su - "
This will ensure the users are always doing su - instaed of su. Hope this helps.

[Alan Riggs]

Santosh, where exactly is your script denying another script the ability to run an su -c? The two criteria you mentioned (valid parent shell and belonging to the apprpriate group) would both seem valid under those conditions. What test are you performing in your script that breaks these other scripts?