I am guessing the verbiage would help with many other products as well.  In the past with getting systems ATO, a developer/administrator/isso only had to document the delta‚Äôs of their configuration against the requirements and justify why they needed the delta.  Programs, for example, like Nagios for enterprise monitoring uses xinetd. I am sure there are plenty of other programs that use it also.

Does that rule or practice no longer apply?

On Apr 6, 2015, at 5:12 PM, Shawn Wells <shawn@redhat.com> wrote:



On 4/6/15 3:16 PM, Steve Grubb wrote:
On Monday, April 06, 2015 03:02:20 PM Trevor Vaughan wrote:
>Hi All,
>
>Since the new-ish (6 and 7) guides indicate that xinetd should be disabled,
>what is the preferred method for running VNC and TFTP sessions to a host?
>
>The tftp-server package installs the /etc/xinetd.d/tftp file but could
>certainly drop an init script/systemd script with associated sysconfig file.
>
>The VNC one is a bit more difficult since it gets difficult to have dynamic
>SSH-based terminals without something like xinetd (or, again, a highly
>configurable init script).
>
>I know this falls under the "if you need it, use it" category
I'd say this is still the case. Tfpd and vnc are not universally needed. I
think the aim is to reduce root running daemons (xinetd) in the common use
case so that the attack surface is smaller. In your situation on RHEL6,
install xinetd if you need it. In the case of RHEL7, systemd socket activation
should work (should even be shipped that way).

Reviewed the RHEL6 xinetd language, and the rules don't have the standard "if you need it, use it" clause.

Trevor, would adding that wording help you?
-- 
SCAP Security Guide mailing list
scap-security-guide@lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide
https://github.com/OpenSCAP/scap-security-guide/