Trusted system question

[Bolek Mynarski]

We are seriously entertaining the idea of swich our system to "trusted" systems. However, there is one question we have that so for, I could not the answer for.

How can I disable number of invalid logons for root? Is it by setting the value to '0'? I cannot find a clear answer to this question. The reason why I'm asking is because if there is a limit on how many times one can try to logon to the root accout, it will become an administrative nightmare (root account locked, take the system down, unlock it, etc.).

It does not take much for a malicious user to write a very short EXPECT scritp to exhaust number of failed logins...

Any suggestions?

Thanks.

[Patrick Wallek]

The root account locked is why you should set someone up with restricted SAM access so that they can go in and unlock IDs, including root.

[Brian M. Fisher]

On a trusted system, even if the root account beconmes locked, console access to the account IS still allowed. You can set a non-default value for Unsuccessful Login Tries for root using either SAM or using the u_maxtries value in the root file under /tcb/files/auth/r

Brian
<*(((>< er

[Wodisch]

Hello,
first: "root" can be unlocked by simply logging in on the
console using TEXT-MODE (not CDE!).
Second: Having somebody else with user-id 0, that one
could use "/usr/lbin/modprpw -k root" (or "-x", do not
remember, but one of the two does the trick) to unlock
the "root" account.
Pretty simple.
HTH,
Wodisch

[Philip Chan_1]

First of all, you could always re-enable root account by logging in from the physical console terminal. So you must make sure your console is secured from people.

Second, if somebody wrote EXPECT scripts to test the root password, you should NOT just increase the unsuccessful login count to avoid root being lock up. You should let the account locked so that intruder got no further chance to hack your system. Next thing you should do is to FIND who these people are (lastb -R root) then sue them perhaps, or send their boss a message for an explanation.

[Bill Hassell]

As mentioned, the root account can (and should) be locked as it is a security feature. After all, the reason to go trusted is to improve security and accountability. As mentioned, once the root account is disabled, you will have to login via the 'real' console. You want a lot of steps to go through to restore root's account.

It is NOT a good idea to ever have multiple UID 0 accounts. root privileges are always in force even if your login was billh or karenw. Consider the following big OOPS problems when logged in as UID 0:

- You need to cleanout your directory of a bunch of dot files (.profile, .exrc and so on) so you type: rm -rf .* Unfortunately, .* matches the current directory (.) and the parent directory (..) which is probably /home so every user file is now gone.

- billh leaves the company so you run SAM and remove billh and all the files owned by billh (which is UID 0) so the entire system is destroyed.

- All files and directories are created with root ownership, from email to temporary files, all carrying a potential security hole.

- One of the most common techniques by hackers is to simply change the UID of an existing user to 0.

You should always scan for multiple root user logins daily:

#!/usr/bin/sh
# Check for all UID 0's in the passwd file
/usr/bin/cut -f1,3 -d: /etc/passwd | tr ":" " " | while read USER UI
do
if [ $UID = 0 ]
then
echo "nuser $USER is $UID"
/usr/bin/grep ^${USER}: /etc/passwd
fi
done

------

Always use restricted SAM to allow limited root privileges to specific users or get a copy of sudo from the HP-UX archive site at: http://hpux.connect.org.uk/

[Philip Chan_1]

Another good practice for you to consider is to disallow direct login as root, this is for improving user accountabilities. Simply create the /etc/securetty file with one single line text "console". This way direct login as root user can only be done at the console. For remote session that would like to gain root access, people must login with their own id first, then perform the switch user command (su -) after, this way all su activities are to be logged in the /var/adm/syslog/syslog.log file.

~Philip