gLite-VOBOX

Functional description

The VO-box is a type of node where experiments can run specific agents and services to provide a reliable mechanism to accomplish various tasks. It is provided as an interim solution in order to allow experiments to provide their own services whenever the middleware still does not provide the required functionality. The access to the VO-box (or VO node) is restricted to the Software Group Manager (SGM) of the Virtual Organisation (VO).

Note that there is not a unique description about "the" gLite VO-box as each VO provides their own requirements. At the time when the VO-box has been deployed, the VOs have completed the "LCG VOBox Operations Recommendations and Questionnaire" which describes, for instance, the requirements on the hardware (e.g., "any modern dual CPU system would be sufficient"), the preferred operating system (Scientific Linux 3 usually), or the requirements on the backup policy. The VO software running on the VO-box, and the open ports, are described in the "VO-Box Security Recommendations and Questionnaire" (VOBOX-SRQ). Templates of the questionnaires have been provides by the Joint Security Policy Group. See the VO-box WIKI for the templates and the current versions of the completed questionnaires: https://twiki.cern.ch/twiki/bin/view/LCG/VoBoxesInfo.

Released Version

http://glite.web.cern.ch/glite/packages/latestRelease.asp

Daemons running

• a GSISSH server (running by default on port 1975) which allows ssh connection authorized through X509 proxies and proxy delegation (/opt/globus/sbin/sshd -p 1975)
• a GRIS (registering to the site GIIS) which publishes the GSISSH service and port; (usually : /usr/sbin/slapd -f /opt/bdii/var/2171/bdii-slapd.conf -h ldap://localhost:2171 -u edguser)
• a Proxy Renewal Service (together with a user level tool) to ensure automatic refresh of user credentials; (/opt/lcg/sbin/vobox-renewd)

Init scripts and options (start|stop|restart|...)

• /etc/init.d/bdii
• /etc/init.d/<VO>-box-proxyrenewal
• /etc/init.d/dteam-box-proxyrenewal
• /etc/init.d/ops-box-proxyrenewal 1)
• /etc/init.d/gsisshd
• ... and possibly any more VO-box specific daemons provided by the VOs

Remarks:
1) If the VO-box is monitored by central SAM services.

Configuration files location with example or template

YAIM site-info.def example file:

• /opt/glite/yaim/examples/siteinfo/site-info.def

Please check https://twiki.cern.ch/twiki/bin/view/LCG/Site-info_configuration_variables#VOBOX for modifications.

Logfile locations (and management) and other useful

• /var/log/secure
• /var/log/vbox/
• /var/log/lcg-expiregridmapdir.log
• /var/log/fetch-crl-cron.log
• /var/log/edg-mkgridmap.log
• /opt/bdii/var/bdii.log
• /opt/bdii/var/bdii-fwd.log

There are maybe rather more logfiles depending on the VO daemons running on the VObox. See the VOBOX-SRQ for details.

Open ports

• 2171 for GRIS (has to be open only for inbound connections from site BDII)
• 1975 for GSISSH

Possible unit test of the service

https://twiki.cern.ch/twiki/bin/view/LCG/SAMTests#VOBOX

The VO must document specific connectivity requirements, preferably via the VOBOXSRQ. They should provide a full description of all required ports (inbound and outbound), and the corresponding remote destinations. VOs may request a specific port to be used by the VO daemons running on the VO-box, but this will not guarantee actual assignment of the specific port requested. For operational reasons, or in case the port has already been assigned to a different service, an alternate port may be assigned. VO software must be able to handle such alternate assignments.

Where is service state held (and can it be rebuilt)

!!! INCOMPLETE !!! The Question was not entirely understood, it should be rephrased.

Cron jobs

• bdii-proxy
• <VO>-box-proxyrenewal
• dteam-box-proxyrenewal
• ops-box-proxyrenewal 1)
• edg-mkgridmap 2)
• lcg-expiregridmapdir
• fetch-crl 2)

Remarks:
1) If the VO-box is monitored by central SAM services.
2) These cron jobs are not used if the site provides the appropriate files using a centralized file distribution service like CFengine.

Security information

Access control Mechanism description (authentication & authorization)

Interactive logins are only permitted using GSISSH. Authentication is based on grid certificates. Authorization is controlled by the gridmapfile.

VOs must provide a description of the access control mechanisms used by the VO specific daemons running on the VO-box.

How to block/ban a user

An individual user can be blocked from interactive logins to the VO-box by removing the DN from the grid-mapfile.

The other daemons running on the VO-box are under control of the respective VO. Quoting from the VOBOX-SRQ:

"Preferably, the service SHOULD implement a blacklisting capability for individual client subject names, to be configured by the site. If such a mechanism is absent, the site will be required to disable the entire VO box in case of incidents."

Network Usage

The VO-boxes are connected to the site fabric as well as to the world. Connectivity on the VO box will generally be managed and contained according to site policies. Inbound connectivity to privileged ports is prohibited. The VOs propose their requirements via the VOBOX-SRQ.

Firewall configuration

The Software Grid Manager (SGM) of the VO can login to the VO-box using GSISSH which is by default running on port 1975.

Other deamons running on the VO-box are described in the VOBOX-SRQ. It must also provide the ports used for inbound and outbound connections, as well as the remote destinations.

Security recommendations

The VOBOX-SRQ already provide security recommendations. The questionnaire (appendix A) should be extended by a description on how to configure logrotation and log forwarding to syslog(8).

Security incompatibilities

There are several daemons running on the VO-boxes which are provided and maintained by the VOs. Some of these daemons are listening on network ports which are opened for inbound connections from world.

Up to now (spring 2009) there is either no logging of VO daemons enabled at all, or the collection of logfiles is not properly handled according to the Audit Requirements. For instance, logfiles are deleted after a few days already. Redirection to the local syslog(8) facility isn't implemented and configured yet.

List of externals (packages are NOT maintained by Red Hat or by gLite)

!!! INCOMPLETE !!! This part should be accomplished by the respective developers of the VOs.

Other security relevant comments

There are currently a lot of documents about VO-boxes published at different places.

Utility scripts

Nothing reported.

Location of reference documentation

• https://twiki.cern.ch/twiki/bin/view/LCG/VoBoxesInfo
• AliEn VO Admin Howto
• http://glite.web.cern.ch/glite/documentation/R3.1/default.asp

Developer Documentation