SECURE LOGIN

[Chris Chaoman]

How do I stop users logging in directly as oracle or any other power users? The same way that /etc/securetty works for root.

Chris C

[Wim Rombauts]

Enter some direct text in the password field. That will prevent users from being able to enter a correct password.
You can allways become oracle executing "su" as root without needing a password.

This setup is possibly not that quickly to do. We configured our software-accounts like that from the beginnen and use .rhosts and .shosts to configure who is allowed to ogin as who. If you have scripts or other programs that depend on the oracle account password, you should modify those scripts first.

[Robert Salter]

Chris,

You could do something like this: create a file, say .idnams and put in the IDs you do not want to have direct logins to, i.e. "oracle". Then in /etc/profile add;
grep $LOGNAME /var/adm/.idnams
if [ "$?" = "0" ]
then
echo "You must login with your own ID and then 'su' to $LOGNAME"
sleep 5
exit
fi


Robert

[Dennis Handly]

>Robert: grep $LOGNAME /var/adm/.idnams
if [ "$?" = "0" ]; then

You should clean this up so the grep doesn't get echoed for everyone:
grep -q $LOGNAME /var/adm/.idnams
if [ $? -eq 0 ]; then

[Robert Salter]

Thanks Dennis, your way is cleaner.

[VK2COT]

Hello,

I implemented a simple solution for Oracle
accounts for a Fortune-100 company recently.
They wanted a free (open-source) and portable
solution that worked for HP-UX, Linux and
SunOS (Solaris).

In fact, my Knowledge Brief is just about to
be published for HP staff.

Short summary for ITRC:

a) Disable all standard but obsolete
protocols (telnet, rlogin, rsh, ...).
I do this on all servesr anyway :)

b) Disable CDE, X-windows logins
(not many use it nowdays).

c) Set DenyUsers in sshd_config:

DenyUsers oracle

That way, user oracle cannot log in
via SSH.

d) Install SUDO and SUDOSH (either compile
them or get packages). For HP-UX,
I could not find ported version of SUDOSH
so I had to build it myself.

e) Set up sudoers file. For example:

User_Alias DBA=dba1,dba2
DBA ALL=(oracle) /usr/local/bin/sudosh

f) Then, as user dba1 or dba2:

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

The beauty of SUDOSH is that it also
keeps a log of ALL commands that
are executed. Admin can even do this:

sudosh-replay

Excellent for those which are
obsessed with SOX-compliance.

Cheers,

VK2COT

PS. I also tested various solutions
(but they are all different for various
flavours of Unix) based on PAM, and Role
Based Access Control.

Finally, companies that do not
have budgetary constraints would
definitely like PowerBroker (commercial
product).

[Robert Fritz]

I'd also recommend some free tools that give you better granularity of control than sudo/powerbroker:

Select Access for IdMI (role-based access), and HP-UX Bastille (for lockdown and security-configuration reporting).

Also, I'm a little nervous about relying on Robert/Dennis' approach. I suspect (though haven't tested it), that an interrupt or shell escape could get a user past that check in the profile.

[Dennis Handly]

>Robert: that an interrupt or shell escape could get a user past that check in the profile.

I would think that would just exit the shell.

[Heironimus]

Actually it's probably better to use "if grep -q foo ; then" intead of grep followed by a comparison with $?. But either way, it's still wrong for what you're trying to do.

/etc/profile is only called for a login shell. If you specify a remote command you won't invoke a login shell. "ssh -t user@host /usr/bin/sh" will give you an interactive shell without running /etc/profile, unless you've taken special steps to prevent it. Most of the time it'll be easier to find a better way than it will be to force a call to /etc/profile.

I've demonstrated this several times for people. It usually leads to a surprised look followed by a long explanation of how remote shells work and how shells decide what login scripts to run.



For the most part Dusan's advice looks correct to me, but I do have a couple comments on it.

I would recommend EAS over sudosh, if you can still find it anywhere. It fixed a lot of the shortcomings of sudosh and added support for logging to a network server. Unfortunately, I think some company bought the rights from the original author and quickly took down the source so they could sell a new version as part of their product instead....

I would also recommend using AllowGroups and DenyGroups instead of AllowUsers and DenyUsers in sshd_config. Using a group makes the access control part of account management, listing individual users in sshd_config makes access control part of sshd administration.