Protecting against downloads

[John B. Milton]

In article <2412 at sud509.ed.ray.com> heiser at tdw201.ed.ray.com writes:
>Thanks to all of you who replied so quickly to my question about
>protecting my system against unauthorized downloads of binary files.
>The overwhelming majority of the responses have told me what I 
>already knew -- the (obvious) setting of file modes to be execute-only.
[lots deleted]

Watch out! In addition to execute, you MUST leave +r on all *shell scripts*,
or the shell (not the kernel) can't open them to INTERPRET them.

This would do it (MUST BE RUN AS ROOT so that set[ug]id bits don't get lost)

for d in /etc /bin /usr/bin /usr/local/bin /usr/lbin; do
  cd $d
  if [ -f .distperm ]; then
    echo "Directory $d already read protected"
  else
    ls -l > .distperm
    file * | grep '386 exe' | cut -d: -f1 | while read i; do
      if [ -x $i ]; then
        chmod go-r $i
      fi
    done
  fi
done

(I just typed this in, so DON'T post if I goofed something trivial)

The "ls -l > .distperm" creates a file containing the original permissions as
distributed. Most everything should still be ok, unless your machine has some
bad shell script with "if [ -r /bin/ls ]...". Most shell scripts I've seen do
the right thing (-x). Note the trick to find binary executables "386 exe". Do
a "file /bin/ls" to make sure "386 exe" is a good substring for your machine.
You WILL have to change it if your machine isn't a 386. The files to watch out
for would most likely be something in /etc, so you might not want to run it on
that directory. Files that may match the executable string from the file
command that you CANNOT remove read acccess to are: /unix (lots of programs use
nlist(3) on it) and *.[ao].

If you don't NEED to protect your system in this way, DON'T DO IT, you're just
in for a lot of headaches.

The argument that that there is no need to protect a public system is not
entirely valid. Someone may want to download just a package you have that they
do not: man pages (which could be protected by setuid man page readers), X
(which one would think could be easily obtained freely, but not so because
of proprietary servers), DWB (almost always costs extra, a prime target),
TCP/IP and compiler (tougher to get all the pieces), comercial packages.

One attack method that is easy to use is to look at how a package is installed
on the system, find the de-install script and trace it to figure out where all
the parts of the package are. These scripts are easily protected since they
are only used by root to de-install a package.

The chroot(2)(1) idea is a very powerful one, but a bitch to setup and maintain
(/etc/[uw]tmp, /usr/mail, news). It is also easy for a user to figure out that
they are in a chroot environment (ls -lid /). The rsh idea only works with
beginners and should NEVER be relied upon.

Pseudo shells, menus and BBSs are one of the best ways to provide access in a
secure way, but you have to be VERY careful about running programs that can
shell out (rn, vi, mail). Hacking up restricted versions of these programs can
be another maintenance hassle. The correct way to hack up these programs is
to make sure that they ALWAYS ONLY use the SHELL environment variable. For
menu users you point SHELL to something like /bin/false or a program that
informs them that they can not shell out. Public source is available to mail
programs (MUSH, ELM, etc.), news readers (rn) and editors (mg2a, stevie, etc.)

The absolute best way is to restrict your machine to trusted people and avoid
the friend of a friend of a friend kind of thing.

P.S. Anyone got a quick tool for changing rwxr-s--x stuff to 2751 stuff?

John
-- 
John Bly Milton IV, jbm at uncle.UUCP, n8emr!uncle!jbm at osu-cis.cis.ohio-state.edu
(614) h:252-8544, w:469-1990; N8KSN, AMPR: 44.70.0.52; Don't FLAME, inform!