Protecting against downloads

[Marc Unangst]

epeterso at encore.com (Eric Peterson) writes:
> 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.

I think it's a safe assumption to make that the type of user who has
to dig preprocessor symbols or dig into the kernel data structures is
rather different from the user who logs on and tries to download your
binaries.  If the user needed to do this, you might want to put them
in /etc/group as a member of "sysinfo" and let them newgrp(1) to
sysinfo when they test their program.  Special arrangements can be
worked out for special situations, but I feel my basic argument still
holds: On a "normal" Unix system that isn't being used for production,
users should not have read access to any of the binaries, the kernel,
or /dev/{kmem,mem,swap}.

> 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?

This all depends on what your system is being used for.  Naturally, a
system that's used for hacking the kernel sources is going to be set up
differently from an X server that users log into over the network and
run a database or something.

I don't run a Unix BBS now, but I have in the past and may in the
future.  My policy is to make sure system security is reasonably
tight, and then let users have shell access.  It's worked fine in the
past.

--
Marc Unangst               | "da-DE-DA: I am sorry, the country you have
mju at mudos.ann-arbor.mi.us  | dialed is not in service.  Please check the
...!umich!leebai!mudos!mju | number and try again."  -- Telecom Kuwait