hutch@fps.com (Jim Hutchison) (06/03/90)
In article <6721@blake.acs.washington.edu> mrc@Tomobiki-Cho.CAC.Washington.EDU (Mark Crispin) writes: >No. We aren't talking about hiding passwords in a secret file. Any >file, once known, can be gotten at. We are talking about hiding the >password where only the kernel can get at them. Granted, a program >that does absolute disk reads can get at the passwords; but such a >program (1) can't be run under FTP (2) can only be run by a privileged >user (and hence the system is already violated). An interesting idea, you want the kernel to maintain a password database on a secondary storage device. This database is not a user accessible file system. Nor is it mountable in a normal way, because if it were it would be able to be left that way by the same careless sysadmin who bungled the permission bits and ftp setup. Among other things, who backs it up? If root must back it up, then you've got to set up the backup utilities to be run safely by operators... If "operator" is going to back it up, it has to be readable by the op. This being the sort of problem which seems to prompt people to slam in suid/sgid bits or chmod a+r things. Not my solution, but apparently a common one. Sounds like a mini-nightmare to maintain, based on backing it up (securely!) and restoring it in the event of a tragedy (one could no longer type it in using /bin/cat and being able to remember root::0:0:&:/:/bin/sh). At first thought I'd think you could use /bin/cat to the raw device, but then you'd have to remember the major/minor number of it for mknod, and it gets worse from there. This is demanding a lot of smart thinking from the sysadmin who is having so much trouble securing the system. >We are talking about setreuid() not requiring any privileges, but >taking a password as an argument. We are talking about no "setuid" >programs; in its place are new unprivileged system calls which make >the necessary checks. So, the hacker now has to probe individual passwords instead of attacking the database. Not much of a win judging by the effectiveness of the various worms and security studies involving password guessing. >In other words, we're talking about making it harder for the system to >be compromised simply by poor file protections! Please revise, it still looks like "poor filesystem protections", ftp> set binary ftp> cd /dev ftp> get r0xd0b ... >Unix purists argue that this "adds a lot of junk to the kernel" and >interferes with the beauty and elegance of Unix. I hate to break it >to them, but the Unix kernel hasn't been "small and beautiful" since >PDP-11 days. In view of the small gain involved, the massive cost in development, standardization, and maintenance. I'd say you hit the nail on the head when you labeled this "junk". It is a very interesting idea though. Perhaps it would work better if the secondary storage device was something more oriented to security, such as one of those password scratch-pads I've heard the kerberos folks use on occasion. Then it'd be an add-on password library and a device driver. You might be able to sell a few million to the government and research facilities. You could probably interest Logicon in it, or some other company working on a secure Unix. -- - Jim Hutchison {dcdwest,ucbvax}!ucsd!fps!hutch Disclaimer: I am not an official spokesman for FPS computing