On 4/3/13 3:13 PM, Rob Weir wrote: > On Wed, Apr 3, 2013 at 9:06 AM, janI <j...@apache.org> wrote: > >> On 3 April 2013 14:39, Rob Weir <robw...@apache.org> wrote: >> >>> We're starting to take a deeper look at what is required to integrate >> code >>> signing into the OpenOffice build and release process. As you probably >> know >>> operating systems, especially Windows and MacOS, are now checking for >>> digital signatures and by default prevent users from installing programs >>> that are not signed. We see similar checks being integrated into >>> anti-virus scanners and even web browsers now. >>> >>> One of the things that has come out in discussions is how large a target >>> OpenOffice is, to hackers. We're on track to have 50 million downloads >> in >>> our first year. If someone is able to get a virus or a trojan into our >>> code, they have the ability to cause a huge amount of damage. And if we >>> are also signing our code, then this damage can propagate even faster, >>> since the OS's "let down their guard" somewhat when dealing with signed >>> code. (Signed code == trust). >>> >>> Of course, none of this has ever happened with OpenOffice, but with the >>> stature and reach we have, it is reasonable to believe that we could be a >>> target of opportunity for someone wishing to cause trouble. We should >>> always keep this in mind and make sure that we are taking reasonable >>> precautions to prevent this from happening. >>> >>> One vulnerability, in theory, is that we have over 100 committers (123 to >>> be exact) who have permission to modify the source code in Subversion. >>> Each account is protected by a self-selected passcode. It is not clear >> to >>> me that we even have requirements on password complexity or expiration >>> policies. In any case, the weakness of this approach is not necessarily >>> what you might think -- brute force attack on the password. If someone >>> wants to initiate a "spear phishing" attack against a committer, it would >>> be something like: >>> >>> 1) Standard phishing: a spoofed note from Apache Infra, with some >> invented >>> story that asks you to change your password but first enter your old one >>> for confirmation. It leads you to a fake, non-Apache website. >>> >>> 2) If you use the same passcode on multiple web services and one of them >> is >>> compromised, say by retrieving the passcode hashes, then it is easy to do >>> offline dictionary attacks (rainbow tables, etc.) and figure out your >>> Apache password. >>> >>> 3) If you lose control of your laptop, at a conference, bar, hotel, >>> whatever, even temporarily, someone can gain access to your Subversion >>> account, via applications that cache credentials, like TortoiseSVN. >>> >>> 4) Similar to #3, but by taking control of your laptop via remote means, >>> i.e., via a virus loaded on to your machine via another vulnerability. >>> >> >> None of these things have happened to us yet, but all of these things are >>> possible. >>> >>> So how do we reduce this risk? There are a few things we do or should be >>> doing already. >>> >>> 1) Be careful on the machines that you use Subversion from. Treat it >> like >>> a machine where you access your bank account from. If you are visiting >>> risky sites or downloading and installing software from dubious places, >>> then you are putting your Apache account at risk. >>> >>> 2) Use a high-complexity Apache passcode, one not used by you on any >> other >>> service. >>> >>> 3) Change your passcode periodically, say every 90 days. >>> >> >> 4) On laptops be sure to set a strong login password, but also where >>> available also a separate harddrive password. These should also be >> strong >>> passwords, not reused, and should be periodically changed. >>> >>> For those who are building binaries for distribution, the above guidance >> is >>> even more critical. >>> >>> Of course, we also protect the code through our CTR process. All active >>> coders should be subscribed to the commits list and should be reviewing >> the >>> changes that are made there. Trust the code, not the person. Remember, >> if >>> we ever are attacked then it will be through someone's compromised >>> account. So if you see an odd check-in, say, from Juergen, don't just >>> accept it saying "Juergen knows what he is doing". If it is odd, then it >>> should be challenged. >>> >>> All of the above should already be going on today. But I'd like to >> propose >>> one change to our current process that will, I think, greatly increase >>> security. This would be to restrict SVN authorization for the code to >> only >>> the subset of committers who are actively coding. We should give this >>> authorization freely to committers who request it. But today we have 123 >>> committers, some of whom have never used Subversion, and some (like me) >> who >>> edit /site and /ooo-site but never touch the code. So we probably have >> 90 >>> or more accounts that don't need access to the source code tree. Since >>> such used accounts are unlikely to be following the best practices >> outlined >>> above (changing passwords periodically, etc.) then they are even more >>> risky. We lose nothing by removing authorization for those users, in >> order >>> to reduce the risk profile. Of course, on request we can easily restore >>> access. But the idea would be to keep the bullets separate from the gun >> by >>> default, to reduce the risk of accidents. >>> >>> One way of implementing this would be to look at all commits for the >> past 6 >>> months (or 1 year?) and remove authorization on /trunk, /tag and >> /branches >>> for those who have not made commits. But preserve authorization for the >>> website directories. >>> >> >> With the knowledge I have, it should be no problem making 2 types of >> committers, but I am not sure it would really fit the "apache way". >> >> > In practice we already have three kinds of committers. The problem is this > is not reflected in the way we assign SVN authorizations. > > 1) We have programmers who work on the code. This is a small fraction of > the total number of committers > > 2) We have website content authors and designers who work on the website > content, either directly via SVN or via the CMS. They never touch the > source code. > > 3) We have those who are voted in as committers and might access other, non > SVN systems. They use their Apache ID's to write blog posts, access Pootle > directly, or maybe even just the SMTP servers. But they never touch SVN at > all. > > But today we treat all three groups the same, and assign them authorization > to change the source code. That is 123 people today, but I can see this > easily growing to 150 or 200 this year. > > Think if it this way: we don't automatically give committers a blog > account when they become a committer. They need to request it. No one > says this is against the Apache Way. So why would we give someone rights > to the source code, something far riskier, automatically, even if they are > not a programmer? The risk of that seems out of alignment with the > benefit. IMHO.
I see also no problem if we handle it more careful and give svn access to the code on demand only. Nobody should take it personal and we will do no further selection or checking before we grant the access to a committer I think. I see no problem here but understand the idea behind this proposal. Any serious committer will understand this and will probably support the idea. Any committer can give the answer by asking the question if she/he needs the svn access to the code or not. It is not really a limitation. I don't think it's a big issue. Juergen > > -Rob > > >> In my opinion, it is fair to say, that if a committer has not made any >> commits for 6 months, the commit access is placed on hold until requested. >> But we have to very carefull not make it even harder to become/be >> committer, compare us a bit with LO, there I can have commit access within >> less than a day. >> >> >> rgds >> jan I >> >> >>> >>> Thoughts? >>> >>> -Rob >>> >> > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
