BostonU SysMgr <root%bostonu.csnet@csnet-relay.arpa> (02/04/85)
I think there is a possibly productive contribution that could come out of all these electrons flying by about AT&T source policies. It just hit me full force as I was left with a few 3B machines with a binary distribution on them (the source is in the mail) and now I gotta set them up. In the old days (less now) DEC would give a binary site for certain (most) O/S's quite a few sources, recognizing that this is necessary for survival. I think that there are quite a few programs/source modules that MUST be supplied with a UNIX distribution for survival. I realize a few of these are supplied with SOME distributions, but not enough. Assuming somebody from AT&T is listening (or could get the right person to listen) maybe someone could collect arguments for certain selected sources from us unix-wizards and consider why we are so upset/frightened by binary only systems. DON'T JUST START SENDING YOUR ARGUMENTS TO THIS LIST, they'll just get lost. Sample arguments: login.c,su.c: This is the front-line of defense passwd.c: for any system. I should be able to add rules like times of day for certain uids or secondary/long passwords. getty.c: This often needs a little customization to work properly in a given environment. init.c: same. All accounting summary software: C'mon, it isn't likely to be exactly right for my site. A few drivers: tty.c and friends for a little customization. A disk and/or tape device for examples if your binary claims to support addition of user drivers (an LP driver wouldn't hurt.) I think these are reasonable arguements, at least maybe a package of these could be sold inexpensively and unbundled from full source. I am not sure I really need the sources to, eg., cat.c to support my system.
jim@timeinc.UUCP (Jim Scardelis) (02/09/85)
> In the old days (less now) DEC would give a binary site for certain > (most) O/S's quite a few sources, recognizing that this is necessary for > survival. I think that there are quite a few programs/source modules > that MUST be supplied with a UNIX distribution for survival. I realize > a few of these are supplied with SOME distributions, but not enough. Having a microcomputer binary license, with a *few* sources, I agree. I would *really* like to be able to customize login.c so that dialup logins from 'root' are disallowed...but I can't. At least I have enough source/object modules to add device drivers to the system (and a 'sample' driver in the manual). At least shell scripts are readable... Jim Scardelis "The opinions expressed herein are those of my computer, and are not necessarily mine, or that of my employer."
honey@down.FUN (code 101) (02/10/85)
In article <97@timeinc.UUCP> jim@timeinc.UUCP (Jim Scardelis) writes: >I would *really* like to be able to customize login.c so that dialup logins >from 'root' are disallowed...but I can't. here's down!/.profile, written by pat parseghian, bowdlerized by me: trap exit 1 2 3 15 if [ "`tty`" != "/dev/console" ] then echo "root must log in on the console" exit 1 fi trap 1 2 3 15 there is probably a narrow window of vulnerability here. peter
loverso@sunybcs.UUCP (John Robert LoVerso) (02/17/85)
> In article <97@timeinc.UUCP> jim@timeinc.UUCP (Jim Scardelis) writes: > >I would *really* like to be able to customize login.c so that dialup logins > >from 'root' are disallowed...but I can't. > > here's down!/.profile, written by pat parseghian, bowdlerized by me: > trap exit 1 2 3 15 > if [ "`tty`" != "/dev/console" ] > then > echo "root must log in on the console" > exit 1 > fi > trap 1 2 3 15 > there is probably a narrow window of vulnerability here. Why not make the above the login shell of root, and at the end have it run /bin/sh or /bin/csh as you please? I've found that a shell (sh or csh) script thats somebodies login shell can't be stopped or broken out of w/o logging the person out. Therefore, the "window of vulnerability" is removed. John -- John Robert LoVerso @ SUNY Buffalo (716-636-3004) LoVerso%Buffalo@CSNET-RELAY -or- ..!{decvax,watmath|rocksanne}!sunybcs!loverso
dave@lsuc.UUCP (David Sherman) (02/19/85)
In article <1166@sunybcs.UUCP> loverso@sunybcs.UUCP (John Robert LoVerso) writes: ||I've found that a shell (sh or csh) script thats somebody's login shell can't be ||stopped or broken out of w/o logging the person out. Therefore, the "window ||of vulnerability" is removed. Sorry, that won't work on v7 systems, where you can't execute a shell file with exec(2), which is what login uses (execlp, actually). Dave Sherman -- {utzoo pesnta nrcaero utcs}!lsuc!dave {allegra decvax ihnp4 linus}!utcsri!lsuc!dave
rpw3@redwood.UUCP (Rob Warnock) (02/20/85)
+--------------- | Sorry, that won't work on v7 systems, where you can't execute a shell | file with exec(2), which is what login uses (execlp, actually). | Dave Sherman | {utzoo pesnta nrcaero utcs}!lsuc!dave | {allegra decvax ihnp4 linus}!utcsri!lsuc!dave +--------------- Well, I know that in 4.1bsd "execlp" will run a shell script (and on my F-box here, too), but where is it documented? A look at "exec(2)" in a V.7 manual reveals: Execlp and execvp are called with the same arguments as execl and execv, but duplicate the shell's actions in searching for an executable file in a list of directories. I have always read this to mean that in addition to using "$PATH", execlp/execvp also duplicates the shell's check for legal "magic numbers" (see "a.out(5)") and assumes anything else is a shell script (the 4.?bsd "#!" cookie is treated as a magic number). Checking "sh(1)" we see: Execution ...If the file has execute permission but is not an "a.out" file, it is assumed to be a file containing shell commands. But having my curiosity aroused, I went back to "exec(2)", read further on and found: BUGS If execvp is called to execute a file that turns out to be a shell command file, and if it is impossible to execute the shell, the values of argv[0] and argv[-1] will be modified before return. To be sure, there are clearer ways to say it explicitly (rather than as a side effect of describing a bug), but that pretty much settles it -- Version 7 "execlp/execvp" DOES work (exec a shell) for shell scripts. (Additional minor quibble: given the amount of diddling around it does, execlp/execvp should probably be with the other library routines as "exec(3)", rather than with the "pure" system calls in "exec(2)".) Rob Warnock Systems Architecture Consultant UUCP: {ihnp4,ucbvax!dual}!fortune!redwood!rpw3 DDD: (415)572-2607 USPS: 510 Trinidad Lane, Foster City, CA 94404
sienkiew@udel-huey (02/20/85)
>trap exit 1 2 3 15 >if [ "`tty`" != "/dev/console" ] >then > echo "root must log in on the console" > exit 1 >fi >trap 1 2 3 15 > >there is probably a narrow window of vulnerability here. The window is small, but it is there. If you put in .profile only the line bye it is still possible to log in to that account. By repeatedly hitting interrupt after typing your password, you have a chance of catching sh between it's signal() call and the execution of the first command. I know this because this is exactly what someone did to me when I was a novice Unix user. (This was on seventh edition unix.) This same characteristic exists in HP-UX (a derivative of System III), but I was unable to duplicate it with csh. You might want to just rewrite login for your site--it's really a pretty trivial program, and well worth it if the security is that important to you. Mark.