The 'Security Digest' Archives (TM)

Archive: About | Browse | Search | Contributions | Feedback
Site: Help | Index | Search | Contact | Notices | Changes

ARCHIVE: 'Phage List' - Archives (1988 - 1989)
DOCUMENT: phage #341 [Something General (was Security Checklist)] (1 message, 1297 bytes)
NOTICE: recognises the rights of all third-party works.


From: haynes@ucscc.UCSC.EDU (99700000)
To: phage
Date: Tue 14:01:51 06/12/1988 EST
Subject: Something General (was Security Checklist)
References: [Thread Prev: 337] [Thread Next: 329] [Message Prev: 337] [Message Next: 339]

Not every kind of site has the same security needs; so I wish vendors
would give us some #ifdefs or option switches to let us choose which
features we need.

Example:  On instructional machines we use a "group master" feature
that originated at Berkeley Computer Center (not EECS).  This provides
that the instructor has all privileges over all files in the class
group, regardless of protection codes.  A user is established as
group master if (uid == gid).  Clearly this is not something
everybody would want, but it's something we just about have to have
for machines where there is a class and all class members have the
same gid.

Example:  On most of our machines we have made it impossible for
the non-privileged user to set the setuid bit on files.  We found
students were using setuid mostly to Trojan-horse one another.
The group master can also set the setuid bit for files in the group.
Some kinds of sites no doubt have users with a legitimate need to
set the setuid bit; but we have a lot less work when they can't.

Example:  I like to hack the atrun program so it won't run scripts
as root.  Probably some sites have a legitimate reason to
allow root to run at scripts; but for me it's a security blanket
to have this ability disallowed.

Example:  I have the kernel hacked so that if the gid of a file is
zero the group protection bits are ignored.  All the systems people
use zero as the default gid when creating files.  By itself this
doesn't make anything more secure; but it does, we believe, somewhat
reduce the chance of accidental security lapses.

(Lots more examples on request.)

In general, academic and commercial and other kinds of sites have
different kinds of security threats and risks.  In a commercial site
you might be very concerned about unauthorized users getting on to
the system; but you have a reasonable expectation that the authorized
users might be well-behaved toward one another.  In an academic
setting you might be much more casual about unauthorized users
(because there are so many users and they have such a high turnover
that completely excluding the unauthorized is well-nigh impossible).
But you have to worry about keeping the authorized users from
harassing one another and from gaining control of the system.