Path: utzoo!utgpu!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!bloom-beacon!athena.mit.edu!scs From: scs@athena.mit.edu (Steve Summit) Newsgroups: comp.unix.wizards Subject: Unix security suggestion Message-ID: <8064@bloom-beacon.MIT.EDU> Date: 19 Nov 88 21:01:32 GMT Sender: daemon@bloom-beacon.MIT.EDU Reply-To: scs@adam.pika.mit.edu (Steve Summit) Lines: 52 One of the disturbing things about Unix security is that bugs in the protection mechanisms tend to be catastrophic: they don't just let you do some little unintended thing; more often than not they let you do anything, as root. For instance, Guy Harris recently reminded us of rlogin host -l '' which (I assume) makes use of the ::0:0::: lines which are, incredibly, still routinely left in the passwd file by broken software. I find it rather astonishing that these "turds" in the passwd file not only do not prevent the file's being read (most bugs break things badly), but in fact happen to introduce everybody's worst nightmare: a wide open, unrestricted security hole. Of course, in Computer Science, as in Mathematics, as in Nature, everything drains towards 0, so the fact that uid 0 is both the superuser and the most likely accidental value can be seen as an invitation to disaster. If only the kernel tested for superuser status neither with if(!u.u_uid) nor with if(u.uid == 0) but with if(u.uid == SUPERUSER) Then it would be a relatively simple matter to re#define SUPERUSER to some really unlikely value. (I have seen kernel code which uses if(suser()), which would also allow easy remapping.) I am quite aware of how well-entrenched is the notion that the superuser is uid 0, and what a massive and error-prone undertaking such a redefinition would consequently be. This is a good example of why embedding "magic numbers" and other assumptions in source code (rather than using #defines or other modular practices) is almost never a good idea. (Ah, the acuity of 20/20 hindsight.) Steve Summit scs@adam.pika.mit.edu