Closed Bug 821341 Opened 12 years ago Closed 11 years ago

Create security group usage tracking mechanism

Categories

(bugzilla.mozilla.org :: General, defect)

Production
defect
Not set
normal

Tracking

()

RESOLVED WONTFIX

People

(Reporter: gerv, Unassigned)

Details

It would be good to reduce bmo's attack surface with respect to security bugs by disabling the security group bits on users who don't need them. 

In order to know which accounts no longer use their privileges to access security bugs, we need to know, for each group membership each user has, when was the last time they actually used that membership to view a bug.

I suggest that the best way to do this is to add a "last_access_ts" column to the user_group_map table, and then hook into individual bug accesses and populate/update that field accordingly. There doesn't seem to be an obvious hook for this; perhaps we would need to use "template_before_process" and match on "bug/show\..*".

When we have this data, we can answer questions like: "Which users are members of the security group (or website-security, or whatever) but have not accessed a bug in that group in the last N months"? And disable the security access of people who are not using it, thereby reducing the attack surface.

Gerv
This data will take time to collect. In the meantime, it would also be interesting to know which members of privileged groups such as the security group have not logged into bugzilla for some time. I'm not sure of the time period but if they haven't logged into bugzilla at all in 6 months or even perhaps 3 months, I think we could use that data immediately.
i'm not a fan of adding additional writes when viewing bugs until we're settled down on the scl3 hardware (q1 2013).

a non-invasive method would be to use bmo's access logs to determine bug views, and run a nightly report to collate the data.

(In reply to Bob Clary [:bc:] from comment #1)
> This data will take time to collect. In the meantime, it would also be
> interesting to know which members of privileged groups such as the security
> group have not logged into bugzilla for some time. I'm not sure of the time
> period but if they haven't logged into bugzilla at all in 6 months or even
> perhaps 3 months, I think we could use that data immediately.

i can add that to the group security report on bug 812433.
The existing user-activity reports can be used to see who has made changes to security bugs. There might be some subset of security group members who merely view such bugs and never make any changes at all (not even CC's), but I bet that's a small group and we can determine whether they're active in other ways.
glob: can we ease your "additional write" pain by only writing the value if the current value is more than e.g. a day or a week ago? That would mean that most bug accesses for most people wouldn't require a write; even a heavy Bugzilla user would still only require a maximum of one additional write per group-membership per day/week (whatever is chosen).

It's the "relatime" solution :-)

If that's not acceptable, we could substitute "bug modification" for bug access, and update the information at the same time that we update the bug. dveditz may be right that the two are approximately equivalent in practice.

We could build something on the access logs, but that requires different people with different skills and different access. I couldn't do it, for example.

Gerv
glob/dveditz: is the "last seen" column on:
https://bugzilla.mozilla.org/page.cgi?id=group_members.html&group=security-group
sufficient to answer the use case that prompted this bug?

glob: I notice that the report linked above tops out at ">30", when it might be useful to know exact values for longer ago than that. Did we fix the bug about adding a "last_login" value to the profiles table, so we can do better than simply checking the age of their logincookie?

Gerv
Flags: needinfo?(glob)
(In reply to Gervase Markham [:gerv] from comment #5)
> glob/dveditz: is the "last seen" column on:
> https://bugzilla.mozilla.org/page.cgi?id=group_members.html&group=security-
> group sufficient to answer the use case that prompted this bug?

i think it would be.

> Did we fix the bug about adding a "last_login" value to the profiles table,
> so we can do better than simply checking the age of their logincookie?

that's bug 240437.


in comment 3 dveditz indicated that the current data set is sufficient for his needs.  i don't think there's value in doing unnecessary work here.
Flags: needinfo?(glob)
OK. If dveditz is happy, then WONTFIX.

Gerv
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.