What good is rsh or rksh?

[Steven Sim Kok Leong]

Hi,

One main purpose of rsh or rksh is to prevent traversal of parent or higher-level directories beyond a user's home directory.

What good is it when the user can still traverse the parent directories after executing one of the shell interpreters such as /usr/bin/sh in his restricted shell?

Thanks in advance. Regards.

Steven Sim Kok Leong

[Animesh Chakraborty]

Hi,
That is why I have seen critical installation like bank etc they use their own customise shell called "Rsh" with a file Rsh.dat in users home directory which defines what are the command allowed to run.
And command like /usr/bin/sh gives not allowd error.

[Frank Slootweg]

As you have found, using rsh or rksh by itself does not help very much, because its restrictions can be (too) easily circumvented.

There is hardly any documentation on how to *properly* set up rsh or rksh. As far as I know, there are no 'cookbooks', etc..

The only documentation I am aware of is this small part in the login(1) manual page:

> If the command name field is *, a chroot() to the directory named in
> the directory field of the entry is performed. At that point login is
> re-executed at the new level which must have its own root structure,
> including /bin/login and /etc/passwd.

[harry d brown jr]

The best security policy is to keep users out of any shell prompt, or out of any application that allows them to "SHELL OUT". To secure or "paste" their existence to a particular directory, use chroot.

live free or die
harry

[Christopher Caldwell]

In order for restricted stuff to work correctly, you've got to limit access to commands using a judicious PATH setting.

At the other end of PATH, you would not have access to a shell intepreter.

You would provide a short list of commands a user needs to do their job.

You'd be careful to make sure these commands don't let you subvert the security measures provided by a restricted shell.

Here's what you cannot do when using a restricted shell (man rksh):
+ Changing directory (see cd(1))
+ Setting the value of SHELL, ENV, or PATH
+ Specifying path or command names containing /
+ Redirecting output (>, >|, <>, and >>)

[Frank Slootweg]

Christopher,

As Harry mentioned, it is (too) easy to 'break out' of a restricted shell.

What you mentioned is how one can (try to) prevent *well*-meaning users getting themselves into trouble, but it will do not much, if anything, to keep people with bad intentions out.

[Christopher Caldwell]

No doubt, Frank. The best thing to do (tm) is *NOT* give shell access at all, since undoubtedly there are always unanticipated side effects with restricted shells.

I gave my post because most problems I've seen with folks implementing rksh come because they change the user's shell but leave the default system PATH in place. That gives the illusion the the restricted shells don't work at all; restricted shells do work, but you've got to ready the man page so see what work they really do ;-).

[T. M. Louah]

Remember these guidelines about /etc/passwd from man 4 passwd:

The following fields have character limitations as noted:

+ Login name field can be no longer than eight characters;
+ Initial working directory field can be no longer than 63 characters;
+ Program field can be no longer than 44 characters.
+ Results are unpredictable if these fields are longer than the limits
specified above.

[Thierry Poels_1]

Hi,

the restricted shell command on itself is worth nothing if the user can access another (not restricted) shell.
You have to narrow the user's PATH variable way down, and most likely put/copy all the commands/programs he need in a separate directory, and mabye even limit his PATH to this single directory.

good luck,
Thierry.

[Wodisch]

Hello Steven,

do not believe you would be able to gain any kind of security by using any r*shell (rsh, rksh)!
Think about that scenario:
- rstricted shell
- profile sets PATH to a directory containg links to *permitted* commands only
- profile executes "readonly" on PATH
- profile does a "cd" to *safer* working-directory
- profile etc are owned by someone else with not write permission for that user in his/her $HOME, nor the dot-files in there (.profile,...)

It does still NOT work, as eventually that user will execute a program which will be able to execute another command, like "/bin/sh" - and that's it :-(

Tried that many years back - and it was NOT safe!!!
Not even with a patched shell...

Be very, very careful in trying chroot-ed/jailed setups, too! There are ways out of those, still.

Sorry,
Wodisc

[Layne C. Berg II]

This is a slight twist to what has been discussed, but a good "real world" example of where this is used alot is for Corperate FTP servers.

For example lets says that you are a distributer and you have supplies that have to upload data on a daily basis for your accounting department. They need a login to the system but you don't want them to have a shell and you certain don't want it to be anonymous.

If you setup the home path with the correct permissions they should not be able to leave there login directory and compromise the system, at least not with out extensive system knowledge :)

Anyway food for thought.

Layne

[Steven Sim Kok Leong]

Hi,

Thanks for your comments.

In my environment, I don't use restricted shell. Instead, I use restricted SAM.

In /etc/profile, I force the user within signal traps to launch restricted SAM which limits the user to executing only specific programs and pre-configured scripts, with an exit logoff immediately after the restricted SAM execution.

I was concerned with rsh/rksh because it could potentially mislead unknowing system administrators into thinking that they are safe.

Regards.

Steven Sim Kok Leong

[Michael Tully]

Hi,

There is no real *safe* shell from a system
administrator, but having the right tools in
place can prevent most hiccups.

I've found in my experience
that junior administrators use 'root'
priviledges for sometimes no apparent reason
and as such this provides unintentional
mistakes. The use of restricted sam, sudo and
captive menus are a better alternaive. I know
I'm a little of right-field in regards to
having restricted shells but are we talking
about hacking systems, boo boo's or command
line developers? Hacking systems, well build
a bastion host (helps) boo boo's (will always
happen as long as people have 'root' access.)
Developers, well if you give them any sort of
shell access on a production system, is like writing your own death warrant?

My 2 bobs worth
-Michael