locking down users

[Glenn S. Davidson]

I have searched (perhaps I missed something) and have not come across anything that helps me so I am resorting to posting my question.

I have recently discovered that users who have requested an account on one of my servers are doing some "curiosity" probing which I was assured they would not (likely promise I know).

So I have experimented with a restricted shell (rksh) but I noticed that even though they cannot "cd" around nothing prevents a knowledgeable user from copying files from their current location to their home directory for inspection and later deletion.

I also have experimented with chroot and found out that "sublogins" are not allowed on a host that has "trusted services" turned on.

I'm not sure how concerned I should be about this since I've tried to maintain a pretty tight server. It would be nice if I could "quarantine" some of these pesky guys so I would have less to worry about. Even if it was for a short period (like giving a 2 yr old a time out)

Hope you can help.

Glenn

[Steven E. Protter]

Sounds to me like you need a policy prohibiting probing.

Then turn on sh_history, use cron to copy the files to a root only location and scan for activity you don't like.

Then if you see restricted activity, contront the individual

There have to be policies in any organization and they have to be enforced. There should be some level of trust of people who work for your organization.

Further, I'd run Bastille on your system and lock down permissions as much as possible to make sure the system is as robust as possible.

Of you want to go nuts, you can run IDS/9000 and track the activities you dislike.

SEP

[John Kittel]

Don't know if this can help you, - What about restricting the commands that the account is allowed to run by setting the account's PATH in .profile to special bin directory containing hard links only to specific commands the account actually needs?

- John

[Glenn S. Davidson]

I had considered that when I read the rksh man page but there really isn't a good description of how to use it and I guess I was hoping this was going to be easy.

[John Kittel]

When I needed to do this sort of thing for the first time recently for one user, I learned about creating a "captive acct" from the O'Reilly book, Essential System Administration.

- John

[Glenn S. Davidson]

Here is a synopsis of what I did for future searchers.
I checked out this document (A4161307)
http://www2.itrc.hp.com/service/cki/docDisplay.do?docLocale=en_US&docId=200000062937578
and it worked well but when I got everything completed I tried to log in and found out that with HP's trusted services turned on it doesn't allow sublogins (which is what this "padded cell" required) so I had to look at the restricted shells again. I ran some tests and found out that if you just create a standard user and don't modify anything the only thing they cannot do are the 4 things listed in the man page. This didn't prevent them from copying a file to their home directory and viewing it and then deleting it. I didn't think this was of any use so I discarded it and kept searching. From one of the replies I received I looked into the /usr/rbin to see how that could help and help it did. Here is what I ended up doing to capture this user in a jail:

1. Changed his shell from ksh to rksh
2. Created /usr/rbin with the same permissions as /usr/bin
3. Modified his .profile and changed the $PATH variable to /usr/rbin only (PATH=/usr/rbin) but left everything else the default
4. changed the ownership of his .profile to root:sys
5. Changed the permissions of his .profile to 644
6. Removed all other files (.cshrc, .login, etc)
7. Created symbolic links from the commands he will need to /usr/rbin

This means that if the file (link) isn't in /usr/rbin then he cannot run it. This includes ls, vi, more and anything else. Restricted shells already prevent you from modifying the environment and from using cd so I think he is quarantined.

Hope this helps someone else.

Glenn

[Glenn S. Davidson]

Oops, I forgot:

8. I changed the permissions on his home directory to 555 just to be sure.

Glenn