On Thu, Apr 4, 2013 at 2:27 PM, Dennis E. Hamilton <dennis.hamil...@acm.org>wrote:
> If the problem is that there are abandoned Apache credentials out there > for the taking, the solution is to deal with the inactive committers and > revocation of those credentials. And to assume that some sudden > resuscitation can go unnoticed strikes me as not very plausible. (It > strikes me as far more likely that such committers have > lost/forgotten/mislaid their credentials and having them fall into the > wrong hands is probably not a material risk.) The claim that there is > automatic inclusion of malicious code introduced by a previously silent > committer seems unsupportable. > > Again, you are showing ignorance of the likely attack vectors. Just because I do not use or have forgotted my Apache password does not mean my account is secure. I could have an easily guessed password, or a password that is identical to one used another another system that is comprised. In fact the later is one of the most-likely attack-vectors. I set my Apache password to something that is the same as some online retailer or other service. Their password hashes are compromised. They reset their passwords and send out a note to their users advising them to reset all passwords on sites that used the same password. But the inactive committer neglects to do that. Simple correlation of names or email addresses leads them directly to Apache. See for example: http://thenextweb.com/socialmedia/2012/06/06/bad-day-for-linkedin-6-5-million-hashed-passwords-reportedly-leaked-change-yours-now/ Now how many inactive committers do you think have LinkedIn accounts? Hmm... maybe *alll of them*. > Whatever is done has to work without injury to "the Apache Way." > > Properly understood, yes. Misunderstood it can be used as an excuse for any form of ossification. > Furthermore, modifications to code on the SVN are always reversible. That > is considered the main line of defense for inappropriate commits to the > SVN. (Use of the web site to create an exploit against browsers is a > different problem that might need to be looked into. That's more immediate > than attempting to get a patch by a watchful release manager. And, as far > as I know, all web site updates also show up on the commit logs.) > > Again, you are assuming that the attack is seen for what it is. That does not seem like what an purposeful hacker would do, does it? > We've been taken through this rationale before. Why is it being raised > anew? Has there been an actual exploit? > > Again, my house has not burned down either, so why should I care about fire safety? > I am having trouble accepting that there is a plausible risk of undetected > exploit here, versus the kinds of attacks that could have far more serious > consequences. There are exploits that are already far easier without > anything happening at the ASF end of things. Having reliable code > signatures would give us a way to discourage and repudiate the continuing > reliance on exploit-vulnerable downloads that folks are now being exposed > to. There are places in AOO worthy of investigation to limit the ways an > AOO install might be an exploit enabler that are probably more important > than the proposed defense of the SVN by requiring committer opt-in. I > assume the opt-in should be requested using the apache @a.o e-mail (will > that be part of the rules)? Will there be some e-mail confirmation > requirement to protect against the account *already* having been > compromised? Otherwise, this is all self-prescribed placebo. > > I believe that Infra is less-likely to accept code signing if we're not taking reasonable precautions to ensure that our SVN tree is secure. My opinion. If I were in their shoes I certainly would want these extra precautions to cover the extra risks that come with code signing. Since signed code can slip onto a machine more easily, without triggering warnings from the OS, anti-virus or browser, this makes our SVN tree a bigger target, not a smaller one. > I shall not say anything further about whether or not this is done. While > it may set some minds at ease, I think it is not doing much in terms of > where the plausible threats already are and where opportunistic exploits > may already be happening. > > As you know, we find vulnerabilities in AOO on a regular basis, and fix them. I think that proves my point. Every single one of these vulnerabilities passed through the eyes of at least one developer, and perhaps more, and escaped unnoticed. And these were accidental. So we should be far more humble about our ability to notice an intentionally-placed vulnerability. If we don't catch 100% of the accidents, what makes us think we'd catch the hacker? Something to think about... Regards, -Rob > - Dennis > > PS: It seems to me that the special authz arrangements and SVN areas for > security fixes has to do with avoiding premature disclosure of a known > vulnerability that is already in released code. The list is private and > moderated for obvious reasons. Likewise, the private @oo.a.o is for > preserving the confidentiality of certain conversations (and that authz is > for related material on the SVN). There is no confidentiality to protect > in the public code base. That's the point. > > -----Original Message----- > From: Rob Weir [mailto:robw...@apache.org] > Sent: Thursday, April 04, 2013 09:44 > To: dev@openoffice.apache.org > Subject: Re: Proposal: Improve security by limiting committer access in SVN > > On Thu, Apr 4, 2013 at 11:57 AM, Andrea Pescetti <pesce...@apache.org > >wrote: > > > Dave Fisher wrote: > > > >> Let's focus only on adding one new authz list for the code tree. > >> Call it openoffice-coders and populate it with those who HAVE any > >> commit activity in the current code tree. > >> > > > > I checked feasibility with Infra. Summary: > > > > 1) LDAP is not the solution. Rule it out. > > > > 2) The only possible solution would be an authz rule like suggested by > > Dave here; however, Infra quite discourages it, mainly for maintenance > > reasons. This leads me to think we would need some good justifications > for > > implementing this. > > > > > Would Infra need to maintain the authz , or would that be something that > you do? > > Note: we already have a separate authz for openoffice-security and > openoffice-pmc, for the same reasons -- there are some things that should > not be authorized for all committers. Going from 3 authz's to 4 is not > unreasonable, IMHO. > > > > 3) If the justification is security, then there are other privileges to > > monitor. Namely, every committer has shell access to people.apache.org, > > authenticated access to the Apache SMTP server and CMS privileges for the > > openoffice.org website, including publish operations. > > > > > > None of these get automatically included in releases that are installed on > tens of millions of machines. So I would not ask for additional controls > here. I'm asking only for additional controls on source code. > > > > For the record, the Subversion project has complex rules like Rob pointed > > out; but it's only a "social enforcement", i.e., all committers respect > > those limitations by their own choice; if you look at the technical > level, > > every committer (all Apache committers) can commit code to the Subversion > > subtree. > > > > > I'm not concerned with things where social enforcement would work. It is > not a concern that someone unqualified makes a change to the source code > merely because they have permissions. The issue is that the product is so > well-known and so broadly installed that it is automatically a target for > hackers, and with so many authorized user accounts from committers who are > not actively coding, or never were, that these authoriziations are > particularly vulnerable to compromise. > > I believe this a serious issue and we act irresponsibly and do a disservice > to our users if we treat this merely as an inconvenience or a social faux > pas. > > -Rob > > > > Regards, > > Andrea. > > > > > > ------------------------------**------------------------------**--------- > > To unsubscribe, e-mail: dev-unsubscribe@openoffice.**apache.org< > dev-unsubscr...@openoffice.apache.org> > > For additional commands, e-mail: dev-h...@openoffice.apache.org > > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org > For additional commands, e-mail: dev-h...@openoffice.apache.org > >
