Subject: Re: daily (& security) mail not delivered
To: NetBSD current list <>
From: William Allen Simpson <>
List: tech-security
Date: 06/28/2003 01:13:22
Andrew Brown wrote:
> >You mean "sounds to me like your machine wasn't completely configured
> >BY SYSINST."  Yes, that's why I'm raising the issues.
> sysinst isn't something i know all that much about.  i do, however,
> know how i want my machines to behave, so i check all sorts of things
> and tweak stuff manually all the time.  as to what sysinst does, or
> how much it should or should not, i can't say.
When I first tried to come back from OpenBSD last Sept with 1.6, sysinst 
didn't match its documentation.  I wrote up a long list of problems, and 
some of them were fixed.

Now, I find that nobody seems to have noticed that sysinst has been 
improperly configuring systems for months....  Yet, NetBSD has a list 
dedicated to working on the installer?

OpenBSD may have its problems, but the installer got better with every 
release.  People actually use it!  It matches the documentation, and 
the documentation is printed in every CD jacket.  Jeez o' Pete....

> >> > (A) PR install/21998
> >> >
> so you also want sysinst to do minor mta configuration and enable the
> mta?  i'm not trying to be argumentative here, just trying to pin down
> the points of contention.
In order for the system to be functional, sysinst has to enable a 
default MTA.  It does.  Badly.

> >The sysinst needs to build a working and secure system.  Running
> >internal security should be part of the default install -- of course!
> sure.
Glad we agree.

> >> >     Anyway, I'm thinking my approach would be a marked change of
> >> >     policy, timely for a 2.0 release, that warrants wide discussion.

And I meant *wide* discussion.  Is it time to change to postfix as the 
default MTA?

> >> > (B) PR install/21999
> >> >
> ><quote>
> >The sysinst adds a obviously unneccessary duplicate localhost line,
> a duplicate localhost line doesn't hurt anyone...
True.  But that was an obvious place to modify the code simply, in 3 
lines, with all the correct variables already in place, replacing a 
minor redundancy with something useful.

> actually, there is already a localhost zone that contains the
> localhost name.  

No.  Red herring.  It's not turned on by default, and therefore not 
relevant to this discussion.

> >Seems that "localhost.dom.ain" is not the same as to me?!?!
> particularly if "localhost.dom.ain" isn't in the dns.  it really ought
> to be in the dns.
What DNS?  A standalone system has no DNS.  A workstation has no DNS. 

The DNS is maintained outside the box, and therefore is not a good 
candidate for expection of a reliable and secure link to!

> >Therefore, it is certainly possible (and therefore perversely likely)
> >that the DNS zone "dom.ain." could have a record such as:
> >           localhost      IN      A
> >
> >This would certainly intercept all the localhost traffic for the zone,
> >at least in the current install, which expands all "localhost" to "localhost.dom.ain."
> now here's where i'm getting confused.  do you mean literally
> "localhost.dom.ain" or

> for what it's worth, i'm much in favor of the latter (the record being
> in the dns, but not with the wrong address), but not the latter.
Can you see why this is a security issue?  How do you "enforce" this? 

Can you see how all root traffic would be intercepted?

> the problem with putting the localhost.dom.ain record in the hosts
> file is that if your domain switches (as it will if you shift between
> dhcp zones in wireless restaurants and cafes, etc), then your mail
> will still suffer.  just not today.  tomorrow.  or the next day.  what

Of course, that's true of the only other line in the hosts file.  So, 
keeping these types of changes in the same place is pretty reasonable.

> sendmail ought to be doing is converting the "@localhost" portion to
> "", which it should already know, so that
> your local mail gets delivered locally.
Great!  How?

All we know is it doesn't do this now.  I'm proposing a fix to what it 
actually does, not to some other possibility.

Are there other applications that "ought" to be converting?
William Allen Simpson
    Key fingerprint =  17 40 5E 67 15 6F 31 26  DD 0D B9 9B 6A 15 2C 32