Hey again. On Wed, 2014-10-29 at 22:07 -0700, Russ Allbery wrote: > If you don't read the mail, you're going to miss some really vital > information, like packages that we are no longer supporting. I am very > much opposed to giving people the impression they can just monitor the > security archive and not read the DSAs. All that kind of stuff should IMO rather move to some machine controlled system as well. I mean, in that area (package installation, upgrade, maintenance) we have actually several things which should be goals: - Debian shouldn't ship packages that enable network listening services per default (unless perhaps very few special examples). At least this services should try to come in a localhost-only fashion. Not having packages like postgresql/httpd/etc. start and initialise automatically would actually be the natural way and... well I don't know what suse does but I think the other distros don't do that thing. - Debian should ship a default set of firewall rules. Are we the only distro which doesn't do this? I mean a basic ruleset which drops incoming, accepts outgoing and accepts related,establised is so easy to do... and it would help for all those cases where services are started but not yet finally configured/secured by the admin. - There should be a central system, that checks whether something needs to be restarted after package upgrades. Some package just unconditionally restart their services on upgrade (even when there is no technical need to do so), some (e.g. libc) check whether other packages need to be restarted. I think this should rather be moved to something like needrestart, even though needrestart currently only looks at services, and not at any other processes which also make use of old libraries/etc. Apart from that, a package should only restart its own service, when there is a strict technical need that stop/start needs to be made before/after the upgrade, e.g. one should be able to upgrade sshd without the need to restart it. The decision whether restarts are made, should then be centrally delegated to e.g. needrestart. - And last but not least to address your concerns about packages which are no longer security supported. For that we already have debian-security-support... and it should ultimately be the canonical point to handle this question. If you still think that the DSAs themselves need to be distributed to the users in a secure way (which is an idea I'd support) than this should perhaps go to the package as well. Like a file DSA.Debian, similar in style to the NEWS.Debian and it could be displayed by apt-listchanges. > > To be honest, it's really awkward to see how much all this is apparently > > fought against. > I don't think people are fighting against you. First I've said how much *all this* is fought, and not how much *I* am fought ;-) But, seriously?! Remember our last dance about strengthening crypto algos in Debian? It wasn't that I proposed to implement something impossible or completely awkward, just to take a concentrated effort to phase out the usage of algos (or key sizes or DH group sizes, etc.) which have already known flaws - or at least to disable them from being used automatically. And history simply proves me right, that it's better to do this proactively, even when something is still safe (for the very moment) or when upstream is slow. Not doing this is, why we still have MD5 in several places, where it's probably not the best idea to use it. The typical arguments then are... "xyz is still safe", which often turns out to be a "for a few months or years at best"; or "we use only xyz for performance reasons", which is kind of a strange argument in all those places where performance isn't crucial and where a few extra ms that e.g. SH512 needs over SHA256 just don't matter. And actually I got several mails by people and other cryptographers after that last discussion, which supported my views and were kinda disturbed of the what has been styled as a commonly accepted opinion amongst cryptographers. Or remember the thing with the downloader packages? And for this issue it's the same? I think the current top argument is "we don't need to do anything, since LWN provides people with secure advisories". So please apologise me if I sometimes get the impressions that people rather just search for reasons not to do something. And so far, noone has really given me a solid technical argument why and of these issues wouldn't be real. The only "arguments" are rather things like "most users don't care" or things at that level. E.g. to quote yourself from below: "esoteric security gains compared to all the other things that they could be working on" The funny thin it that one gets arguments like these in all these fields, and an attacker is probably not too smug to exploit such a meta-security-hole just because Debian calls it esoteric. :-( > I think people are > unconvinced that all of the machinery that you want to put in place is > worth it Well actually the machinery is already there isn't it? Someone had the great idea to add validity times to the Release files - it's just not used well enough to match our typical upgrade release periods. > for some pretty marginal and esoteric security gains compared to > all the other things that they could be working on. An attacker will typically always attack the weakest chain element in security. If he can easily break an algo, he'll do that. If not, but he can do social engineering, there he goes. If he can run a meta-attack, why not? And if he's powerful enough (governments) and finds no other way, he simply comes after you, beats you up and tortures you so severely until you give him everything he wants with pleasure. Software will always have bugs, government will always be stronger than you, people will always be tricked into social engineering, and sooner or later, all algorithms (unless OTP if implemented correctly) will be broken. But none of this means that we shouldn't try to make each single chain stronger if we can. Sure we could work on other things, start auditing software for example,... but this won't happen just because we drop work on meta-attacks. > And, on top of that, > you argue for them by writing encyclopedic tomes that are kind of hard to > digest. Hehe, *guily*... well I guess that comes with fighting windmills,... either one gives up, which I sooner or later do, or at least you try to argue, explain, etc. > Also, most of the people responding to you are not people who have the > power to implement the changes you want. Uhm agreed,... but neither have I. These things I've brought up in the recent years aren't single holes in software XYZ which can be fixed by avoiding a buffer overrun. By their nature they must be dealt with on a larger scale. But I don't think that it's impossible to handle them. Take the issue with the downloader packages,... if people would just agree on actually taking action on this, one could add it to Debian Policy, add some heuristics to lintian which check for potential downloaders in packages and give a small how-to to maintainers how to correctly deal with that. > I don't know that you're going to like this advice, and I know it's kind > of unsatisfying, but you keep picking up causes that are structured so as > to require people other than you to go do work. Sure, that's the easiest?! ;-) No seriously,... you don't know what efforts I make to improve security in those areas where I can do this on my own, do you? btw: I would't say that identifying such meta-attacks and thinking about solutions is like no work. o.O > Can you find a solution > to one of these security issues that you see that you can just fix > yourself? Like, in this case, a better tool for monitoring security > status of packages? Russ, you should perhaps rethink that whole issue with the validity times. By definition there is no way[0] to improve one's security, without having the shorter validity times (and thus more often the guaranteed, signed statement from e.g. Debian "yes, all your packages are still up to date, no new security upgrades in the meantime). > There is *way* more to be done in Debian than we can ever possibly > accomplish, particularly in the security arena. People are prioritizing. > You get to pick your own priorities, but so does everyone else. Your > priorities aren't in line with the people who have to make the changes you > want to see. That's super frustrating, but that doesn't mean they're > obligated to change their priorities. There are limited hours in the day; > some very good ideas are not going to get done. If you are getting > frustrated by being blocked on other people... work on things that don't > block on other people. After you do some of that, you'll often find that > other people are more willing to jump into shared projects with you. Sure... but I think in none of these issues we ever came to the place where the question was "who starts with the concrete work now", did we? Agreeing on something like "we want to regulate downloader packages according to the following rules" or "we want to take countermeasures against downgrade/blocking attacks" would already be half the goal. Even if the people in charge don't have time immediately (or ever) this would at least enable others to work on this one by one. But no one can expect non-core-people to deeply work into complex systems like apt or the mirror infrastructure, just to be told "na we don't want to do that at all" when they'd provide first patches. > > I really wonder how you can do that with the above means. > I read the mailing list. In practice, it works fine. I questioned how you make sure, that you actually get all the mails and that Mallory isn't blocking those that apply to you. But when this is just an esoteric threat model for you, then of course reading the lists will be fine. Regards, Chris. [0] Unless perhaps you give me a direct secure path to the master mirrors. Which would probably mean TLS... and well let's say: I'm happy that secure APT isn't dependant/based on TLS ;-)
Attachment:
smime.p7s
Description: S/MIME cryptographic signature