Ben Bucksch wrote: > Frank Hecker wrote: <snip> >> * A person who reports a security bug will have continued access >> to all Bugzilla activities associated with that bug, even if the >> bug is marked "Security-Sensitive." >> * Any other persons may be given access to a particular security >> bug, by someone else (who does have access) adding them to the >> CC list for that bug. >> > What, if that bug or strongly related topics are discussed on the > mailing list? IMO, there should be a policy that those people are added > to the (email) cc list of such discussions.
That's a reasonable request; however note that there's no technical way to ensure that a bug reporter gets cc-ed on all correspondence. See also my comments below on this. > Rationale: > > * Bugzilla is not an ideal platform for longer discussions, thus it > sometimes makes sense to move a discussion which started in a bug > to a mailing list. But Bugzilla is a good platform for discussions which are centered specifically around a particular bug. As I said above, from a technical point of view we can't force people to cc the bug reporter on all email that might be relevant to their bug. At best we can suggest that this be done. > * Members of the security group might be tempted to move discussions > to the list specifically to exclude the reporter or other people > on the cc list. I don't think, this should happen, unless the > group at large decides so for good reasons. Again, no policy can absolutely prevent people from moving discussions to more private forums (e.g., the security bug list, or person-to-person email) in order to keep information away from the bug reporter. But if a bug reporter thinks that others are deliberately withholding information from them then the reporter will have the power to go ahead and open the bug report to full public view. That's a major reason why we proposed having the bug reporter officially drive disclosure -- to act as a check on any tendency of people in the security bug group to keep information confidential any more than is reasonable. > Involvement of the original reporter is essential, because sometimes, he > is the only one involved who is really interested in getting the bug > fixed right. (This is nothing against anybody working on Mozilla, but a > general (sad) statement).) I agree 100%. That is why this policy tries to put the bug reporter at the center of the process of investigating and resolving security bugs, as opposed to letting people submit bug reports and then forcing them to wait "on the outside" while other people look at the bugs and decide what information (if any) to release. One major goal of this policy is to give potential reporters of security bugs a reason to work within the Mozilla project processes, as opposed to putting potential reporters in a position where they have to work outside those processes. Note that this applies not only to potential bug reporters who work independently, but also potential bug reporters who are employed by big companies with managers who are sensitive releasing information about security bugs. IMO there are at least two ways a policy like this can fail: First, consider people working with Mozilla security issues who favor more disclosure and do not have to worry about what their employers think. If those people believe that their bug reports to the Mozilla project will be put in a "black hole" and never be resolved or disclosed, then they will boycott the Mozilla project processes and use some more public process. The result will be that the Mozilla project might as well have not had its own processes and policies, since they would be going unused. Second, consider people working with Mozilla security issues whose employers are sensitive about disclosure. (Note that I'm not just thinking of Netscape here; this could apply to any medium-to-large company shipping Mozilla-based commercial products.) If the policy arbitrarily forces disclosure under some fixed and inflexible criteria, I suspect what will happen is that employees of those companies will be less likely to report to the Mozilla project any security-related bugs they find, and less likely to work with others in resolving bugs reported by others -- they'll just work the bugs privately within the confines of their own company, and never release any information at all if they can possibly avoid it. The result is that the Mozilla project isn't able to take advantage of the expertise of a number of people who otherwise might have added a lot of value, and we lose opportunities for cooperation across multiple vendors of Mozilla-based products. >> The criteria for membership in the Mozilla security bug group are as >> follows: >> >> * The applicant must be trusted by those already in the group. >> * The applicant should have a legitimate purpose for wishing to >> join the group. >> > What is "legitimate"? "I want to fix a few security bugs."? "I want to > do a securty-audit of Mozilla."? That's up to the security module owner, peers, and the other members of the security bug group to debate. Assuming that the person was trusted, I'd consider both of the examples you gave to be legitimate reasons for applying to join the group. Examples of IMO non-legitimate reasons would include "I just think it would be cool to see confidential information", "I'm not willing to help out, but I have an absolute right to see all this information", and so on. (I'm presuming that no one would be stupid enough to give a reason like "I'm looking for vulnerabilities I can exploit for malicious purposes". But you never know...) Again, the intent is that the barrier to membership in the security bug group be relatively low, and that the number of people in the group be relatively large. >> We reserve the right to cap the membership at some reasonable level, >> either by refusing new applications or (if necessary and appropriate) >> by removing some existing members of the security bug group to make >> room for new ones. >> > But that "reasonable" must depend on the size of the Mozilla project. > The more people You didn't finish your thought. But to give you an example, IMO the security bug group could easily grow to be several dozen people in size. Remember, the security bug group is *not* intended to be a small "tiger team" with very restricted membership. To the extent that we need a small core team to coordinate actitivities and take the lead roles, we can use the security module owner and peers for that purpose. But the intent is that all members of the security bug group have the same access to information as do the module owner and peers. >> Mozilla distributors participating in security bug group activities >> can mention in their release notes that a security bug has been fixed, >> but we ask that they be vague and not describe the exploit in detail. >> (For example, a release note could say, "This release fixes a serious >> security bug involving HTML form submission.") >> > I strongly believe that each new bug reported confidentally should > *immediately* be reported in a vage way to the public. See an older post > of mine for details. > > E.g., we create a newsgroup .security-announce and whenever a security > bug gets reported, a certain person has the reposibility of posting a > summary (without details about how to exploit it) to that group. > > I believe that the public has at least the right to know that there is a > bug and roughly where it is. This allows people to protect themselves, > e.g. by disabling JavaScript or avoiding to use Mozilla to submit > sensitive information in https HTML forms or whatever. Your position is not unreasonable, and there are others who share your views (including at least one mozilla.org staff person). This issue came up when we were discussing the draft policy among mozilla.org staff. My personal position on this question is that I don't want mozilla.org to impose a blanket policy. Here's what I wrote in a staff-internal email about this general question: "I have no objection to the security [bug] group deciding on a case-by-case basis to do public warnings of vulnerabilities in advance of having a fix in hand. I also have no objection to the idea of mozilla.org considering in some extraordinary cases whether to overrule the security [bug] group and issue a public warning over the objections of people in the group. "What I object to is making it a precondition of forming the security [bug] group that mozilla.org mandate such warnings as a universal policy. While this may be the right thing to do in theory, in practice I think mandating such a policy would potentially lead to some Mozilla distributors choosing not to participate in the security group, and doing things on their own behind closed doors. And that in turn potentially lessens the benefit to everyone (including users) of having a security [bug] group in the first place. I think this is arguably a case where "the ideal is the enemy of the good", as the saying goes, and I would rather have the good and not worry about the ideal for now, than go for the ideal and risk losing the good. "And I would add that if we punt on this issue, nothing prevents us from revisiting it later once the security [bug] group is up and running and we see how things go. It may be that the cases in which early warnings are called for are so frequent that at some point the people in the security [bug group] will decide to do them as a standard policy. But IMO that's a decision for the future, not a decision that needs to be made now, or should be made now." >> The original reporter of a security bug has the primary responsibility >> for deciding when that bug will be made public; disclosure is done by >> clearing the bug's "Security-Sensitive" flag, after which the bug will >> revert to being an ordinary bug. >> > I think that there should be mozilla.org-imposed limits to how long a > bug will be kept confidential. There are such limits, at least in theory. mozilla.org reserves the right to intervene at some point and force disclosure. However I don't believe in specifying beforehand an exact time limit; I would prefer that this be handled on a case-by-case basis. > To make my point, I see absolutely no reason to keep the bug confidental > after distributors issued release some time after the bug has been > reported. Even the least security-savvy computer user will be xx to hear > that his browser vendor released a product with severe security bugs in > it, which were known for some time. I couldn't find "xx" in my Deutsch-English dictionary. I presume it means something like "#@?&!" :-) > If security-concious people get to > know about that, it drives them up the wall and they generally loose all > trust in that vendor. I don't think, mozilla.org should support such > irresponsible treatment of security bugs. As I said above, mozilla.org is prepared to step in if we feel that a particular vendor is abusing the system and trying to keep a bug confidential for an unreasonably long period of time. > (OK, there is a problem to determine when all distributors released a > new product after a bug has been found. Maybe we can settle at > mozilla.org stable releases or something like that.) See where the complications begin to arise? :-) That's why it's hard to come up with a single absolute criterion. > I go even further than say that mozilla.org should put some directed > pressure on its developers by making security bugs public after some > pre-defined amount of time. The pressure of publicity is the only > reliable way I know to get people fix security bugs in time and > correctly. Apart from pressure, publicity also gives more people a > chance to fix a bug. I agree. Again, that's why you as a bug reporter should and will have the power to force disclosure of Bugzilla data relating to your bug. The problems you're concerned about are mainly problems when the bug reporter is a Mozilla vendor with an incentive to keep the bug confidential. They can take advantage of their position as a bug reporter to try to keep the bug private. There are at least two ways to address this problem: First, mozilla.org (and/or the security module owner) can step in and force disclosure over their objections. Second, if the same bug gets reported by someone else then it can be worked on and disclosed independent of the recalcitrant vendor. (That's a major reason why the policy specifies that bug duplicates are treated as separate bugs are far as disclosure is concerned.) > I don't argue more, because that has been discussed extensively before > and I wonder, why this didn't make it in the mozilla.org policy draft. Because there's not universal agreement with either your position or the opposite of your position, and thus we decided to leave this question up to the security bug group. > The current scheme (see also my replies below) practically gives > Netscape the chance to keep security bugs confidental as long as it > pleases. We're not talking about continuing the current "Netscape Confidential" scheme. Under the proposed scheme Netscape would not have any formal power to keep bugs confidential, except for bugs that are reported by employees of Netscape; the same applies to any other Mozilla vendor. >> We believe that investing this power and responsibility in the bug >> reporter simply acknowledges reality: >> > Indeed. This "policy" is none. You simply never disclose security info. > I don't think that is right. Ben, where does this policy say we "never disclose security info"? If you report a bug then you decide when to disclose the information. If Netscape/IBM/Sun/Red Hat/etc. report a bug then they get to decide when to disclose it. If mozilla.org and/or the security module owner feels that a particular bug is being kept confidential for too long then they reserve the right to force disclosure on a case-by-case basis. That's the policy "in a nutshell". > The current policy changes nothing to the current procedure, apart from > giving a few more people access to the bugs. In fact, in some cases, it > is worse: Today, Netscape makes all fixed bugs public some time after it > made a release. With the new policy, a bug which is forgotten by a > reporter might never be disclosed, unless someone pokes him. What, if > the reporter is not reachable anymore? Then the security module owner and/or mozilla.org step in and force disclosure. >> However we will ask all individuals and organizations reporting >> security bugs through Bugzilla to follow the voluntary guidelines below: >> >> * Please try not to keep bugs in the security-sensitive category >> for an unreasonably long amount of time. >> > You have to define that. But we can't define "unreasonably long" in a way that would correctly apply to each and every case. >> If disputes arise about whether or when to disclose information about >> a security bug, we ask that the parties involved discuss the issues >> via private email and try to reach consensus. >> > I think that should happen visibly to all members of the seucrity group, > not just the 2 parites in conflict. Encouraging this discussion to occur within the security bug group is fine by me. However see also below. > Otherwise, Netscape or somebody else > might talk a reporter into keeping the bug closed longer than reasonable. I see nothing wrong with a vendor privately communicating with a bug reporter to make the case for keeping a bug confidential for a little while longer. After all, the vendor might need to convey vendor-confidential information, like the fact that they have a release planned for a particular date. And other members of the security bug group have the same opportunity to make their own views privately known to the bug reporter. > BTW: Why do we have to wait for distributors to release a new version of > their product? I think that it is technically and organizational > possible to push important fixes to users. > > At Beonex, I added a default bookmark, which exploits the change > notification feature in Mozilla to display new security alerts to users. > The page is checked each time Communicator starts, at most once a day. > If the alert webpage changed, a window pops up displaying it. On the > page, the problem is described (vagely) and a suggestion for a fix or > workaround is suggested, e.g. to install an XPI which contains the fixed > dll. > Note that this works even through firewalls, assuming the web can be > accessed at all. > > This approach is not perfect but could be made to work well with not too > much effort. This would allow Netscape and others to quickly distribute > security fixes to all users. I think that what you've done is a clever idea and should be considered by other vendors. However mozilla.org doen't have the power to force all vendors to implement a similar scheme. >> A final point about duplicate bug reports: Note that security bugs >> marked as duplicates are still considered separate as far as >> disclosure is concerned. Thus, for example, if a particular security >> vulnerability is reported initially and then is independently reported >> again by someone else, each bug reporter retains control over whether >> to publicly disclose their own bug, but their decision will not affect >> disclosure for the bug reported by the other person. >> > Rationale? I would think that if any of the reporters decided to > piblicize the bug, all dups can be made public, because they are > practically anyway. I think you meant to say "... because they are practically the same anyway." See my comments above about bug duplicates. One reason I think duplicates should be treated separately is because it prevents the original reporter from controlling disclosure of bugs independently reported by others. Also, I can imagine cases where the original bug report contains ancillary information that is still considered somewhat sensitive (e.g., vendor-sensitive information like plans for products releases), and might justify delaying disclosure a little while longer even after duplicate bug reports have been opened up. >> This policy is not set in stone. It is our hope that any disputes that >> arise over membership, disclosure, or any other issue addressed by >> this policy can be resolved by consensus among the Mozilla security >> module owner, the module owner's peers, and other security bug group >> members through discussions on the private security bug group mailing >> list. >> > I think that the Mozilla community at large must have a word in this, > not just the security bug group. The Mozilla community at large definitely should have a word in deciding what the overall policy is. That's exactly why I'm posting this proposal to a public forum for review and comment. If and when a policy gets adopted, then we can certainly have further public discussions about suggested changes to policy. But what I was referring to in the paragraph above were disputes that might arise about a particular bug, or about letting a particular person join the security bug group. By definition those disputes are regarding things that are not public information (at least at the time they're being discussed). >> As with other Mozilla project issues, mozilla.org staff will have the >> final authority to make changes to this policy, and will do so only >> after consulting with the various parties involved, in order to ensure >> that all views are taken into account. >> > It isn't meant as offening as it might sound, but while you *considered* > all views, the view of Netscape is about the only one followed in this > policy. This policy reflects my views as well, and my views are not identical to Netscape's. In fact, I'm not even sure I know exactly what "Netscape's" views are in this context. This draft policy wasn't dictated by Netscape management, if that's what you mean, and it's quite possible that they might find things to object in it, just as you have. > You have neither full disclose nor disclosure after a certain > amount of time. Everything is controlled by a small, hand-picked group > of people. More correctly, "everything is controlled" by the security bug group (not necessarily a small group, depending on what you mean by "small"), by the bug reporter (who could be anyone), and ultimately by mozilla.org as overseer of the process. Regarding time limits for disclosure, as I wrote earlier I don't think it's possible or desirable to specify a single fixed time limit for disclosure; I would prefer to leave the time limit open, to be decided on a case by case basis, with enough checks and balances in the process to prevent people from abusing the system and sitting on bugs forever. Frank -- Frank Hecker [EMAIL PROTECTED]
