Bug#81118: base: Wishlist: High security base system (or separate add-on package)
On 01-01-04 Ethan Benson wrote:
> On Thu, Jan 04, 2001 at 11:37:08AM +0100, Christian Kurz wrote:
> > 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.
> perhaps, but for the most part daemons packaged in debian are not
> priority standard and thus not installed by default. the decision to
> install the daemon should imply the desire to run it IMO. for some
> cases i agree there should probably be a question, especially daemons
> that outright require admin configuration before being useful anyway.
Alright, I think I can agree with this.
> i just think a trend of daemons when installed asking whether the
> admin really wanted to install and use it would be rather annoying.
Absolutely and I think moving telnetd to a lower priority would give a
better sign that debian is also aware of the security of it's OS.
> i prefer to not enable daemons by not installing them.
> > So rpc.statd still get's started even if it's not used?
> yes, so long as portmap is started, which it is by default. lockd is
> started if needed/supported.
This is bad behaviour and we should then really fix this.
> > Hm, why must it be downgraded? Is the priority to high currently to
> > remove it from the standard-installation?
> its priority standard i presume, which unless dselect/tasksel is
> changed means it will be installed and started by default. that can
> either be solved by ya postinst/debconf question or by lowering its
> priority to make the admin install it if they need it.
Well, then I would prefer lowering it's priority to match so that I only
gets intalled when the admin decides to install it. And if some people
are against a change of the priority, I think then we should use the
approach to change the postinst/debconf to ask a question about starting
portmap or not.
> the whole priority standard thing is really sticky, its supposed to
> create a basic command line system that a *nix guy will be comfortable
> with and not find much missing that triggers a `wtf!' the thing is
> nobody can agree on exactly what that is. (ie does it include emacs or
> not, does it include TeX or not?, does it include nfsd or not? does it
> include telnetd or not?......)
Well, I think the priority idea is good and useful, but we are currently
not thinking enough about security and check if our base-system is not
> > > 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
> don't be so sure, i recently saw someone on -devel get yelled at for
> saying portmap is not secure.
Well, I would suggest, that those people who yell me for this, either do
a audit of portmap and present it on -devel or shut up.
> > 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.
> i would hope so. i really don't see any reason why a default
> installation has to run things like portmap and statd by default.
> OpenBSD doesn't and it doesn't seem to hurt them any.
Well, do you know how FreeBSD or NetBSD handle this? I think we should
not try to create a second OpenBSD called OpenDebian, which is very
security aware, but we should care a bit more about our security.
Debian Developer and Quality Assurance Team Member
1024/26CC7853 31E6 A8CA 68FC 284F 7D16 63EC A9E6 67FF 26CC 7853