ARCHIVE: 'Phage List' - Archives (1988 - 1989)
DOCUMENT: phage #341 [Something General (was Security Checklist)] (1 message, 1297 bytes)
NOTICE: securitydigest.org recognises the rights of all third-party works.
START OF DOCUMENT
From: haynes@ucscc.UCSC.EDU (99700000)
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.
END OF DOCUMENT
|ISSN 1742-948X 01 (Online) | 2005/03/01 | Copyright 2002-2008 securitydigest.org. All rights reserved.|