Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!henry From: henry@utzoo.UUCP (Henry Spencer) Newsgroups: net.bugs.v7,net.unix-wizards Subject: unexpected alarms Message-ID: <4861@utzoo.UUCP> Date: Thu, 3-Jan-85 14:35:23 EST Article-I.D.: utzoo.4861 Posted: Thu Jan 3 14:35:23 1985 Date-Received: Thu, 3-Jan-85 14:35:23 EST Organization: U of Toronto Zoology Lines: 31 There is a destructive security bug in almost every existing Unix version. Try writing a program that sets an alarm and then execs, say, passwd(1). A few seconds later, passwd(1) gets the alarm and drops dead, perhaps in the middle of an update to /etc/passwd. This problem definitely exists in V7. Inspection of source indicates that it probably exists in System V. (We have, but do not run, SysV.) I haven't summoned up the courage to check 4.2. Clearly, the *wrong* thing to do is to require every setuid program to reset the alarm. People writing setuid programs have enough to worry about already. There is also an important corollary of the Law of Least Astonishment: if you don't use a facility, you shouldn't have to care about it. One can argue that alarms should not be allowed to persist across exec(2) at all. This is probably stronger than necessary, however, and there are a few uses for such persistence; see page 229 of Kernighan&Pike for an example. However, not allowing alarms to persist across an exec of a setuid (or setgid) program seems appropriate. In V7 (SysV is similar, dunno about Berklix), late in sys1.c/getxfile(), you will find the code that implements setuid. It's trivial to add the statement: u.u_procp->p_clktim = 0; to the uid-setting and gid-setting if's. -- Henry Spencer @ U of Toronto Zoology {allegra,ihnp4,linus,decvax}!utzoo!henry