128590 - Allow reporters to uncheck security flags

Status: RESOLVED WONTFIX

(bugzilla.mozilla.org :: General, enhancement, P5)

Description

[Ben Bucksch (:BenB)]

According to the mozilla.org security policy, the reporter may disclose a bug at
any time.

At least bugzilla.mozilla.org doesn't allow him to, because only those in the
group who can view all bugs with that flag have the checkbox enabled. The
reporter (if not in the security group) can't.

Reproduction:
1. Create a new bugzilla user.
2. File a security bug
3. Let a bugzilla user in the security group check the security flag
4. Log in as the new user again, try to uncheck the flag

Actual result:
You cannot - checkbox is disabled.

Expected result:
Reporter can uncheck security flag.

Comment 1

[James Cox]

as a note about this, since BenB wanted to silence me, and I don't like being
silenced (I wouldn't have posted this if Ben had kept quiet):

sometimes it's nice that reporters can't move things out of security... I can
just imagine the malicious hacker who reports a sec bug, but before it can be
fixed, unhides and announces it... so -1 on fixing this.. imo.

Comment 2

[Matthew Tuck [:CodeMachine]]

I don't really agree with the policy, so I doubt we should do this as a default
in Bugzilla.  Perhaps mozilla.org should apply a patch of their own here.

Customising this will likely be dealt with for the fine-grained security stuff
that's targetted at 2.20 currently.

Comment 3

[Dave Miller [:justdave]]

::sigh::

To the best of my knowledge this was on purpose, however, you're right, it's a
violation of mozilla.org's security policy.  I can think of plenty of reasons
you *wouldn't* want the reporter to be able to uncheck a particular group (the
security box is just another group, nothing special about it) such as in
commercial installations using 'usebuggroups' where a bug is secured by product
and you don't want competing customers to see each others' products, etc. 

Probably the best way to handle this is a per-group setting of whether to allow
non-group members who have been invited to participate in a bug to remove that
group flag.  This will probably be easier (as Matty noted) after bug 68022 and
bug 110947 are in, since our group handling will be much more flexible at that
time...

Comment 4

[Ben Bucksch (:BenB)]

> BenB wanted to silence me

I was joking.

> I can just imagine the malicious hacker who reports a sec bug

Why should he do that?

Reporters being able to unhide thier bugs is a central part of the mozilla.org
security policy. Disagreement with that should go to n.p.m.security :).

Comment 5

[James Cox]

well, whatever the reason, I would not like it to be default behaviour that a
reporter could change the security options.. as an aside, maybe the reporter has
too much access.. but that's another issue.

Comment 6

[Frank Hecker]

As Ben notes, the official policy on handling reports of Mozilla security
vulnerabilities states that a person reporting a Mozilla security vulnerability
should also have the ability to make public the confidential Bugzilla bug report
relating to that vulnerability. So the only question is how to accomplish this.

My personal opinion is that allowing the bug reporter to do this through the
Bugzilla interface is a good idea. In the absence of such a capability, the
reporter would have to request that someone else, e.g., the module owner or a
representative of mozilla.org, clear the "confidential" flag. But in any case
the current mozilla.org policy should be embodied in some procedure, whether
automated or manual. People who disagree with the policy should take it up with
mozilla.org staff; IMO it's off-topic for this bug.

Comment 7

[Dave Miller [:justdave]]

I believe this was partially fixed by the product groups rewrite in 2.17.3 (at
least the capability within Bugzilla anyway).  Although I don't think it's
limited to reporters, I think the new security model allows you to set groups in
a given product so that anyone who can see the bug can remove the security flag,
whether they have access to the security group or not.  Although I think this
would also allow anyone to set that flag (although once it's set, they've have
to be a member or listed on the bug to see it)

Joel?

Comment 8

[Joel Peshkin]

Well, right now a user can only place a new bug in a group of which he is not a
member (if permitted) and a non-member can never remove a group restriction from
a bug.

Naturally, anything is possible, but we really need to give some further thought
into the nomenclature if we wanr to add another pile of options.

Comment 9

[Stephen Lee]

[this showed up in a search for something else - here goes with a 2p worth!]

It stands to reason that if the reporter can *see* the confidential discussion, 
he is also capable of copy-pasting it anywhere he chooses. This is also 
commented on in the mozilla security policy.

It would seem preferable that if the reporter chooses to publicly disclose the 
vulnerability, that it is done on the official bug report so that the security 
team know about it immediately and can put suitable emergency measures into 
place (e.g. disabling the vulnerable function). A suitable warning next to the 
box should probably be given together with a link to the relevant part of the 
mozilla security policy.

Comment 10

[Max Kanat-Alexander]

This bug has not been touched by its owner in over six months, even though it is
targeted to 2.20, for which the freeze is 10 days away. Unsetting the target
milestone, on the assumption that nobody is actually working on it or has any
plans to soon.

If you are the owner, and you plan to work on the bug, please give it a real
target milestone. If you are the owner, and you do *not* plan to work on it,
please reassign it to [e-mail] or a .bugs component owner. If you are
*anybody*, and you get this comment, and *you* plan to work on the bug, please
reassign it to yourself if you have the ability.

Comment 11

[Frédéric Buclin]

This looks like specific to b.m.o. My vote to move it to mozilla.org. I see no
reason why the reporter should be allowed to go through group checks and make
the bug public. At least, I would deny review any patch going in this direction.
If the bug should not belong to some given group, let a user from this group
remove this flag.

Comment 12

[timeless]

This should be fixed in Bugzilla proper. bmo isn't that special, any open Bugzilla could reach the same decission and forking Bugzilla is not something we should be encouraging.

justdave: is there some magical incantation we need to go through to arrange for this to be fixed as part of mozilla.com?

Comment 13

[Frédéric Buclin]

(In reply to comment #9)
> It stands to reason that if the reporter can *see* the confidential discussion, 
> he is also capable of copy-pasting it anywhere he chooses. This is also 
> commented on in the mozilla security policy.

That's what mconnor said on IRC too. But in this case, anyone in the CC list could do the same (copy-pasting). Does it mean they should be allowed to remove the security flag too?? By reading all comments again, I'm happy to see that I'm not alone thinking we shouldn't do it (about the reporter).

Comment 14

[Mike Connor [:mconnor]]

I don't see a constructive reason, with the myriad of existing admin UI, why adding per-group support for reporter access to remove a bug from that group is so evil.  This would be an off by default option that would be set per-group.

Comment 15

[Dave Miller [:justdave]]

Bug 189627 has gone off in a slightly different direction and doesn't really have much to do with this bug anymore, so removing the dependency.

I agree with mconnor, an additional flag on the group control settings in editproducts seems like a good approach for this.

If you care enough about it to want it done on Mozilla paid time, you'll need to talk to schrep.  I have enough things on my plate right now to keep me busy for a few months yet before this would make it anywhere near the top of my list currently.

Comment 16

[Frédéric Buclin]

(In reply to comment #14)
> adding per-group support for reporter access to remove a bug from that group is
> so evil.  This would be an off by default option that would be set per-group.

I don't think it worths making the group control map UI more complex to do this. I see users marking bugs as FIXED when a patch is attach all the time, probably thinking that the bug is now fixed because it has a patch (despite it has not been reviewed yet, and so has not been checked in). Such users would do the same mistake with security flags (and other kind of flags) too.

My opinion is that users knowing how security works and who should be allowed to remove the sec flag already are in the required group. Other users, including the reporter, should be excluded from this group of "decision makers".

The goal is not to prevent the reporter from making the bug public if his goal is to intentionally make it public (we cannot prevent him from copying and pasting the whole discussion of the bug); the goal is to prevent accidental actions because the reporter thought it was fine to remove the sec flag.

I'm pretty sure you would cry if a reporter was making a severe security bug public before you had the time to do the whole QA cycle before releasing the next version of your product. In the same way the reporter is not allowed to edit all fields of his own bugs, he is not allowed to edit group restrictions.

I strongly and definitely suggest to mark this bug as WONTFIX, despite what your bmo policy says about this topic.

Comment 17

[Frédéric Buclin]

As explained in my previous comment, I don't want to leave reporters remove their own bugs from groups. So this is WONTFIX as an upstream feature/bug.

But as b.m.o wants it, and per my discussion with justdave on IRC today, I'm moving this bug in the mozilla.org product, so that you can implement it locally.

Comment 18

[Daniel Veditz [:dveditz]]

I was CC'd so I guess someone wants my opinion. I agree with Frédéric for groups in general, so if we do implement this in BMO please restrict it to the minimal amount necessary to comply with our security bug policy: the Reporter (not CCs) should be able to uncheck the core-security bit but not any other groups.

Members of the group should continue to be able to edit the group setting at will.

I don't feel terribly strongly about the CC's not being able to do it since they could of course repost the information elsewhere. But if they're not members of the group I'd rather have some minor barrier to mistakes or momentary poor judgment.

Comment 19

[Jesse Ruderman]

If the concern is people accidentally making bugs public, we could make a JS warning appear when you uncheck the box.  That would be good for members of the security group too, not just reporters.

Comment 20

[Jesse Ruderman]

See also bug 504461, "Allow everyone to make bugs security-sensitive retroactively".

Comment 22

[Dylan Hardison [:dylan] (he/him)]

WONTFIXing this has nothing to do with policy, merely reality. We can reopen this if we revisit it.