ENQUIRY: HP-UX disable direct login - only su allowed

[VK2COT]

Hello,

I came across an interesting problem.

Server runs HP-UX 11.11 (11v1), Gold
bundles 2005, TCB password database.

For security reasons, they want to disable
direct logins to several Unix accounts
(it is not root!). Those accounts belong
to some applications (for example oracle).

They want each user to log in as
themselves, and then su(1) to the
application account.

If they had HP-UX 11v2 and above, some
very elegant solutions would be readily available. A few to mention:

a) Role Based Access Control (RBAC).

b) Extended Pluggable Authentication Module
(PAM).

c) HP-UX Security Containment.

d) Authentication against LDAP, Kerberos,
or Windows NTLM, (this is also possible with
11v1, but in a limited fashion).

e) Smart Card.

and so on.

Alas, we are dealing with HP-UX 11v1 and most of the above do not apply.

* One of my ideas was to install HP-UX PAM
Requisite bundle (it is free to download
from HP) and play with /etc/pam_user.conf.
This is a special per-user PAM authentication.
But, I found so little information about it
at HP. This would require more time for
testing by trial-and-error.

* Another option were possible if they used a
newer version of SSH. There is an SSH config option called PasswordAuthDenyUsers.
But this also needs to be tested and possibly
even upgrade SSH...

* For small passwords file, SSH could be set
to use AllowUsers option. Then, only
selected users could connect via SSH
(telnet, rlogin and similar are already
disabled) and then su(1) to application
account. This might be nice simple method
to test.

* Method without SSH:

Nobody should know passwords for those special
Unix accounts.

Therefore, nobody could log into them
directly.

The staff that need to use su(1) to assume identity of those special accounts would use Super or SUDO.

SUDO and Super commands are loggable.

Any attempt to change password for those
special accounts (unless it is done by
root), should invoke disciplinary measure
or immediate dismissal.

A good security policy should be in place.

Plus, if auditing is enabled (which is currently disabled), special Unix accounts
could be fully audited for every
command they execute!

I can come up with many more ideas.

But to save time and money, I am asking if anyone else has come up with a simple method
to disable direct login for certain accounts
and force use of su(1) under HP-UX 11v1.
It is easy for root (/etc/securetty)
but I am talking about "ordinary" accounts
here.

I have done it via RBAC and other methods
for newer HP-UX versions, Linux and Solaris.
Alas, HP-UX 11v1 does not have many options.

Any comment is appreciated.

Maybe I am too tired today and cannot
see a simple solution (14-hour day
is quite enough for me),

Well, I am off to sleep and maybe someone
reads it overnight :)

Greetings from Sydney in far-away Australia,

VK2COT

[Steven E. Protter · Accepted solution]

Shalom down in Austrailia,

Happy Friday by the time you read this.

Of the solutions above seems the openssh based approach is the easiest. I recommend it because playing around with the ssh_config and the sshd_config files is relatively simple to do.

I recommend this only if the feature you want is available in a version of secure shell provided by HP at http://software.hp.com

That software is relatively well tested.

Most interesting is this document:
http://docs.hp.com/en/B2355-90680/login.1.html

There may be a way in there to force su login with normal users. see exec login

Sudo is a decent tool.


Last however is a simple add in to /etc/profile

REALNAME=$(who am i)
if [ "$LOGNAME" == "$REALNAME" ]
echo "Naughty child, direct login disabled $LOGNAME"
exit 1
fi

Note that who am i is different than LOGNAME when su - is used.

You will have to add a loop to only check these users, lets say they are in a list

while read -r uname

if [ "$LOGNAME" == "$uname"
then
REALNAME=$(who am i)
if [ "$LOGNAME" == "$REALNAME" ]
then
echo "Naughty child, direct login disabled $LOGNAME"
exit 1
fi
fi

done < /etc/specialusers

Some debugging required.
Also its possible for a user to break out of this loop unless you disable ctrl-c

SEP

[Wouter Jagers]

Hi there,

I used to 'quick-fix' this through the .profile of the accounts in question.

I made sure the .profile of these generic accounts could be edited by me only, and added something like this inthere:

###
if [ $(whoami) = $(logname) ]
then
echo "Access denied. Please first log in with your personal account and then use the su command."
exit
fi
###

Cheers,
Wout

[Patrick Wallek]

I am a big fan of the unknown password route. Set the password to some unknown value and use sudo to allow logins.

You could even write a quick script that would automatically do the sudo for the user.

# cat oracle
#!/usr/bin/sh
sudo su - oracle

Then the user just has to type 'oracle' at the prompt and supply their own password.

If you are concerned about people changing the password of these users, I would recommend a 2 pronged approach.

Step 1) Write a wrapper script so that any attempt to run the passwd program results in a failure and an e-mail sent to the appropriate people. I would exclude root from this check just in case you actually DO need to change the password.

Step 2) Have a script run nightly in cron that changes the password for these accounts. There is a good article in Sys Admin magazine about this topic. See here: http://www.samag.com/documents/s=9494/sam0502h/0502h.htm

I use exactly this approach for some user-ids on my systems.

[Heironimus]

Relatively modern versions of ssh also have a "DenyGroups" directive so that you can just modify group memberships to block direct login via ssh - much easier than listing everybody in DenyUsers. Naturally, this assumes that all non-SSH access to the server is disabled.

Relying on something in the profile doesn't work. Unless you use a custom shell that forces it, it's generally quite trivial to run commands or get a shell without running any of the login scripts.

If people are OK with sudo, that's a much better approach - frequently more elegant than the methods vendors provide. A lot of times you don't need to mess around with secret passwords, you just use a locked password like the various system users (bin, uucp, etc.). Then only root can set a password, nobody can su, nobody can log in. Add a sudoers entry to run a shell as that user (NOT an entry to allow them to run "su - user" as root) and pretty much everything runs fine. For that matter, if you only use sudo for access the user doesn't even need a valid shell.

[Marco A.]

Although the OS does not provide this capability directly (there is nothing
similar to /etc/securetty for root), adding the following statements to
/etc/profile or /etc/csh.login should prevent a certain user from
login but allow su - username.

Expand on the "if" statement if there are multiple accounts.


For Bourne and POSIX shells, add the following to /etc/profile:

#unsupported statements to prevent users from login but allow su.
name=`logname`
if [ $name = username ]
then
echo $name not allowed to login...only su
logout
fi
#end

Note: username should be replaced with the name of the user to
whom direct login access is denied.


For C shell, add the following to /etc/csh.login:

#unsupported statements to prevent users from login but allow su.
set name=`logname`
if ( $name == username ) then
echo $name not allowed to login...only su
exit
endif
#end

Note: username should be replaced with the name of the user to
whom direct login access is denied.

I hope this script helps,

Best regards,

Marco

[VK2COT]

Hello,

Many thansk for all comments.

I will implement and test both login profile
and SSH methods next week.

I still want to play with PAM as well,
but maybe time will not allow me to do it
in the short-term. If I find a PAM solution,
I will share it at ITRC forum.

Greetings from rainy Sydney (rain is very
rare in NSW so we welcome it :))

VK2COT

[VK2COT]

Hello,

This is the final solution. I will write a
Knowledge Brief about it:

a) As in any good company, inetd-based
protocols were disabled (telnet, rsh, rlogin).

b) Ordinary users have access to the server
via SSH only.

c) Added into sshd_config:

DenyUsers oracle prdadm

d) Installed SUDO and SUDOSH.
Everyone is familar with sudo, and
sudosh is available at:

http://sourceforge.net/projects/sudosh

For example, to log in as oracle:

/bin/sudo -u oracle /usr/local/bin/sudosh

SUDOSH captures all keystrokes on the tty and
the user cannot forge them! There is also a
replay command to check what the user did:

sudosh-replay

Note that sudosh can be a login Shell too!

Bingo: SUDOSH was a perfect and relatively easy method that made the customer happy.

Regards,

VK2COT