Hi Yves, Andreas,
> > The idea was to finally fix the security issues with the static accounts,
> > so we did not want to give an easy option to just ignore these changes.
>
> You suggest that the sgm and prd accounts are in a different primary
> group than the normal users. (although having the normal group as
> secondary group)
> This will make troubles when software or data is written groupreadable,
> and normal user want to access them.
True. Software and other shared data need to be made world-readable.
Note that until now the sgm users already had to take care making all
their files group-readable.
> In addition, there will be problems when one sgm or prd user will
> change/delete files written by another sgm or prd user.
The files and directories also need to be made group-writable.
> For sure, there are ways of dealing with these issues on the system
> side, but I doubt every sgm or prd user or sysadmin will do this.
>
> I fear that files might end up world readable and writable, which
> implies other security concerns (not to mention the administrative
> overhead: "Why can't I read the VO software at your site?"...)
Each VO usually can fix such problems by itself and avoid them.
> What are the experiences of other sites with these changes?
>
> Have there been any security incidents in the past that forced the
> implementation of the new mapping accounts?
No, but bad things should not be required to happen first, before we do
something about their cause. The issue with static accounts is that the
audit trail gets fuzzy when 2 DNs have concurrent jobs on a particular WN,
running under the same account. It is like allowing a bunch of users to
share a single account and run jobs like that on your farm: do you allow
that for local users? If not, why should grid users be an exception?
It is true there are other risks that do not get mitigated by mapping
each sgm to an sgm pool account. For example, one hacked sgm account
can still be used to put a trojan horse in the shared software area.
One could argue that the situation thus remains fundamentally broken.
Does this mean we do not have to care about the static accounts?
> Is there any possibility to use the old mapping scheme?
At the moment YAIM only allows exceptions for the VOBOX and SE_castor.
You could modify the functions that impose these requirements, but we
think it is more constructive to "bite the bullet" now and shake the bugs
out of the current implementation. Or convince the Grid Deployment Board,
or WLCG Management Board, or EGEE Technical Coordination Group that it is
wrong to try imposing these requirements on all sites. Here I note that
it would be better for the VOs if all sites had a consistent configuration,
and there are some sites for which the sgm pool accounts finally solve a
longstanding security concern...
Thanks,
Maarten
|