From: cross-project-issues-dev-bounces@xxxxxxxxxxx [mailto:cross-project-issues-dev-bounces@xxxxxxxxxxx]
On Behalf Of David M Williams
Sent: Wednesday, September 14, 2011 11:58 AM
Subject: [cross-project-issues-dev] An educational item on Hudson project-level group security
I do not mean this as part of the ongoing "security debate" ... this is a separate issue (at least, sending this note now is motivated for completely
different reasons ... pure coincidence ... though does fit in to the "do what you can to be secure even if not perfect" theme).
I happened to notice that many Hudson jobs have ROLE_CALLISTO-DEV defined as a group that has permission to do things to their build jobs (such as, build, configure, delete). I didn't look at too
many details, but the sheer volume of such permissions implies this has been something that's been copied from job-to-job without people thinking much about it and perhaps not even knowing what it is ... so, thought I'd explain ... at least the little I know.
I did a "grep" of config.xml's in /shared/jobs, and about 50% of the groups used are ROLE_CALLISTO-DEV (out of about a 1000 hits for "ROLE_", about 500 of them were for "ROLE_CALLISTO-DEV". That
seems way out of balance, so, thought I'd explain what "ROLE_<group>" means, and suggest some alternatives for many projects.
Using "ROLE_<group>" equates to a Linux group, usually the committers for a project. ROLE_CALLISTO-DEV is the group of committers that can write the input files needed for the yearly simultaneous
release (namely the callisto-dev Linux group). It currently has about 100 members! So ... if your own project permits that group to your Hudson job, you are essentially allowing 100 "extra" people access to your Hudson job. This is no huge security hole ...
after all, the callisto-dev folks are all trust worthy, etc., ... but, ... as a matter of principle, security is a matter of degree, the more people that have access to something, the more chances there are for someone (else) to break-in, or, I suppose, more
chances for accidents to happen (e.g. someone changing your job, when they meant to change another job).
I opened bug 357316 about this, and the Hudson admins closed as "works for me" saying (rightly) that it is up to each project, once its set up, to define its own project level security, that they
do not know what is intended or desired.
So, what to do? During the weeks ahead (not necessarily now, during shutdown) I'd suggest those responsible for their projects' Hudson jobs to take a look at their project level security and make
sure the right people and groups have access. If there's no reason for a group (e.g. ROLE_CALLISTO-DEV) to have access, then to remove that group. In most cases, you want only the committers for your project to have "working" access to your project. So if,
for example, if you had a job for a Web Tools Source Editing project, you probably want "ROLE_WEBTOOLS.SOURCEEDITING" to have access to build or change jobs. If you simply want everyone to be able to "read" your build results, you can add "anonymous" with
the "read workspace" check box marked. If you need help for your individual project, I suggest opening a bug under the "Hudson" component, and I'm sure the admins would be glad to help if/when they know the specifics about your project.
As far as I know, there is no reason for ROLE_CALLISTO-DEV committers (as a group) to have access to so many Hudson jobs. So, I just mean this as a wordy "education item", and encourage people
to be aware of the access they give to others. I could not find this described on any of our Eclipse Hudson wiki pages so added a section  to our main Hudson wiki page . Do let me (us) know if "recommended security settings for Eclipse Hudson jobs"
are described elsewhere.