On Mon, Feb 14, 2005 at 08:39:20PM +0000 or thereabouts, Dr D J Colling wrote:
> Dear All,
>
> Following last week's discussion about security issues I asked Kostas to
> look for them and then to test and report any that he finds. This is the
> first one that he has done this for. This clearly is a very serious
> problem as it removes the definite mapping between a user running a job
> and the real person, so breaking the security policy at many sites. As
> Steve T. says this is a serious problem however I don't see any activity
> correcting it.
Dave,
All points are correct, this clearly needs addressing and fast. It represents
a good test, although very real, case.
Things to do
1) Someone else should confirm the exploit, I was unable to today but
I'm sure that was me doing something wrong. It should work.
2) From Ian Nelsons useful mail to Alessandro a few days we have a choice
of security contacts:
<quote>
> [log in to unmask]
For discussion of operational security coordination between EGEE ROC
contacts = embryo Operational Security Coordination Team
> [log in to unmask]
As defined in the LCG/EGEE Incident Response Guide for notification of
incidents. Contains all site incident response team contacts. Should not
be used for general discussion.
> [log in to unmask]
Generic contact address as a catch-all if people don't know what who to
ask - currently points to me.
> [log in to unmask]
As defined in the LCG/EGEE Incident Response Guide for general
discussion of incidents or other matters. Contains all designated site
security contacts. Intended for general discussion or follow-up of
incidents.
> [log in to unmask]
Defined to provide feed-back/support on policy set.
Ian
</quote>
This is also important since you could consider this a deficiency in
perhaps the most significant software contributions from GridPP to Grid.
3) Think of solutions,
i) Preserve account mappings for ever.
ii) Modification to pbs/torque though I don't know what.
iii) Some very careful clean up in pbs pro/epilogues.
iv) What do other batch systems do , LSF,..
Steve
>
> What are people supposed to do when they find such a hole and what effort
> do we have to correct such holes? I seem to remember that there was effort
> in the GridPP2 tender for Security support. What happenned to this effort
> and is this sort of thing appropriate for them to work upon (in a support
> role)?
>
> Security is not like data movement or workload management. Somebody finds
> an in-efficiency in these pieces of middleware and you have time to put
> them right (and there are people working on them). Once a security hole is
> discovered there has to be rapid action correct it before it is exploited
> and what is more I don't see any activity in their correction.
>
> Now that it has been pointed out to you that you do not know who is
> actually running a process, which, if any, sites are running this software
> legally (i.e. not breaking their college usage policies)? I suspect that
> people will keep ignoring this (which in itself is technically worthy of
> dismissal at Imperial) in order to keep their sites on the LCG. Is this
> really the way we want to proceed? What do we say to our security officers
> when somebody exploits such a weakness to launch (say) a DoS attack? "Oh,
> yes, we knew it was there some months ago but we ignored it..."?
>
> I don't know what the answer is here, but I do see that we have a real
> problem and I would like to see discussion about a way foreward. Most of
> all I don't want to see it ignored and swept under the carpet.
>
> All the best,
> david
>
>
> On Mon, 14 Feb 2005, Steve Traylen wrote:
>
> >On Mon, Feb 14, 2005 at 12:28:43PM -0000 or thereabouts, Burke, S
> >(Stephen) wrote:
> >>Testbed Support for GridPP member institutes
> >>>[mailto:[log in to unmask]] On Behalf Of Steve Traylen said:
> >>>I would submit it to the torque bugzilla, clearly a big hole it PBS.
> >>
> >>Didn't we already know that? We've had dangling processes in the past. I
> >>think PBS kills (or tries to kill) everything in the process group, but
> >>if the group changes it doesn't get caught ... it's not entirely obvious
> >>how you would do it cleanly given that one user might be running two or
> >>more jobs on the same node.
> >
> >Yes you are right, we used to see this as you know with some replica
> >managment
> >commands.
> >
> >This is probably a serious problem .
> >
> >Steve
> >>
> >>Stephen
> >
> >--
> >Steve Traylen
> >[log in to unmask]
> >http://www.gridpp.ac.uk/
> >
--
Steve Traylen
[log in to unmask]
http://www.gridpp.ac.uk/
|