help@kendra.kew.com (Drew Derbyshire - UUPC/extended Help Desk) (09/11/90)
From article <1990Sep11.115623.6091@mp.cs.niu.edu>, by rickert@mp.cs.niu.edu (Neil Rickert): >>> UUPC/Extended version 1.08a is now available for the public. This >>> package is a small but *free* UUCP based mailer for connecting an MS-DOS >>> based PC to another PC or UNIX system. > > One question: Some earlier versions of UUPC allowed you to do wonderful > things such as > uucp myfile pcnode!/command.com > > Mail pcnode!/command.com > > Are these wonderful 'features' still available? Hmmm ... interesting question. The answer to the question may be yes; if it is, this is the last release of UUCP that will, because I promised someone yesterday that I would add a UUCP command to UUPC for the next release -- and if file transfers are supported, I have to secure the PC's root directory. (Actually, add a formal permissions file). By the way, stunts like the above example are why I don't keep my command.com in my root directory AND have three sets of backups for my hard drive. Also: I grabbed MUSH 6.5 off simtel20 and was reminded why I don't use it-- it is large enough to require overlays on MS-DOS, which kills performance. Nor is it will run on my PC, it complains my UUPC configuration file doesn't have a HOME directory -- which is a lie. I suspect a user problem (mine) on this latter item. Drew Derbyshire Internet: help@kendra.kew.com Snail mail: 108 Decatur St, Apt 9 Voice: 617-641-3739 Arlington, MA 02174
billg@cs.tamu.edu (William Gunshannon) (09/12/90)
In article <1990Sep11.164626.10348@news.clarkson.edu> help@kendra.kew.com (Drew Derbyshire - UUPC/extended Help Desk) writes: >From article <1990Sep11.115623.6091@mp.cs.niu.edu>, by rickert@mp.cs.niu.edu (Neil Rickert): >> One question: Some earlier versions of UUPC allowed you to do wonderful >> things such as >> uucp myfile pcnode!/command.com >> >> Mail pcnode!/command.com >> >> Are these wonderful 'features' still available? > >Hmmm ... interesting question. The answer to the question may be yes; >if it is, this is the last release of UUCP that will, because I >promised someone yesterday that I would add a UUCP command to UUPC for >the next release -- and if file transfers are supported, I have to >secure the PC's root directory. (Actually, add a formal permissions file). I would think that rather than trying to hack something into MSDOS that it doesn't support/understand (SECURITY), you would be much better off to make all file transfers INTO the PC go into a spooling directory (uucppublic), and leave the final disposition up to the PC user. There are other files that you probably don't want over-writen other than command.com (BIOS.SYS comes immediately to mind) and rather than trying to protect all these obscure files, I think it would be much easier to just put them all in one directory and have the user sort them out. Comments?? bill gunshannon bill@platypus.uofs.edu
rickert@mp.cs.niu.edu (Neil Rickert) (09/12/90)
In article <8158@helios.TAMU.EDU> billg@cs.tamu.edu (William Gunshannon) writes: >In article <1990Sep11.164626.10348@news.clarkson.edu> help@kendra.kew.com (Drew Derbyshire - UUPC/extended Help Desk) writes: >>From article <1990Sep11.115623.6091@mp.cs.niu.edu>, by rickert@mp.cs.niu.edu (Neil Rickert): >>> One question: Some earlier versions of UUPC allowed you to do wonderful >>> things such as >>> uucp myfile pcnode!/command.com >>> Mail pcnode!/command.com >> >>Hmmm ... interesting question. The answer to the question may be yes; >>if it is, this is the last release of UUCP that will, because I >>promised someone yesterday that I would add a UUCP command to UUPC for >>the next release -- and if file transfers are supported, I have to >>secure the PC's root directory. (Actually, add a formal permissions file). > >I would think that rather than trying to hack something into MSDOS >that it doesn't support/understand (SECURITY), you would be much >better off to make all file transfers INTO the PC go into a spooling >directory (uucppublic), and leave the final disposition up to the >PC user. There are other files that you probably don't want over-writen > >Comments?? > Absolutely. I totally agree. In working with an earlier version of UUCP I did a little hacking to improve security. My policies were: Incoming UUCP transfers must go to the uucppublic directory in my case \UUPUBLIC if the file contains a '/'. (Otherwise they go to the uucp spooling directory which is presumably safe. Outgoing UUCP transfers must come from the uucppublic directory when initiated from the connecting host, but may come from anywhere if initiated on the PC. I didn't actually implement the latter, for I never got around to creating the UUCP command on the PC. An additional nice little sanity check - the outgoing file in a UUCP transfer is not unlinked if the name contains a '/'. This means that only files in the spooling directory are deleted. Naturally this was added after I had lost a file during experiments. I stopped working on this when I discovered you could just mail to \COMMAND.COM. This is a more difficult security hazard to eliminate, for the delivery of mail by UUPC is based on converting the recipient name to a mail box, then reinvoking the delivery function to deliver to a file. A major reorganization of the delivery mechanism is needed. (I will communicate privately with Drew Derbyshire as to other changes I made, in case he wishes to incorporate some of them. I don't have the time to monkey with UUPC at present). -- =*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*= Neil W. Rickert, Computer Science <rickert@cs.niu.edu> Northern Illinois Univ. DeKalb, IL 60115. +1-815-753-6940
help@kendra.kew.com (Drew Derbyshire - UUPC/extended Help Desk) (09/12/90)
From article <8158@helios.TAMU.EDU>, by billg@cs.tamu.edu (William Gunshannon): > I would think that rather than trying to hack something into MSDOS > that it doesn't support/understand (SECURITY), you would be much > better off to make all file transfers INTO the PC go into a spooling > directory (uucppublic), and leave the final disposition up to the > PC user. There are other files that you probably don't want over-writen > other than command.com (BIOS.SYS comes immediately to mind) and rather > than trying to protect all these obscure files, I think it would be > much easier to just put them all in one directory and have the user > sort them out. > > Comments?? UUCP itself doesn't exactly seem brilliant in its treatment of files; if you want the level of security allowed by UUCP, it's really not that hard to do in MS-DOS with UUPC. Note that by limiting the user to a selected directory sub-tree you have locked out all your system files (mostly in the root directory), and by preventing overwritng of read-only, system, or hidden files you have provided additional security. I would also, I think, set the default to no overwriting of existing files at all; this will lock your MS-DOS system under UUPC as well as UUCP itself allows. Certainly the distributed default would be only writing to the UUPC public directory; after all, most people only want mail. However, by not allowing other options, you restrict the functionality. Drew Derbyshire Internet: help@kendra.kew.com Snail mail: 108 Decatur St, Apt 9 Voice: 617-641-3739 Arlington, MA 02174
les@chinet.chi.il.us (Leslie Mikesell) (09/13/90)
In article <8158@helios.TAMU.EDU> billg@cs.tamu.edu (William Gunshannon) writes: >I would think that rather than trying to hack something into MSDOS >that it doesn't support/understand (SECURITY), you would be much >better off to make all file transfers INTO the PC go into a spooling >directory (uucppublic), and leave the final disposition up to the >PC user. There are other files that you probably don't want over-writen >other than command.com (BIOS.SYS comes immediately to mind) and rather >than trying to protect all these obscure files, I think it would be >much easier to just put them all in one directory and have the user >sort them out. >Comments?? Why not just get the files on a diskette instead if you are going to have to manipulate them manually? How about simple config file options with PATH-like strings: READ= NOREAD= WRITE= NOWRITE= EXECUTE= NOEXECUTE= Where the names in the lists could be either directories or files. It would be useful to have these lists on a per-remote-system basis but if you accept inbound calls, the determination of the remote system name must be done bases on a login/password combination since the uucp handshake name is easy to fake. Les Mikesell les@chinet.chi.il.us