root%bostonu.csnet@csnet-relay.arpa (BostonU SysMgr) (09/01/85)
Is this an unreasonable (or useless) place to air this? My hope is some reasonable (most) people from ATTIS read this list. If not send me a few flames and I'll shut up. The argument thus far is that binary licenses to UNIX should always come with a few sources because of various security and administrative policies that a site might need to institute that shouldn't require a full source license, among those mentioned were login.c. So far the list has been: 1. The ULIMIT problem, modifying login.c is currently the only effective way to raise ulimit above 2048 on SYSV. 2. Enforcing times when certain users can or cannot login, or other variables (eg. load, free dialups available etc.) This *could* be done via /etc/profile but I think most would agree it belongs in login. 3. Schemes like if they type in N bad passwds hang the phone up, maybe warn someone (the user or SA.) Here's another one that was just brought up on the SECURITY mailing list. If user's are not careful about password creation (and people are just people) then a reasonably determined cracker can grab the encrypted string in /etc/passwd and run it against dictionaries (this is all well documented in "The Security of UNIX", I think that was Kernighan, sorry, working from memory here.) A trivial defense (used I believe years ago at Harvard and probably lots of other source sites) was to make /etc/passwd a dummy file (so most software is undisturbed) which does not contain encrypted strings but otherwise is publicly readable. You then create another, unreadable, copy (call it /etc/passwd.nr) with the strings. The only two programs that I can think of that use those encrypted strings (as delivered) are login.c and passwd.c, just modify those to use the unreadable version (easy.) It would also be handy to have a script that can be run that builds the readable from the unreadable when it is modified (easy.) If need be, passwd.c could be re-written by any competent applications programmer in an afternoon. Login.c is quite subtle and would be a bit of a job to rewrite from scratch without having access to its source. So, another sound argument I believe that certain software sources should always be delivered with UNIX systems (hey, we're a University, we get sources to all of this stuff, but my binary only PC7300 got me thinking.) Now, another security/integrity problem on UNIX I would like to hear a discussion on: /tmp. Let's face it, it's a problem (anyone can do an 'rm /tmp/*', or fill it with junk, or usually read many files on it.) How about considering a temporary file type (maybe by making /tmp a device?) with some special rules (delete on last close, no name in the visible file space except to root etc.) Of course any design should be ignorable (transparently work the old way at sites that don't need it, like my UNIX/PC.) -Barry Shein, Boston University
peter@graffiti.UUCP (Peter da Silva) (09/04/85)
> a device?) with some special rules (delete on last close, no name in ^^^^^^^^^^^^^^^^^^^^ ^^^^^^^^^^ > the visible file space except to root etc.) Of course any design should ^^^^^^^^^^^^^^^^^^^^^^ > be ignorable (transparently work the old way at sites that don't need it, > like my UNIX/PC.) easy, do this when you make temporary files: ...make temp file name somehow (mktmp, maketmp, whatever it's called this week)... if(!(fp = fopen(file, mode))) { ...error processing... } unlink(file); An unlinked file is not actually thrown away until the last close. Viola. You get delete on last close & invisibility. Not that this is really important since most everyone keeps their files open and thus deleting them (rm /tmp/* was one problem suggested) wouldn't make much difference. For security just make your tmp file 0600 mode.
draughn@iitcs.UUCP (Mark Draughn) (09/04/85)
In article <1149@brl-tgr.ARPA> root%bostonu.csnet@csnet-relay.arpa (BostonU SysMgr) writes: [...] >Here's another one that was just brought up on the SECURITY mailing list. >If user's are not careful about password creation (and people are just >people) then a reasonably determined cracker can grab the encrypted string >in /etc/passwd and run it against dictionaries (this is all well documented >in "The Security of UNIX", I think that was Kernighan, sorry, working from >memory here.) > >A trivial defense (used I believe years ago at Harvard and probably lots >of other source sites) was to make /etc/passwd a dummy file (so most >software is undisturbed) which does not contain encrypted strings but >otherwise is publicly readable. You then create another, unreadable, >copy (call it /etc/passwd.nr) with the strings. The only two programs >that I can think of that use those encrypted strings (as delivered) are >login.c and passwd.c, just modify those to use the unreadable version (easy.) >It would also be handy to have a script that can be run that builds the >readable from the unreadable when it is modified (easy.) [...] In my UNIX manual it is pointed out several times that it is a crock that user information (office, name, shell, etc.) is stored in the password file. It should be in a separate database. So far, it isn't. I guess it would be easier to move the passwords than it would be to move anything else. This should be a standard part of UNIX. (Not that I don't think that a few source files would be nice. I am at a university so we have source, but we also run VMS without source and I wish I had it.)
tanner@ki4pv.UUCP (Tanner Andrews) (09/04/85)
] few progs need to see encrypted passwords in /etc/passwd, /etc/group ] therefore, have non-readable pw file containing this info. Login, passwd, newgrp, and su are the main progs which require this information. However, in many cases, the password in /etc/passwd may be used by some program that wants to be sure that the person using it is really who we think it is. Any prog may wish this information. A database maintainer (real or game) may wish to protect certain functions by requiring a password which is matched against some /etc/passwd encrypted string. This is certainly a way offered by the documents to verify a person's identity. As for the "dictionary" testing: have a daemon go through there each weekend, and flag those passwords that it can guess. Have the "passwd" prog use the dictionary and reject any passwords it finds there. Have a bulletin printed for your new users advising them that it is bad form to use real words. -- <std dsclm, copies upon request> Tanner Andrews, KI4PV uucp: ...!decvax!ucf-cs!ki4pv!tanner
gww@aphasia.UUCP (George Williams) (09/09/85)
> ] few progs need to see encrypted passwords in /etc/passwd, /etc/group > ] therefore, have non-readable pw file containing this info. > > Login, passwd, newgrp, and su are the main progs which require this > information. However, in many cases, the password in /etc/passwd may > be used by some program that wants to be sure that the person using > it is really who we think it is. > > Any prog may wish this information. A database maintainer (real or > game) may wish to protect certain functions by requiring a password > which is matched against some /etc/passwd encrypted string. This is > certainly a way offered by the documents to verify a person's identity. I think a better solution is to have a setuid program that returns an exit status of 0/1 to identify the user, the program should guarantee a sleep of a few seconds if the user gets it wrong to protect against dictionary searches. Fork/exec may be slow but this sort of thing doesn't happen that often (in my experience less often than password crackers) but if you really care you could hack a system call into the kernel which could take a file descriptor to read from a string to verify, and maybe a filename to read from. George Williams decvax!frog!aphasia!gww I'm not to be found, I'm fully occupied elsewhere. If you wish to find me I shall be in my study. You can knock, but I shall give you no reply. I wish to be alone with my convictions.
peter@rlgvax.UUCP (Peter Klosky) (09/16/85)
XXX
> For security make your /tmp file 0600 mode.
Security?
This seems dubious. My idea of secure includes being able to
read back what was written, possibly from another process.
/tmp is world writeable. This means that anyone can unlink tmp files.
In particular, my application wants to pass state data from a child
process to a parent prodcess via a tmp file that the child creates,
and there are windows of vulnerability in this scheme, due to the unlink
trouble.