Protecting against downloads

[Eric Peterson]

ralphs at halcyon.wa.com (Ralph Sims) writes:

| heiser at sud509.ed.ray.com (Bill Heiser - Unix Sys Admin) writes:
| 
| > A *ix sysop I communite with recently told me that he'd caught one of
| > his "shell-access" users downloading *ix binaries.
| 
| Sounds like he left HIMSELF open.

Of COURSE he left himself open to such activity -- why else would he
ask the net for help?

| > As far as I can see, we either have to trust the users that we give
| > shell access to, or make kermit/sz, etc unavailable to them.  I guess
| > we could just make downloads only available thru the "bbs", rather than
| > from the shell ...
| 
| How 'bout privileges on the files?  If the user didn't have read permission,
| then he wouldn't have got them (maybe?  I don't speak unix, but I'm sure
| someone will follow through on this).

** BZZZT! **  Wrong.  People need to be able to read the kernel and
other binaries.  Changing the permission bits on the standard files is
not necessarily a healthy idea.

| > Anyone else have any ideas on this?  How do you all deal with this?
| 
| Watch your back.

This is true.  But unhelpful.

| Protect your files.

This is what he's asking how to do.

| Don't give shell users root access.

Finally!  A useful bit of information.  Not much information, but more
so than the rest of the previous message contained ...

I would guess the user was downloading binaries that normal shell
users would need, such as the contents of the /bin, /usr/bin, /etc, or
/lib directories, as well as possibly the kernel itself.  This
presents the dilemma -- if I give the user access to those files for
shell use, he can then download them.

What you might do is write a shell script (or hack the xmodem, kermit,
or sz code) to check the user and group ID for each file that is being
attempted to be transferred.  If the UID and GID are "root" or "sys"
or "bin" or some other system ID, then deny access to the file.
Otherwise, let it go through as normal.

There is also a command under System V called "chroot".  What that
will do is create a virtual root for a running process, and all file
access done by the process will be relative to that root.  You might
want to consider using this function, but be careful with it -- by
using it, you basically isolate a process to one particular branch of
the file system, thereby isolating other parts of the system.  For
instance, if you gave the command "chroot /usr/$HOME /bin/csh" instead
of just "/bin/csh" as your shell command, the user would see
"/usr/$HOME" as "/" and would not have access to /bin or /lib.

| Run an MS-DOS system.

ACK!!  What makes MS-DOS so much better than Unix?  If I had DOS shell
access, I could still download the DOS binaries, so the problem would
still exist, right?  How would you solve it with a DOS system?

Eric
-- 
      Eric Peterson <> epeterson at encore.com <> uunet!gould!epeterson
  Encore Computer Corp. * Ft. Lauderdale, Florida * (305) 587-2900 x5208
Real Time: Here and now, as opposed to Fake Time, which is there and then.