Restricted Shell and /etc/default/security file

[Chris Wong]

Happy New Year to everyone.
I've added an article on the /etc/default/security settings that can be used for restricted shell users. You can find it here:
http://newfdawg.com/SHP-RestShell
Please understand that the old (bad) default behavior only exists if you have not applied specific patches (not necessarily the patches I mention).

(BTW, SearchHP.com shutdown a few weeks ago, so you won't be getting anything from this site anymore if you were subscribed). I had already written the article before they shutdown.

- Chris

[Frank Slootweg · Accepted solution]

Is your procedure vi(1)-safe?

While you do not say that vi(1) is an acceptable command (in the user's bin directory), you also do not specifically exclude it.

Note: I have not tried with a /etc/default/security file, but normally rsh(1) can not be made secure without a chroot-ed environment, i.e. using the 'Subsystem' login facility of login(1) ("*" in the command name field of the /etc/passwd entry).

See for example the following threads:

http://forums.itrc.hp.com/cm/QuestionAnswer/1,,0x77cf7680e012d71190050090279cd0f9,00.html

http://forums.itrc.hp.com/cm/QuestionAnswer/1,,0x31298f960573d611abdb0090277a778c,00.html

[Chris Wong]

Hi,

My article points out that unless your system is correctly patched, the correct behavior for rsh, as pointed out in one of the above links:

the following is disable by using a restricted shell:
- Changing directory (cd)
- Setting the value of SHELL, ENV, or PATH
- Specifying path or command names containing /
- Redirecting output (>, >|, <>, and >>)

does not work correctly. Also, if you go to a new site and saw the setting of "RSH_SECURITY=0" yikes!

It is important to continually check the behavior of security settings as they may change. This may be a mistake on HP's part, but a security admin shouldn't assume a default behavior, even though you would think it is OK. For example, At one point, it was "fixed" so that only a user from a hpterm could send commands to a session opened by root that was writeable. When I was teaching a security class several months ago, it was determined that this worked from anywhere (11i), not just the hpterm. Perhaps it was a patch issue, but the point being that the system wasn't working as you would expect. (Yes, yes, yes, root shouldn't have a writeable session).

As far as using "vi" with the rsh, I haven't played with that, but would be very cautious. You wouldn't want them to be able to write files into their home directory or bin, and I suppose there would be an issue with the /tmp directory.

- Chris

[Frank Slootweg]

> As far as using "vi" with the rsh, I haven't played with that, but would be very cautious.
> You wouldn't want them to be able to write files into their home directory or bin, and I suppose there would be
> an issue with the /tmp directory.

Well, I don't really believe in 'security by obscurity', so I might as well be more specific:

I was implicitly referring to setting the shell with ":set shell=...." and then executing that shell. Also, if you can execute chsh(1), you can get rid of the restricted shell altogether.