dave@lsuc.uucp (David Sherman) (09/23/88)
My understanding of the "att" multi-machine setup is that
each of the three machines (Ohio, New Jersey and Illinois)
calls itself "att", and whoever happens to call you first
will pick up any mail addressed to/through "att". Fine.
Now, what happens if your dialin isn't working for a few
days, but your dialout is fine? OK, you think. You poll
all the sites that you talk to, so anything pending will
go through. But what happens if you normally call the Ohio
"att" for your mail, but there's a ton of mail waiting for
you on the New Jersey "att"? Will it ever reach you?
Should you have to call all three "att" machines if your
dialin is often busy or down? The three don't share the
same /usr/spool, do they?
David Sherman
The Law Society of Upper Canada
Toronto
--
{ uunet!attcan att pyramid!utai utzoo } !lsuc!davejhc@att.ATT.COM (Jonathan Hawbrook-Clark) (09/25/88)
In article <1988Sep23.105347.652@lsuc.uucp> dave@lsuc.uucp (David Sherman) writes: >My understanding of the "att" multi-machine setup is that >each of the three machines (Ohio, New Jersey and Illinois) >calls itself "att", and whoever happens to call you first >will pick up any mail addressed to/through "att". Fine. Right so far. >Now, what happens if your dialin isn't working for a few >days, but your dialout is fine? OK, you think. You poll >all the sites that you talk to, so anything pending will >go through. But what happens if you normally call the Ohio >"att" for your mail, but there's a ton of mail waiting for >you on the New Jersey "att"? Will it ever reach you? >Should you have to call all three "att" machines if your >dialin is often busy or down? >The three don't share the same /usr/spool, do they? No, they don't. And your underlying point is correct, any mail queued up for you will never get delivered. But not because of the scenario you suggest, although that is currently the case, but simply because we do not trust that a machine calling in is actually who it says it is. It is a trivial command to change a machine's nodename, and I suspect that no-one would thank us if we delivered mail for 'lsuc' to some schoolkid with a PC who happened to rename hir machine to that and call us up. So, except in rare cases, we only deliver mail when we make the call. This does pose a minor problem with our netnews feeds; we are moving towards a setup where mail received on, say, att-mt, for a site which has a netnews feed from att-ih will magically get forwarded to the appropriate att for delivery. This is primarily for cost reasons. Hope this clears up some questions. This situation isn't perfect, but we are putting security above convenience and cost. If anyone has any truly wonderful ideas which would satisfy the various criteria under which we work then we'd love to hear them. -- Jonathan Clark jonathan@mtune.att.com, attmail!jonathan Any affiliation is given for identification purposes only. The Englishman never enjoys himself except for some noble purpose.
dave@lsuc.uucp (David Sherman) (09/30/88)
In article <2300@att.ATT.COM>, jhc@att.ATT.COM (Jonathan Hawbrook-Clark) writes: > any mail queued > up for you will never get delivered... because > we do not trust that a machine calling in is actually who it says it > is. It is a trivial command to change a machine's nodename... > So, except in rare cases, we only deliver mail when > we make the call. > > Hope this clears up some questions. This situation isn't perfect, > but we are putting security above convenience and cost. If anyone > has any truly wonderful ideas which would satisfy the various > criteria under which we work then we'd love to hear them. Uh, yeah. Not to get snarky or anything, but many years ago someone came up with this wonderful idea called a PASSWORD. Just give each machine its own login. I realize this would mean a little more administrative overhead at your end; setting up a link would require a bit more contact with the other end. But it's hardly onerous. We have 45 uucp entries in our /etc/passwd, each with its own login name and password. Doesn't bother the other 1,490 users in the least. Of course, you'd no longer have the cuteness of running uucico on your dialup lines instead of getty. I must admit I was a bit startled when I first saw the L.sys entry for calling att (there's no login mechanism at all, you just dial and connect). David Sherman The Law Society of Upper Canada -- { uunet!attcan att pyramid!utai utzoo } !lsuc!dave
bill@carpet.WLK.COM (Bill Kennedy) (10/01/88)
In article <1988Sep29.210829.29073@lsuc.uucp> dave@lsuc.uucp (David Sherman) writes: >In article <2300@att.ATT.COM>, jhc@att.ATT.COM (Jonathan Hawbrook-Clark) writes: [ Jonathan's remarks ... ] [ David's remarks, followed by David's remarks that I'm following up ] >Of course, you'd no longer have the cuteness of running uucico >on your dialup lines instead of getty. I must admit I was a bit >startled when I first saw the L.sys entry for calling att (there's >no login mechanism at all, you just dial and connect). Now hold on here for just a minute. This suggests that the att gateways operate just like ihnp4 used to, i.e. any site on earth with something to say can call in and it will be said (even if it's to /dev/null). This makes a lot of sense from the standpoint of collecting as much att mail and news as possible, but it makes no sense whatsoever from a security point of view. Admittedly, "there's no login mechanism at all", but I thought there was at lease a verification of Shere. Perhaps Jonathan's (deleted) remarks about any site being able to masquerade as any other apply, but just *any* site who wants to shovel into att can call and do it? If that's so, I need to crawl back into my shell and watch my toenails grow. -- Bill Kennedy Internet: bill@ssbn.WLK.COM Usenet: { killer | att | rutgers | uunet!bigtex }!ssbn!bill
chip@ateng.ateng.com (Chip Salzenberg) (10/03/88)
According to dave@lsuc.uucp (David Sherman): >> [att does] not trust that a machine calling in is actually who it says it >> is. It is a trivial command to change a machine's nodename... >> So, except in rare cases, we only deliver mail when >> we make the call. > >Uh, yeah. Not to get snarky or anything, but many years ago >someone came up with this wonderful idea called a PASSWORD. >Just give each machine its own login. ...which solves nothing. If I (ateng) have a UUCP login on att, then I can change my nodename to uunet and then use the 'ateng' login. Presto, I've logged in successfully and picked up uunet's mail. This does leave tracks in the log files; but the damage is done by the time it's discovered. -- Chip Salzenberg <chip@ateng.com> or <uunet!ateng!chip> A T Engineering Me? Speak for my company? Surely you jest! >> Beware of programmers carrying screwdrivers. <<
les@chinet.UUCP (Leslie Mikesell) (10/05/88)
In article <1988Oct3.115720.2175@ateng.ateng.com> chip@ateng.ateng.com (Chip Salzenberg) writes: >...which solves nothing. If I (ateng) have a UUCP login on att, then I >can change my nodename to uunet and then use the 'ateng' login. Presto, >I've logged in successfully and picked up uunet's mail. HDB uucp knows how to check LOGNAME against the entries in the Permissions file. If you give each machine its own login name and password it is possible to detect the nodename/logname mismatch. Les Mikesell
jbuck@epimass.EPI.COM (Joe Buck) (10/05/88)
David Sherman: >>Uh, yeah. Not to get snarky or anything, but many years ago >>someone came up with this wonderful idea called a PASSWORD. >>Just give each machine its own login. Chip Salzenberg: >...which solves nothing. If I (ateng) have a UUCP login on att, then I >can change my nodename to uunet and then use the 'ateng' login. Presto, >I've logged in successfully and picked up uunet's mail. Not if att is ran HDB uucp, assigned a different account and password to each neighbor, and used the VALIDATE keyword in their Permissions file. If Permissions is set up correctly, then the only way for att to believe that you are uunet is to log in with uunet's password. I'm told that the 4.3 UUCP has similar features. We can make the UUCP network a lot more secure than it is now with very little work, and major mail hubs should especially concentrate on this. -- - Joe Buck, card-carrying ACLU liberal jbuck@epimass.epi.com, or uunet!epimass.epi.com!jbuck, or jbuck%epimass.epi.com@uunet.uu.net for old Arpa sites
brian@ncrcan.Toronto.NCR.COM (Brian Onn) (10/05/88)
In article <1988Oct3.115720.2175@ateng.ateng.com> chip@ateng.ateng.com (Chip Salzenberg) writes: >According to dave@lsuc.uucp (David Sherman): >>Uh, yeah. Not to get snarky or anything, but many years ago >>someone came up with this wonderful idea called a PASSWORD. >>Just give each machine its own login. > >...which solves nothing. If I (ateng) have a UUCP login on att, then I >can change my nodename to uunet and then use the 'ateng' login. Presto, >I've logged in successfully and picked up uunet's mail. > >This does leave tracks in the log files; but the damage is done by the time >it's discovered. But what about HDB UUCP? The LOGNAME and VALIDATE fields of the Permissions file can prevent some login from using another node name. I would hope that the att sites are using HDB, since it would sure make an awful large /usr/spool/uucp directory if they weren't. Not to mention the almost unmanagability of it. Brian. -- +-------------------+--------------------------------------------------------+ | Brian Onn | UUCP:..!{uunet!mnetor, watmath!utai}!lsuc!ncrcan!brian | | NCR Canada Ltd. | INTERNET: Brian.Onn@Toronto.NCR.COM | +-------------------+--------------------------------------------------------+
wisner@zug.AI.MIT.EDU (Bill Wisner) (10/06/88)
>...which solves nothing. If I (ateng) have a UUCP login on att, then I >can change my nodename to uunet and then use the 'ateng' login. Presto, >I've logged in successfully and picked up uunet's mail. "The LOGNAME entry LOGNAME=uucpfriend VALIDATE=eagle:owl:hawk specifies that if a remote machine that claims to be eagle, owl, or hawk logs in on your 3B2 Computer, it must have used the login uucpfriend." -- The AT&T 3B2 System V Release 2.0 Basic Networking Utilities Guide discussing the format of the /usr/lib/uucp/Permissions file.
honey@umix.cc.umich.edu (Peter Honeyman) (10/06/88)
Chip Salzenberg writes: >...which solves nothing. If I (ateng) have a UUCP login on att, then I >can change my nodename to uunet and then use the 'ateng' login. Presto, >I've logged in successfully and picked up uunet's mail. wrong. the att machines run honey danber with SENDFILES=NO in Permissions. this was pointed out in an earlier note by an att person. peter
chip@ateng.ateng.com (Chip Salzenberg) (10/08/88)
Okay, okay, I surrender! At least five people, including no less a net.personage than the one and only peter honeyman, have pointed out that HDB UUCP -- which I have never used, sad to say -- is capable of restricting a given UUCP login for use by a given host. Mea culpa, mea culpa, mea maxima culpa. Enough already. -- Chip Salzenberg <chip@ateng.com> or <uunet!ateng!chip> A T Engineering Me? Speak for my company? Surely you jest! Beware of programmers carrying screwdrivers.