Bug 24011

Summary:	Sendmail listens by default, should it really?
Product:	[Retired] Red Hat Linux	Reporter:	Chris Evans <chris>
Component:	sendmail	Assignee:	Florian La Roche <laroche>
Status:	CLOSED RAWHIDE	QA Contact:	David Lawrence <dkl>
Severity:	medium	Docs Contact:
Priority:	medium
Version:	7.1	CC:	herrold, notting
Target Milestone:	---	Keywords:	Security
Target Release:	---
Hardware:	i386
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2001-01-21 16:30:47 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Chris Evans 2001-01-15 01:06:02 UTC

Default, full install.
Boot up the new system, and sendmail is listening on two TCP sockets.

I don't think this is wise. As well as the obvious "big root daemon" risks,
there are less obvious risks. Recent RedHat builds of sendmail are linking
in more and more libraries. The most worrying of these is Kerberos. I'd
really rather that Kerberos code paths were not remotely available in the
default install ;-)

As far as I know, the default listening behaviour of sendmail was disabled
late in the RH7.0 beta cycle. But, it was re-enabled again in RH7.0 final
due to a few glitches this caused.

If sendmail network listening is disabled for an early RH7.1 beta, there
might be time to sort out all the issues this time round.

Comment 1 Chris Evans 2001-01-16 23:29:43 UTC

In fact if we fix this, we'd be heading towards OpenBSD levels of security on a
default install...

Comment 2 R P Herrold 2001-01-21 16:30:38 UTC

I was a proponent too last time around -- the counter-argument was 
pathological programs which talk to localhost:25, rather than 
handing content off through a "| mailx"

If this is closed with a DEFER or WONT in the 7.x series, can we 
at least give 'fair warning' that it is depreicated contduct, and 
likely to break in future major releases?  That way, we can fairly
disable in th 8.0 and see what else breaks, and catch them early enough
in the release and design phase to avoid major wailing.

Comment 3 Florian La Roche 2001-02-04 09:33:55 UTC

We only listen on the loopback device at the moment and
only on the smtp port. Please send in problem reports if this
is not the way to go.