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 > 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. > 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). > 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.
Attachment:
smime.p7s
Description: S/MIME cryptographic signature