root shell

[Sharon Bi]

Dear all,

Per HP's document for 10.20, root's shell should be /sbin/sh. But our customized environment is all the super user use Korn Shell ( which means in /etc/passwd file, the shell for root is set to: /bin/ksh).

In order to do that, we have to boot the machine into single user mode, and do a: ln -s /sbin/sh /usr/bin/ksh. ( Because if you don't do this step, after you boot the machine, it will go to single user mode automatically and tells you " bad shell").

I know all these steps. But I don't understand why I am doing this. Could anybody explain to me how this thing works?

Thanks a lot in advance!

Sharon

[Paula J Frazer-Campbell]

Hi Sharon

You have solved the problem yourself - as per HP documebntation root's shell should /sbin/sh which you stated.

Do not change the root shell and you will not have the problem.

Your customised environment should not be configured to require that the root shell be any other that /sbin/sh.

HTH

Paula

[Devbinder Singh Marway]

The reason being under sbin , contains static binaries , i.e. does not require other programs involved in the include statement when compiled, so in case of a DR it can be mounted without depending on other files. Hence , it is not changed .

HTH

[Sharon Bi]

Sorry for the confusion. I think my questions are:
1) why root has to use /sbin/sh?
2) By the steps I mentioned , I am able to login as root using Korn Shell without problem. I want to know why by doing that symbolic link i can have what ever shell for root? ( Because i was just folowing some document from other people.)

[Tom Danzig]

Don't change the root shell to anything other than /sbin/sh. This can cause the system to be unbootable. As the /usr mount is not avaiable at first boot, your link to /usr/bin/ksh will fail.

If you want root to use ksh on interactive shells, you can modify the /.profile to test if the shell is interactive and the fire up ksh.

[Dan Hetzel]

Hi Sharon,

With your command ln -s /sbin/sh /usr/bin/ksh issued in single user mode, most probably with /usr unmounted (otherwise it would complain because /usr/bin/ksh already exists)
you create a symbolic link on the / filesystem.

That one will be hidden when you go multi-user and mount /usr.

The funny thing is that your newly created /usr/bin/ksh is totally equivalent to /sbin/sh as this is the file it points to.
As far as you're single user, it's just the same shell (posix).

Whe root logs in in multi-user state, he's got a korn shell.

The reason why root needs the /sbin/sh shell is that, as it as been said before, this one has been compiled with static libraries.
If it was compiled with dynamic libs instead, it won't find those libs in single-user state as the filesystems where those libraries reside isn't mounted yet.

Best regards

Dan

[Kofi ARTHIABAH]

Sharon,

I totally agree with Tom and Dan. I would suggest that you modify your ~/.profile so that the last line does an exec /usr/bin/ksh (if you must absolutely use the korn shell... mind you most of the features of ksh are supported by posix-sh)

#echo "exec /usr/bin/ksh" >> ~/.profile

[Sharon Bi]

Thanks for everybody. I am one more question:

Does this mean when a system boots, it goes to single user mode first? And then change to multi-user mode?

Thanks a lot!

[Kofi ARTHIABAH · Accepted solution]

Sharon:

When the system boots, it goes straight to the level specified in your /etc/inittab under initdefault. look for initdefault in this file and the number associated with it eg.

init:3:initdefault:

says that it should run at run level 3.
As it happens in order to reach run level 3, it has to execute scripts in order - these scripts are found in /sbin/init.d/rcX.d (where X is the run level)
and are typically a superset of the scripts in run level one.

To answer your question, theoretically, it does go through single user mode to get to the final run level.

there is a good document on your server in
/usr/share/doc called start_up.txt explaining the startup process - it is well worth a read.


Good luck.

[Kevin Ernst]

Someone slap me if what I'm about to suggest is thoroughly inadvisable or otherwise naughty.

Why not create a second account for UID 0, with the same home directory as 'root,' but with a different name and a different shell? I have a UID 0 account named 'rootb' which uses the Bourne-Again shell (bash). You could create a 'rootk' account--or whatever--and specify the Korn shell instead. You can use the two accounts interchangeably however you like, since they have the same UID and home directory. And you don't have to worry about screwing up the 'real' root account.

This is usually almost the very first thing I do when I get my hands on a new system. I also move root's home directory to /root (which is NOT on a mounted filesystem). Otherwise, after time, you get that unsightly buildup of dot-files and other garbage at the root of the filesystem--yuck!

[Paul Frederiksen]

You could do that, but you are just asking for security problems...

[Kevin Ernst]

I thought about that initially, but what *really* are the security implications of doing that? If the passwords are well-chosen to begin with, and synchronized between the two accounts, what's the diff? There's no prize for cracking BOTH accounts--you just get root access either way.

[Kofi ARTHIABAH]

Kevin:

I think that multiple root accounts are not adviseable in the same way that you would not you would not two doors to a safe! chances are higher that one of them will get compromised... then you've been had. Usually, it is easier to keep a hawk-eye on just one account.. than two (or three if someone can slip one in) besides backdoors are not a very good idea - an unethical sa who quits his job can own that machine. In short, minimize the chances of breaching your machine.

my 2c

[Bill Hassell]

SOme addtional comments:

/sbin/sh (the statically linked POSIX shell) is virtually indistinguishable from the Korn shell. While there are very small differences, for the majority of scripts and commands, the POSIX shell is a superset of ksh.

But more importantly, the POSIX shell has security features that are designed for root usage that are not present in ksh. Keep in mind that in single user mode (and this is *NOT* init s), the /usr directory is not mou8nted so there is no such file as /usr/bin/ksh. The shells in /usr/bin use shared libraries and will not function in single user mode.

You can prove this to yourse3lf by copying /usr/bin/ksh to /sbin and then rebooting into single user mode. Do this by interrupting the boot process and use hpux -is to reach *TRUE* single user mode. To verify this, type: mount and you not see /usr. If you do, you are not in single user mode.

But the most important reason to use the POSIX shell is that it will handle *all* the needs of the root user with security. There is no issue with shell scripts. All shell scripts should be written with:

#!/usr/bin/sh

or

#!/usr/bin/ksh

as you desire. The root user should *ONLY* be used when absolutely necessary! It is far too easy to make a mistake that can destroy the system when everything is done as root.

And concerning multiple root user ID's:

NEVER DO IT!

First, the pwck program will complain (and that's good) because it assumes that a hacker has attacked your system. But more likely, the casual user that logs in as billh and reads mail and creates files, etc, etc is creating havoc with your system as *ALL* protection has been removed. And that pesky billh user keeps forgetting that he is root and does dumb things that would never be allowed as a protected user.

Finally, a really bad thing happens when you remove the billh user and all the files owned by billh (you guessed it, all root files are removed). Don't ever give user ID 0 to any other account.

[Dan Hetzel]

Hi Sharon,


I fully agree with Kofi and Bill, with multiple root accounts it's exactly like having a safe with 2 or more doors.
You'll be asking for security problems.

More, as you seem to have people logged in as root regularly, you're facing a risky situation. Remember that root has ALL the rights on your system and is really able to do the WORST !!

If yourself or other users regularly need root privileges, you should use 'su' or install a utility like 'sudo' which will allow you to selectively assign root privileges for given actions only. This is a lot safer !!

Regarding the single/multi user state of your system during boot, your system is always booting to the level mentioned as "initdefault" in your /etc/inittab file.

It's 3 by default and this means that, to reach level 3, init passes by all level from 0 to 3, executing all scripts in /etc/rc[0123].d starting with the letter S (for start).
The same when you shutdown, in reverse order, executing scripts starting with letter K (for kill) in the same directories.

All those scripts use configuration variables defined in /etc/rc.config.d/*. You'll see that there is nearly always a variable having a 0 or 1 value which controls if the script runs or not.

All files in /etc/rcx.d have links in /sbin/init.d


Best regards,

Dan


ps: here is SUDO main page
http://www.courtesan.com/sudo/sudo.html

[Sharon Bi]

Thank you very much for all the help. ( I couldn't login to the forum at all this morning.)

I took a look at our "standard" password file:

root:*:0:3::/:/bin/ksh
supertom*:0:1:Tom as root:/:/bin/ksh
supertim:*:0:1:Tim as root:/:/bin/ksh

We have lots of super** accounts ( which might be a big potential security problem?) and the reason why they want to use korn shell is because they want to be able to track .sh_history file. Does this make sense?

[Kofi ARTHIABAH]

Hi Sharon:

Ouch! ...that is an absolute no-no in security terms. first, you have all super* sharing the same homedir , UID and GID. and that is equivalent to them being the same - one can log in and su to the other :-)

If you want to be able to track what others are doing, configure sudo, and track through the sudo logs.

if you need to see the history files posix-sh provides history file facilities (just like korn shell) from "man sh-posix":

HISTFILE If this parameter is set when the shell is invoked, its
value is the path name of the file that is used to
store the command history. The default value is
$HOME/.sh_history. If the user is a superuser and no
HISTFILE is given, then no history file is used. See
the "Command Reentry" subsection and the WARNINGS
section.
=========================================
In other words if you want root's .sh_history, then append the following line to /.profile

HISTFILE=$HOME/.sh_history

This works because this is what I use.

As has been said before most of the functionality provided with Korn shell are also available with sh-posix.

Cheers.

[Bill Hassell]

Sharon wrote:
--------------
root:*:0:3::/:/bin/ksh
supertom*:0:1:Tom as root:/:/bin/ksh
supertim:*:0:1:Tim as root:/:/bin/ksh

We have lots of super** accounts ( which might be a big potential security problem?) and the reason why they want to use korn shell is because they want to be able to track .sh_history file. Does this make sense?

------
This is the most common reason cited by new sysadmins concerning POSIX shell versus ksh, and it's one of the security features. The parameters HISTFILE and HISTSIZE should always be set in /etc/profile for everyone as they affect both POSIX and ksh shells. One difference with the POSIX shell is that it will not create $HOME/.sh_history for root. So it must be created to be used (and permissions should be 600 only).

I noticed /bin/ksh in your passwd file. /bin does not exist and has not existed for several years! /bin is a temporary (transition) link for /usr/bin (try this: ls -ld /bin). Transition links exist to ease the transition to V.4 filesystem layout and naming conventions fo the industry. It would be a good idea to scan all your scripts for obsolete startup lines like: #!/bin/sh, #!/bin/ksh, etc, and replace them with #!/usr/bin/sh.

[Dan Hetzel]

Hi Sharon,

This is really a security issue.
As Bill said previously, Posix shell doesn't create the .sh_history ($HISTFILE) for root, it must exist (permission 600) to be used.

Otherwise, Posix shell offers the same facilities as the Korn shell.

As I mentioned before, you should use the SUDO utility if you want some users to gain access to root privileges. This would at least allow you to track who's been doing what on the system, which could prove useful in some if not all cases.

Root login should be restricted to a strict minimum, possibly from the system console only.
All actions needing root privileges should be done through 'su' or 'sudo'.

Take some time to read the info at the following link:
http://www.courtesan.com/sudo/sudo.html

Best regards,

Dan