VNC is not universally needed, I'll definitely agree on that one. But, I
haven't seen many environments that *don't* use some sort of GUI
forwarding, be it X (horrible, no), VNC, NXMachine, or something.
Sometimes you just need an app "over there" and a SOCKS proxy won't cut it.
But...how do you kickstart your systems from DHCP and/or update your
network devices that only speak tftp?
I cry foul on the fewer daemons make the attack surface smaller as I like
risk analyses with my mandates.
Xinetd *is* actually a security layer providing services for daemons that
cannot be otherwise easily protected. Sure, it can be abused by a reckless
admin, but what can't? Look at what some of the cloud services do with
iptables and turning everything into forwarding routers!
Yes, there are CVEs against xinetd, there are also CVEs against well,
pretty much everything, and until another *vendor supported* solution
exists, we need to use what is in the docs.
On Mon, Apr 6, 2015 at 3:16 PM, Steve Grubb <sgrubb(a)redhat.com> 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
> 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
> The VNC one is a bit more difficult since it gets difficult to have
> 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
should work (should even be shipped that way).
> but I was
> wondering if there were 'more compliant' alternatives that didn't
> epic amounts of work and/or maintenance and that stuck within the RHEL
> software stack.
Vice President, Onyx Point, Inc
-- This account not approved for unencrypted proprietary information --