Re: RH Taroon Beta Open Ports

[David T Hollis <dhollis davehollis com>]

Steve Dickson wrote:

> rhldevel assursys co uk wrote:
>
> > > statd (i.e. nfslock) probably does not need to be running if NFS is 
> > > not configured but
> > > tunning off portmapper is a bit extreme... Not only do local process 
> > > expect portmapper
> > > to be there,
> > >   
> >
> >
> > Which local processes? We've already heard about sgi_fam, and we already
> > know about NIS and NFS, but is this really worth leaving it listening on
> > external interfaces in a _default_ install?
> third party applications of our beloved customers... There are 
> *probably* a few more
> applications other than NFS and NIS that need to advertise ports.... 
> Remember the
> RPC subsystem has been around for a very long time which means we 
> really don't
> what we would be breaking by turning it off... Just because you don't 
> know about
> something..... does not mean they don't exist....

Your missing the point here.  No one is saying don't ship portmap or nfs 
utilities.  Just raising the question as to whether they should be 
enabled by default.

> > > The
> > > point being turning off portmapper could (and probably will) cause 
> > > unexpect process
> > > to fail in unexpect ways making very difficult to debug especially 
> > > during installation...
> > >   
> >
> >
> > As a matter of course, I disable portmap and rpc.statd on any machine 
> > not
> > expected to perform NFS or NIS and have not noticed any side effects 
> > as a
> > result.
> So we can assume that your system is an *exact* clone of every other 
> linux system
> out there... so what works in your world will work everywhere.... I'm 
> sorry but
> I just don't by your logic...

I also disable them on my systems since I don't typically utilize NFS 
(nor NIS, or any other RPC based service) and I have not had any 
problems either.  Using the recent MS DCOM problems, MS' technical 
information for the problem suggested a workaround of disabling DCOM 
with the following nebulous disclaimer:

*Warning* If you disable DCOM, may you may lose operating system 
functionality. After you disable support for DCOM, the following may 
result:

   * Any COM objects that can be activated remotely may not function
     correctly.
   * The local COM+ snap-in will not be able to connect to remote
     servers to enumerate their COM+ catalog.
   * Certificate auto-enrollment may not function correctly.
   * Windows Management Instrumentation (WMI) queries against remote
     servers may not function correctly.

(http://support.microsoft.com/default.aspx?scid=kb;en-us;825750)

It translates to most folks as "If I disable DCOM, no one knows what is 
going to break".  With a stock RH install, how many RPC using services 
are available?  NFS, NIS, sgi_fam, and??  Unlike MS, you know what will 
not function if portmap is not running.  3rd party apps are certainly a 
different ballgame, but that is the 3rd parties responsibility to 
mention the requirement of portmap.

> >  
> >
> > > Portmapper has been around quite a long time making it pretty bullet 
> > > proof...
> > >   
> >
> >
> > Funny, 'cos in my universe, the portmapper is regarded as one of the 
> > most
> > vulnerable pieces of UNIX software, along with rpc.statd, sendmail 
> > and BIND.
> Educate me...  How has it *recently* (i.e within the that 3 years) 
> been exploited?
> And what damage was caused?
>
> > > So I see no reason what so ever to turn off portmapper. Lets not make a
> > > system more difficult to deal with for simply no reason...
> > >   
> >
> >
> > ...but there is a reason - making new installs secure by default. For a
> > admin who's already configuring NFS or similar, the extra step of
> > chkconfig'ing portmap and rpc.statd isn't much of a burden.
> Again.... NFS and NIS are not the only user of portmapper... We have 
> to keep
> in mind  the entire industry... not just or own little worlds....
>
>
> SteveD.
>
>
> --
> Rhl-devel-list mailing list
> Rhl-devel-list redhat com
> http://www.redhat.com/mailman/listinfo/rhl-devel-list