 |
 |
Hello all, As Steve mentioned on the wiki page, some of the fixes may break MPI support. I would not like such fixes to be the default in yaim. Currently for MPI support ssh access between the workernodes is necessary. As far as I understood yaim was only meant to perform the setup of the LCG middleware. Sites using yaim will have to do the rest of the configuration, like the setup of ssh and tcp wrappers, themselves. I would like it to stay this way, because otherwise it is very hard to be able to make use of yaim functionality when using cluster management software. Hints about the setup on a wiki are of course very welcome. Kind regards, Fokke -----Original Message----- From: LHC Computer Grid - Rollout on behalf of Steve Traylen Sent: Fri 6/17/2005 09:53 To: [log in to unmask] Subject: Re: [LCG-ROLLOUT] The 'How to blacklist a user" discussion and others. On Fri, Jun 17, 2005 at 08:37:54AM +0200 or thereabouts, Serge Vrijaldenhoven wrote: > Hi all, > > I would like to add that there is a DenyGroups directive that can be added > to the /etc/ssh/sshd_config file. > It's probably not too difficult to add the groups related to grid > automatically by the yaim scripts. This might be easier in some system > setups. I have ideas for this coming in from multiple direction all of which are good. Please add them to the wiki. > DenyGroups > This keyword can be followed by a list of group name patterns, separated > by spaces. Login is disallowed for users whose primary group or > supplementary group list matches one of the patterns. '*' and '?' can be > used as wildcards in the patterns. Only group names are valid; a numerical > group ID is not recognized. By default, login is allowed for all groups. > If a user's group matches a pattern in both DenyGroups and AllowGroups, > login will be denied. > Note that all other authentication steps must still be successfully > completed. AllowGroups and DenyGroups are additional restrictions and > never increase the tolerance. > > Regards, > Serge > > > > > > > > > > > Ian Neilson > Sent by: > LHC Computer Grid - Rollout <[log in to unmask]> > 16-06-2005 17:29 > Please respond to > LHC Computer Grid - Rollout <[log in to unmask]> > > > To > [log in to unmask] > cc > > Subject > [LCG-ROLLOUT] The 'How to blacklist a user" discussion and others. > Classification > > > > > > > > > On Monday 13/06/05 there was activity in several places under the headings > of > 'jobs attempting to alter ssh setup', 'please remove user from VO' and > 'how to > blacklist a user'. > > NOTE: It is confirmed by the ROC security contact in question that this > activity, whilst potentially dangerous and unauthorized, was NOT > malicious. > > A number of issues are raised by these discussions which can be analysed > with > the benefit of hindsight of which I give my brief summary of conclusions > for > some of them here. > > A) Information was flowing in several places (inter-ROC, ROLLOUT and OSCT) > > but, given the spread and timing of the discussions, confirmation of the > true > nature of the activity did not reach the necessary wider audience (site > admins) until too late. It was also not clear who should act. > > * confirmed incidents MUST be reported, preferably via the registered site > > security contact, to - > > project-lcg-security-csirts -at- cern -dot- ch (an equivalent -egee- alias > exists). > > * security reports which are not confirmed attacks (e.g. information > updates > and discussion) is via the site security contact to the list - > > project-lcg-security-contacts -at- cern -dot- ch (an equivalent -egee- > alias > exists). > > Both of the above should reach registered contact addresses at all sites. > Mail > subjects should clearly identify the content as HIGH, MEDIUM or LOW impact > or > INFORMATIONAL. Escalation in both cases due to unavailability and for > coordination should be through the affected ROC(s). The ROLLOUT list is > NOT > seen as appropriate for disclosure of security related information. > > I would say the security-contacts list would have been appropriate in this > case. > > B) Whilst not grid-specific in its nature, technical information on how to > contain the behaviour was not available and/or not sufficiently > publicised. > The OSCT will review and update where necessary. For the incident in > question > a reference has been created here: > http://goc.grid.sinica.edu.tw/gocwiki/Blocking_batch_jobs_from_creating_ssh_back_doors > > (Thanks Steve Traylen). > An additional source of general security information is published here: > http://goc.grid-support.ac.uk/gridsite/operations/security_info.php > and here: > https://cic.in2p3.fr/index.php?id=roc&subid=roc_security&js_status=2 > > C) Availability of contact data for VO management and access to user > contact > data for site administrators (currently only readily available through > mail > contact with the VO) is unclear. This needs to be addressed, no immediate > solution is available but I will add a web page with contact points for > this > and A) above together with their purpose. > > I would welcome feedback on any aspect to help in improving procedures for > the > future. > > Ian > > | Ian Neilson, LCG/EGEE Security Officer > | Grid Deployment Group, CERN > | Tel: +41 (0)22 76 74929 > > > > -- Steve Traylen [log in to unmask] http://www.gridpp.ac.uk/