Re: Open then gates
Am Samstag 15 Mai 2010, 02:55:40 schrieb Christoph Anton Mitterer:
> On Fri, 2010-05-14 at 17:16 -0700, Russ Allbery wrote:
> > Why do you have this strong of a reaction to this change?
>
> Because it shows - what I consider to be a - trend in Debian recently
> that security dying more and more (again, I do not mean the work of the
> Security Team).
>
> - Debian does not ship with hardening stuff per default (e.g. kernels
> with PaX patches).
> Of course all this can be done manually, but I think at least some of
> them should be default, and an admin/user should have to actively
> disable them (which usually means that he has at least some knowledge of
> what he's doing).
> But I see that especially things like PaX will yield in many different
> opinions about whether this should be included per default or not.
>
> - Many packages ship with configuration that is either really insecure
> or that could be at least hardened a lot.
> Some examples: sysctl values could be more tightened or there could be
> restrictive set of default iptables rules, portmap recently went aways
> from the default to bind to loopback only (IIRC), ejabberd generally
> opens some erlang control ports which should be blocked by
> netfilter, /etc/defaults/nfs-common enables services which are not
> required, depending on which NFS version you're using,... etc. etc. (and
> no I do not mean to offend or point with the finger on the respective
> maitainers).
>
>
> - Many packages contain code which does things that is questionable from
> a security point of view:
> 1) Some of them download and install data from the web (fonts, sun jdk
> doc, firmware, etc.) but do not verify them, therefore bypassing
> Debian's great secure apt system
> 2) Some do this by intention by installing plugins (firefox, josm, etc
> etc.) Of course it's probably bad to completely disable this, but the
> user is not even warned, that he gets code, which is perhaps completely
> unsecured (transmitted) and especially not covered by the security team.
>
>
> - et cetera
In that case why dont we as security aware people and people that think that
more hardened defaults should be applied, go out and file bugs against them
providing atomic patches that the maintainer can review and then either apply
or talk back to the person filing the bug why this is not applicable for this
situation.
I know we have a security team in Debian, but sometimes the presence of just
an asorted list of people caring about one issue while the rest of the teams
overlook this area might be more harmfull, than the issues in themselfs.
> > you must not understand how
> > user-private groups work at all
>
> Well I guess I do,...
>
> > and therefore think that they form some
> >
> > sort of security vulnerability.
>
> In principle yes,... but
> 1) Im not sure whether we see all possible side effects and follow-ups
> of this. There might be scripts, programs etc. which do not correctly
> set their own (secure) unit mask and thus create files which are to
> open. This may even apply to system services. Even in upcoming versions.
> 2) Users may add other user to their own group, thinking that they've
> removed group write permissions on all files, where they do not want to
> allow this. But new files may be created later where this could be
> security critical.
> 3) I'd generally say, no other user should be every trusted. Never!
> E.g. You wouldn't (usually) create firewall rules that blacklist ports
> but such rules which whitelists them. The same should apply here, even a
> trusted user (which was added to the UPG) should generally not be
> trusted but only selectively for certain files.
+1
> > If you have more specific objections other than not understanding the way
> > they work, I'm afraid you're going to have to be more specific, because
> > we can't read your mind. I think many people participating in this
> > thread would be open to being persuaded by a good argument. But you
> > need to present one.
>
> See above,... I know that these are no concrete rock solid points, but I
> guess we just introduce a insecure way of doing something which should
> not be done like this.
> Personally I'd even say we should choose a default umask of 077.
>
> > My personal experience with portmap is that, for most systems, I don't
> > want it installed at all, and for those systems where I need it
> > installed, I also need it to respond to public network interfaces
> > because it's there in order to provide rendezvous service for network
> > services.
>
> You need for example for fam, where it's fully enough to have it bound
> to loopback.
> You need it for nfs-common... now you say one probably want's to have it
> then listening to all interfaces,... but I can imagine that people
> install it just because nfs is such a common thing and they want to have
> the manpages in place.
>
> > I appreciate
> > Debian's committment to allowing portmap to not be installed at all so
> > that I can purge it completely on most systems.
> > A package that isn't even
> > installed is better than a package that's installed and listening to
> > localhost.
>
> Of course,...
> But maybe on needs NFS, and needs it just a several places, or very
> rarely. Such people want to have the packages installed, but perhaps
> disable it (portmap) per default and just enable it, when they really
> need it?
>
> > Judging from the changelog of portmap, there's been a *lot* of discussion
> > and angst over this decision over the years, and it wasn't one that was
> > made easily. I think you're overstating this a bit as an example of a
> > bad direction.
>
> Yes,.. but why "opening" something which does not need to be "open".
> If a user/admin really needs it, he'll see that something does not work,
> find out why, and then enables/opens it.... but _only_ if it's really
> required.
> That's a major idea of shipping hardened configurations, I guess.
> > Have you filed bugs?
>
> Mostly,... but sometimes (!), maintainers to not react at all or simply
> say a change is not needed (I've tried for example to convince some of
> them to not use MD5 but something better, without success).
> Sometimes they simply do not want to make things more hardened/secure as
> this would "break" things which currently work out of the box (which I
> can of course understand to some point).
Thats sad and a shame.
> > Could you point people at some examples?
>
> See the examples I've provided in this mails,... e.g. sysctl hardening,
> or the packages download and install unverified stuff issue.
> I've started a somewhat larger discussion about that issue on the d-d
> list here.
>
>
>
> Cheers,
> Chris.
Reply to: