On 01-01-04 Ethan Benson wrote:
> On Thu, Jan 04, 2001 at 10:40:46AM +0100, Christian Kurz wrote:
> > Hm, what about changing the postinst of telnetd so, that I ask the admin
> > who installs debian or the package, if he really wants to activate
> > telnetd or not?
> either that or downgrade telnetd to another priority.
Well, I'm not sure if downgrading would be a good idea, but changing the
postinst-script should be easier to do as this would part of it would be
very generic and could be used in other scripts via cut&paste too.
> > > nfsd and nfs-common are also standard, but nfs-kernel-server's
> > > initscript won't start the daemons if /etc/exports contains no
> >
> > So that means that this security risk is not by default opened.
> correct for nfsd, not for rpc.statd though.
So rpc.statd still get's started even if it's not used?
> > > exports. nfs-common and portmap are started by default though. (and
> > > statd had a nice root hole recently)
> >
> > And I think we don't need a running portmap as default for all installed
> > system. I think we should also modify this postinst-script to ask the
> > user if he really needs a running portmap or not and have it per default
> > turn portmap off.
> well in unstable portmap is now a seperate package so possibly its
> priority could be lowered so the admin would have to install it. (or
> it would be installed when a service requiring portmap is installed
> since they must depend on it) this would require downgrading the
> priority on nfs-common (and thus nfsd) along with any other standard
> package requiring portmap. i don't know what the politics of that
Hm, why must it be downgraded? Is the priority to high currently to
remove it from the standard-installation?
> would be. (more then likely a big flamewar where all propronants are
> called incompetant morons)
Well, I'm not sure if this will really be a flamewar, since the security
holes in portmap and nfs have been obvious and visible for everyone, so
to increase our security and make debian also the choice for
security-aware people. I think this approach would fit to debian's image
fine.
Ciao
Christian
--
Debian Developer and Quality Assurance Team Member
1024/26CC7853 31E6 A8CA 68FC 284F 7D16 63EC A9E6 67FF 26CC 7853
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
