Ian G wrote: > On Saturday 28 May 2005 02:17, Ka-Ping Yee wrote: > >>On Fri, 27 May 2005, Ian G wrote: >> >>>And, both petname and trustbar were roundly rejected >>>by the Mozilla security community. >> >>Is there a foundation for this statement? I would really >>like to learn what constitutes the Mozilla security community >>and what constitutes the authority to speak for it.
There are several things going on with regards to security and the community/communities around it. One way to look at it would be this: * There is one Mozilla Foundation member whose job is to handle all things about security * There is a small group of people who are on the security email alias. They get all the mails when new security bugs are filed as well as emailed to the security email address. They discuss these new reports. * There is the Mozilla Security Group, which is again slightly larger than the previous group. This group discusses security issues that are broader than just a simple buffer overflow - security policies if you will. There are discussions about new security bugs that cause a respin of a product. See members at http://www.mozilla.org/projects/security/secgrouplist.html * There are the people who have access to bugs marked as security sensitive - everyone in the Mozilla Security Group + selected others. * There are people who discuss security in this newsgroup, and the crypto newsgroup, and other public forums * Module owners, reviewers (and more generally, coders) think about security every day when they write fixes, create new features, and review code. * There are researchers using Mozilla to research new defenses against security threats etc. All of these groups have various authority levels. I think the security authority you are thinking about would be the Mozilla Security Group. > 1. There is no overarching or cross-team security > process. Security as a directorate in the whole - as it > exists in security projects like the BSDs and in the > terms that you or I would look for - does not exist. There is. It could be better, of course. > There is no identifiable or organised security > community other than these two mailgroups (crypto > and security) which are essentially talking shops > and the "security team" mentioned below. There is, see my bullet points above. > 2. What fills the gap of security process is the models. > These are implemented as is. By this I mean the > oft-heard retort of "that's not in the standard" as an > answer to a security question with the expectation > that this is a sufficient answer to a security question. I don't understand this. > 3. The application teams themselves make the security > decisions on how to implement models. The obvious > problem here is that the application teams have little > experience in wider security practice and simply adopt > the models presented by "standards" regardless of > needs and security of the users. This is most clearly > seen in technical terms with the S/MIME project (where > implementation of the model leads to bemusingly few > results), and in political terms with the HTTPS secure > browsing / phishing debate (where implementation of > the model clashes with the evident security breach). The Mozilla Security Group has been involved with the https and phishing issues, and I would say has some experience dealing with security in general. These are tricky problems, and NOBODY has solved them perfectly yet. There have been some promising developments and ideas, though. > 4. Security decisions are taken in secret. The "security > team" is a basically an approve-only group, so it is > essentially a closed shop and the squeaky wheel of > non-model security isn't welcome. > > [ In one of Frank's earlier lives, he wrote the policy > that explicates the closed and secret security process. > Basically he documented what was politically possible, > he wasn't the one pushing that as his own preferences. ] > > The problem with secrecy and closed shops is that > actions then are indistinguishable from no actions, > difficult choices are indistinguishable from no choices, > and if there are any other problems then that process > can fail very easily. > > In fact, the most likely result of a secret process is > a failure as there is no feedback to point out the > problems that all processes have. C.f., Shmoo, > where the security team didn't make the decision. There is always the schism between full disclosure immediately and always keeping everything secret and everything between these two extremes. Mozilla has a well known security policy, so no more on that. And I think you are wrong. As Mozilla's policy states, things will become public reasonably quickly. And there is always the possibility that anyone involved in the security issue goes public if they are unhappy about things, which they can do at any point. And after the issue has become public, everyone can review how the process and people worked (maybe not all aspects of it, but they can determine if a fix was done in a reasonable time frame, for example). > 5. The security team concentrates on bug fixing, > code audits, patches and the like. In my time on > these lists, I've never heard a reference to the > security team in any active sense, and it was > a year before I'd even realised there might be > another group. In all probability, they are sitting > there doing good work and believing that what > happens on the security mail groups is irrelevant > so are keeping the thing quiet. > > (Now, this is not meant to be a criticism. Someone's got > to fix the bugs, Lord knows I wish I had some team to fix > my security bugs. But, to say that this team fulfills the > wider/higher needs of security beyond bug fixing is a > stretch.) There is discussion on the closed lists. Some of it could be here, but some discussion is triggered in response to just reported vulnerability and therefore can not be discussed publicly until the security policy allows it. And look at what Gervase has done on this list, very much public. Audits etc. don't end up discussed here - what they find will be fixed by the coders and often don't need discussion here. > 6. One big important part is the bugzilla system. > That is a good focussing tool for bug-level issues. > But it also acts as a control system, it is impenetrable > to outsiders, and it does not admit wider issues. So > it works well at the tactical bug level but is actually > a negative force at the strategic issues level. I don't understand how you can draw that conclusion. Bugzilla is open - there are very few security bugs that are closed while they are being worked on. > But Mozilla itself presents its browser as the secure > alternate and users have been trained to perceive > of the browser as protecting them. That's not in > accord with reality. Mozilla is just the new kid on > the block as far as other browsers are concerned, > and the users are starting to get the idea that the > browser is not protecting them. So there is a > realignment of expectations due here. It seems like you are implying that if Mozilla was older/had more market share, the security vulnerabilities would show it is just as insecure as other products. Show us the data that would imply so, because as far as I know the data shows otherwise. Simply being popular does not mean being insecure. Mozilla has made many architectural decisions which have resulted in a more secure product. A simple example is ActiveX. > In terms of security as we know it, the issue is that > Mozilla is a "models" project and the models are > sacrosanct (this is the same with all browser projects). > Until the clash between the models and security is > addressed, Mozilla cannot be a security project, IMO. I don't really understand the above. But of course Mozilla is not a security project. There is the Firefox browser project, Thunderbird email project etc. They all deal with security, some more (NSS), some less. Still, I'd say Mozilla spends more time thinking about security than many other projects. > Three things were evident that support this post on > wider security: 1) it took a long time and during > that period there was silence, 2) the decision taken > was very simplistic, maybe knee-jerk, and 3) the > decision was taken by the "staff" group and not by > anyone with "security" in their name. Staff consults with security people on security issues. > PS3: If you look at the occasional security pronouncements > in the press by spokespeople for Mozilla then you can see > that they are basically reactive, with no substance. It's > not their fault, there's nobody there to advise them on > what matters and where to go and what to say. They > basically see themselves as locked in a battle of words > with Microsoft over security blah blah. What they don't > realise is that they are fighting on Microsoft's ground, > and that means they lose eventually. Why would Mitchell Baker say in a press release that we are thinking about this and that security improvement? It does not belong in that context. And you seem to be conveniently forgetting some recent security improvements in the browser which were Mozilla initiatives, and new ones that are being discussed. Also, there are things in the security arena where all the browser vendors should work together. For example, the lock icon is basically the same in all browsers and users know to expect it. There are several areas where they have cooperated in the past, and this is likely to continue. > But there is only one Frank, and as he is busy on > the CA policy project he's already committed. In this > sense, the CA policy project is proving to be very > expensive, and holding it up is the worst thing that > could be done. If I was Microsoft, I'd pick and poke > at the CA policy project because of the damage it > does in holding it up from other more important things > like security. I don't understand what Microsoft has to do with Mozilla CA policy. And the CA policy is about security - trust is a large part of security work. -- Heikki Toivonen _______________________________________________ Mozilla-security mailing list Mozilla-security@mozilla.org http://mail.mozilla.org/listinfo/mozilla-security
