Protecting against downloads

[Eric Peterson]

mju at mudos.ann-arbor.mi.us (Marc Unangst) writes:

| epeterso at encore.com (Eric Peterson) writes:
| > ** 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.
| 
| No, you're wrong.  People don't need to be able to read the kernel; in
| fact, on every modern Unix system I've seen, the ordinary user CAN'T
| read the kernel.  It's usually owned by "root", group "sysinfo" (or
| something similar), and permitted 640 or 040.  Programs like ps(1)
| that need to read the kernel are SGID sysinfo.  /dev/kmem, /dev/mem,
| and /dev/swap are similarly owned by group sysinfo and permitted 640
| or 040.  Any programs that have to access these protected files are
| SGID sysinfo.
| 
| The only executable files that need to be readable by the user are
| shell scripts.

As mentioned in another message, there is a program which can
determine preprocessor symbols by digging them out of the cc binary,
for which one has to have read permission on /bin/cc.  Also, if you're
working on a program which dives into the kernel and nlist(3) out the
addresses for its data structures, having read permission on the
kernel is also helpful.

| > 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.
| 
| Well, ignoring for the moment that "/usr/$HOME" will probably expand
| to "/usr/u/loginid" or something similar, this opens up a security
| hole big enough to drive a medium-sized planet through.  Consider this:
| 
| [[ Completely obvious example I didn't consider the first time ... ]]
| 
| The user now has root.  Kids, don't try this at home.  THIS IS WHY
| ROOT IS THE ONLY ONE ALLOWED TO EXECUTE chroot(1).

Aha!  I see your point.  An even less healthy idea than before.
However, if you were willing to take the time to do it, perhaps you
could set up a branch of your file system to be a limited subset of
your primary file system, with hard links from the subsystem into the
main system for programs that users would need access to (sh, csh, cc,
etc.).  If you also linked in /etc/passwd, /etc/group, and so forth,
you'd be set to present a limited subset of your main hierarchy.

There's only two things wrong with doing this -- (1) it may take more
time and effort than it's worth, and (2) it still doesn't solve the
original problem.

| The solution, as I mentioned before, is to remove read permission from
| any and all binaries, INCLUDING the kernel.  Make sure the hard drive
| and raw hard drive devices are permitted 600.  Make sure /dev/mem,
| /dev/kmem, and /dev/swap can't be read by an ordinary user.

All in all, it ends up boiling down to the question "Why do you want
to give your users shell access?"  To let them use the tools on the
system to develop their own programs?  To learn Unix?  To experiment
with various applications?  How far do you trust them?  What's your
policy towards shell access?

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.