Group Name Guessing Disclosure Policy

[Frédéric Buclin]

Le 20. 07. 10 22:44, Max Kanat-Alexander a écrit :
> 	The conditions under which a user can see a group name are ill-defined
> and very complex. The conditions I can think of off the top of my head are:

It is not very complex...
> 
> 	A user can see a group's name if they can enter a bug in any product
> where that group is mandatory, shown, or default for them.

Mandatory groups are never displayed in bugs. About shown and default
groups, all we want is $product->groups_available, which we already do.
Here, group visibility doesn't matter and we display these group names
in all cases. So this case doesn't need to be considered.


> 	A user can see a group's name if any bug that they have access to has
> OtherControl for that group, even if they are not in the group.

We use $product->groups_available, as above. Also doesn't need to be
considered.


> 	A user can see a group's name if they have been CC'ed on or are the
> reporter of a bug that is restricted to a group that they normally
> cannot see.

We use $product->groups_available, as above. Same conclusion.


> 	A user can see a group's name if they have editcomponents for any product.

All groups marked "Use For Bugs" are indeed visible to them, thanks to
$product->group_controls. Doesn't need to be considered. If the
poweruser tries to hack the URL, then we can tell him that either the
group Foo doesn't exist, or is not a bug group. No need to check his
relationship with the group.


> 	A user can see a group's name if they are in it directly, by
> inheritance, or by regex.

We use $user->groups directly. Doesn't need to be considered.


> 	A user can see a group's name if they have global editcomponents,
> editusers, creategroups, or are in the admin group.

It depends which admin page you are talking about, but it's either one
of the method mentioned above, or simply Bugzilla::Group->get_all(),
which do not need to be considered as these methods are all unrelated to
your relationships with groups.


> 	A user can see a group's name if any user with that group's icon has
> ever commented on any bug they can see. (Or it might be only the group
> description--I'm not sure, but that's just as bad.)

That's a bug which should be filed and fixed.


> 	In the future, these conditions will expand and likely become more
> complex. For example, depending on how we do flag requestee
> autocomplete, it's possible that users will be able to see the name of
> any group that is in the grantgroup of any flag on any bug they can see.

If we use autocompletion for requestees, then we don't need to disclose
the group used as the grant group. If the user ignores autocompletion,
then it's enough to tell him that the user he chooses has not the right
privileges to grant the flag. Telling him that the user must be in the
group Foo would be of no help. I know that's what the current error
message says, but it can be reworded once autocompletion works for
requestees.


> 	In customized installations, there are likely to be additional
> conditions under which group names can be seen.

Then they would very likely use their own methods, or re-use one of the
existing ones above, in which case the error message is totally under
our control.


> 	So, instead of creating a performance-draining and extremely complex
> centralized method for determining all of the above, I figured I'd just
> modify our policy on the subject.

I still don't see the relationship with the original discussion, which
is about disclosing the existence of groups. You need all the methods
describe above, and all are pretty independent. Basically, you don't
want to use Bug::Group->check() in non-admin pages, and admin pages
already have their own methods and error messages can be worded
accurately enough to not confuse the user, without disclosing the
(in)existence of groups when that's not required.


LpSolit