Hi,
since these are middleware bugs I would add
[log in to unmask]
to the list of useful email addresses. Although this is for middleware
discussion and not a bug report mailing list.
cheers
alessandra
On Mon, 14 Feb 2005, Steve Traylen wrote:
> 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/
>
--
********************************************
* Dr Alessandra Forti *
* Technical Coordinator - NorthGrid Tier2 *
* http://www.hep.man.ac.uk/u/aforti *
********************************************
|