The proposal is that a tool will be written to parse the Hg pushlog/SVN
log/Bonsai and create a list of accounts which have checked in at some
point in the last N months. This would then be compared against a full
list of accounts to determine which accounts are dormant. (Bugzilla is a
bit trickier, and may require code changes. But I think it's OK to
create policy in advance of our technical ability to implement it.)
Question 1 is whether we should have such a policy or not, and whether
the above is a good formulation. Question 2, a separate question, is the
value of N.
My suggestion is that we run the tool using an initial period of six (6)
months. If it turns out that the list of names produced contains some
people who we still consider active contributors, we can adjust N
accordingly.
Gerv
> In order to reduce the attack surface for our machines and systems, we
> would like to implement a policy for disabling dormant accounts for our
> SCM systems and for Bugzilla accounts with security bug access.
While I fully agree with disabling unused SCM accounts, I think
completely disabling Bugzilla accounts for inactive users with security
bug access is going too far. In my opinion, the better option is to just
remove security bug access from the inactive users rather than actually
disabling their accounts.
~reed
--
Reed Loden - <re...@reedloden.com>
> On Thu, 03 Sep 2009 16:01:48 +0100
> Gervase Markham <ge...@mozilla.org> wrote:
>
>> In order to reduce the attack surface for our machines and systems,
>> we
>> would like to implement a policy for disabling dormant accounts for
>> our
>> SCM systems and for Bugzilla accounts with security bug access.
>
> While I fully agree with disabling unused SCM accounts, I think
> completely disabling Bugzilla accounts for inactive users with
> security
> bug access is going too far. In my opinion, the better option is to
> just
> remove security bug access from the inactive users rather than
> actually
> disabling their accounts.
+1; I'd also probably un-cc them from the security-sentitive bugs that
they might be cc'd on.
cheers,
mike
I recall that we had this discussion before, and there were complaints
about "just half a year".
I wonder if we should gather the data first, and then see if there's a
clear cut on what's rarely used and what's not used.
Technical detail question, can this be directly hooked up on ldap?
Axel
Yes, OK, that makes sense.
Gerv
That's exactly what I'm suggesting :-) I'll run the tool looking back 6
months and if it turns out the list has the wrong people on it, we'll
try a year. In fact, we could try both and see if it makes a difference.
> Technical detail question, can this be directly hooked up on ldap?
See https://bugzilla.mozilla.org/show_bug.cgi?id=505331 . It turned out
to be difficult to get this info out of LDAP, so I decided to write a
public CVS/SVN/Hg log parser instead. I'm about half way there, although
there's a problem with the web SVN logs:
https://bugzilla.mozilla.org/show_bug.cgi?id=514406
Gerv
What about bugs they filed, or security bugs in components they watch, etc?
Rob
Er, forget about the second one, but the first may be an issue.
Rob
technically we could remove rights for them to see those bugs (bug at
a time, by clearing a checkbox).
I'd bet the ui for being locked out of bugs you've reported sucks.
> Robert O'Callahan wrote:
> > Er, forget about the second one, but the first may be an issue.
>
> technically we could remove rights for them to see those bugs (bug at
> a time, by clearing a checkbox).
reporter_accessible, yeah.
> I'd bet the ui for being locked out of bugs you've reported sucks.
It's the usual "Access denied to bug xxxx" error message, as seen it
within the last few weeks.
OK, seems like this is OK (with the edits proposed - dormant Bugzilla
accounts will be removed from all secure bug access rather than disabled).
I've written the tool to support this policy, and am just waiting on a
complete list of accounts from IT in order to run it and see who gets
caught in the net, as it were.
Gerv
Seems like another thing worth raising at a meeting, to catch people
who might not have been reading governance in the last 9 days. If
this is suddenly urgent, I apologize, but I haven't seen a reason for
it.
Mike
I appear to have created some confusion here, for which I apologise.
The Dormant Accounts policy has two parts.
1) SCM account disablement
2) Bugzilla account privilege-busting
I have a tool to find a list of active accounts which, when compared
with an IT-supplied list of all accounts, gives us targets for 1).
However, there will be further discussion of an appropriate value for N
before this is implemented, and there will be announcements and a blog
post (although if the people actually have gone, they are unlikely to
see them!).
We do not yet have a script which will query a Bugzilla and
automatically do 2) for a given list of names. So even when we know N
and we do 1), we may not do 2) immediately.
So neither part of the policy is to be implemented imminently. However,
it's worth raising it at the meeting just so people know it exists.
Gerv