Bug 522524

Event posted on 09-10-2009 11:14am EDT by kbaxley

We have a customer at LANL that is not happy with the decision to install xinetd as part of the OpenIPMI update in RHEL5.4:

From: Ed Brown <ebrown>
To: "Giacomo G. Brussino" <ggb>
CC: Kent Baxley <kbaxley>
Subject: OpenIPMI update results in xinetd installed and running
Date: Wed, 09 Sep 2009 16:56:42 -0600
User-Agent: Thunderbird 2.0.0.22 (X11/20090625)

Hi Giacomo and Kent,

Could you create a support ticket over this bug that I've re-opened:

https://bugzilla.redhat.com/show_bug.cgi?id=429329

The OpenIPMI update in RHEL-5.4 included a bugfix that results, 
unnecessarily I believe, in the installation of xinetd.  Perhaps this 
should be opened as a new bugreport?

thanks,
Ed Brown
505 665-0908
This event sent from IssueTracker by kbaxley  [LANL]
 issue 340883

Event posted on 09-10-2009 11:18am EDT by kbaxley

Customer comments transferred over from BZ 429329:

  -------  Comment #24 From  Ed Brown (ebrown)  2009-09-09
18:10:29 EDT   (-) [reply] -------      Private

It was a heavy-handed fix to require xinetd to be installed.  Of course
when
xinetd installs, it defaults to running.  Basic configuration guidelines
101:
turn off and uninstall daemons you don't need, but now that would break
this
pseudo-dependency.  And it IS a false dependency: OpenIPMI does NOT
require
xinetd.  But not installing xinetd is no longer an option, and
unfortunately
it's not even so simple as to disable xinetd globally, because we do use
it
some places.  So this will now require completely new workarounds in our
configuration management settings to differentiate and handle the
different
cases, with the risk of mistakes and disabling xinetd where it is needed.

Manual intervention is already required to enable this fix, why would it
have
been too much to both edit a file AND copy a file?  Couldn't it have
been
accomplished with rpm triggers?  And when will RedHat GET that such a fix
as
this is security significant, unacceptable to your government customers
and
probably most corporate customers with a clue?  (Sorry, but my aggravation
is
high because this isn't the first time that updates have resulted in new
and
unrelated daemons installed and running.)  

------- Comment #25 From Ed Brown (ebrown) 2009-09-09 18:34:20
EDT (-) [reply] ------- Private

Actually, it was just simply a mistake to do this.  Other packages put
files
into /etc/xinetd.d/ without requiring xinetd itself.  /etc/xinetd.d/ is
owned
by the filesystem package.  



kbaxley assigned to issue for LANL.
Category set to: Applications::Bug Fix
Status set to: Waiting on Tech

This event sent from IssueTracker by kbaxley  [LANL]
 issue 340883

Event posted on 09-10-2009 11:22am EDT by kbaxley

Customer has asked us to please re-think the approach to solving the
original problem that resulted in installing and enabling xinetd with the
OpenIPMI update.
 
As they stated, this causes problems for government customers that have to
be careful in some environments about what services can be enabled and
disabled...in this case xinetd.  


This event sent from IssueTracker by kbaxley  [LANL]
 issue 340883

I didn't know that xinetd is started by default. But if the administrator does not touch xinetd config files, all services are disabled, xinetd does not open any listening port and basically only waits for reconfiguration. On the other hand, I understand the customer is upset, installing and *starting* new daemon on update is bad thing to do.

Question is, what can I do now? Of course, I can relax the dependency on xinetd in next update that it won't get installed, but the damage is already done.

Obviously the only thing that can be done is to remove the inappropriate and unnecessary "dependency" on xinetd.  

By the way, the rmcp file added to /etc/xinetd.d/ by OpenIPMI has the wrong modes.  It should be 644 like every other file there, it should not be executable (755).

I don't know what policies guide the release of rpm updates, but I believe these are security significant problems, and an update should not wait for RHEl-5.5.  RedHat stopped including xinetd as part of a standard install for good reasons: it shouldn't be installed unless needed.  Common configuration standards (e.g., the NSA's: http://www.nsa.gov/ia/_files/os/redhat/rhel5-guide-i731.pdf; CIS: https://community.cisecurity.org/download/?redir=/linux/CIS_RHEL5_Benchmark_v1.1.pdf), and common sense, agree that xinetd should not be installed or enabled unless needed.  You can't make assumptions about other configs in /etc/xinetd.d/, and admins may very well have attempted to globally ensure xinetd services aren't accessible by removing, or never installing, xinetd itself.  The installation and enablement of xinetd by the update for OpenIPMI is not documented in the release or technical notes.

clap clap.

Enabling a disabled / unistalled service is definitely a no-go. From my point of view -- medium size commercial, unlisted company, no formal SOX et al requirements -- this is a regression.

As probably most customers have not yet updated their infrastructure to RHEL5.4 it is still an option to fix the OpenIPMI package. This will solve the issue at least for all customers updating to the latest revision.

Release notes should also mention this change.

An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on therefore solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHBA-2009-1629.html