Path: utzoo!attcan!uunet!auspex!guy
From: guy@auspex.UUCP (Guy Harris)
Newsgroups: news.sysadmin
Subject: Re: Security check up summary (long)
Keywords: summary security
Message-ID: <379@auspex.UUCP>
Date: 1 Nov 88 19:31:09 GMT
References: <235@ssbn.WLK.COM>
Reply-To: guy@auspex.UUCP (Guy Harris)
Distribution: na
Organization: Auspex Systems, Santa Clara
Lines: 38

>6) On many systems, "at" is a security hole.  If no one uses it,
>disable it.

And beware if your system 1) supports "at" and 2) permits a user to give
files away.  Try submitting an "at" job; if the set-UID bit isn't set on
the "at" job file, disable "at" even if somebody *does* use it.  (I
suspect few systems have this hole, though; it doesn't exist in the "at"
that comes with S5R2 or later - I'd expect it only on systems that
support giving files away, S5-style, but that have the V7/BSD "at".)

>8) Keep a list of all setuid/setgid files on your system (use
>"find", for instance).  Keep the list off-line.  Recheck it
>periodically and see if any files have changed size or modification
>time (or had those bits added or deleted).

Also note that "ncheck", on many systems that have it, has a "-s" flag
that lists special files (i.e., devices) and set-UID files; you might
want to run this to make sure nobody's created any "back door"s to
"/dev/mem", or their own set-UID programs.

>10) On BSD systems, don't have any setuid/setgid shell scripts --
>unless you know that the security hole with them has been fixed
>on your system.

Umm, if you know of a fix for all the security holes, let us know; there
are some that are fixed by various changes in 4.3BSD (as long as you put
the right flag in the "#! /bin/sh" or "#! /bin/csh" line), but there's
another one that's not so easy to fix - the only reliable fix that I've
heard of requires an OS feature not present in most UNIX versions.

Note also that even if this security hole *is* fixed, it's probably hard
to write shell scripts that don't have other holes.  For one thing, if
you don't set IFS to "<space><tab><nl>" (the default value) first thing
in the script if it's a Bourne shell script (yes, you can do this, even
if IFS has been tampered with), and then set PATH or "path" right after
that, the script will probably be easy to break.  (Some versions of the
Bourne shell may not import IFS, which closes that hole.)  I'm sure
there are other similar tricks that I don't even know about....