From f23bf0306affae5e5945bd8d9b6b93f8d754e3ec Mon Sep 17 00:00:00 2001 From: =?utf8?q?Daniel=20Kou=C5=99il?= Date: Tue, 29 Jul 2008 14:12:03 +0000 Subject: [PATCH] The security section reduced and moved to the Implementation section --- org.glite.lb.doc/src/LBUG-Introduction.tex | 130 ++++++++++------------------- 1 file changed, 42 insertions(+), 88 deletions(-) diff --git a/org.glite.lb.doc/src/LBUG-Introduction.tex b/org.glite.lb.doc/src/LBUG-Introduction.tex index f65ae02..0d5f2a6 100644 --- a/org.glite.lb.doc/src/LBUG-Introduction.tex +++ b/org.glite.lb.doc/src/LBUG-Introduction.tex @@ -557,6 +557,48 @@ it is safe to qualify events with lower WM counter (than the already received one) to belong to inactive branches, hence ignore them even for update of job state attributes. +\subsubsection{\LB data protection} +Events passed between the \LB components as well as the results of their +processing provide detailed information about the corresponding job and its +life and users obviously expect the job data provided by the \LB server to +be credible, reflecting the real jobs' operation on the Grid. Therefore, the +data must be based solely on authentic information generated by legitimate +grid components. The job data also provides information about user's +activities, which many users want to keep private. In order to provide a +sufficient level of security, the \LB infrastructure implements a security +mechanism that provides data protection and access control to the data. + +All the \LB components communicate solely over secure channels whenever they +send data over a network. The TLS protocol~\cite{tls} is used for both mutual +authentication of the client and server and also encryption of the +communication. All the \LB components as well as the clients must possess a +digital certificate that they use to prove their identity. The \LB +infrastructure supports both standard X.509 certificates or proxy +certificates~\cite{proxycert} that are standard authentication mechanism in +the gLite environment. Depending on the server configuration and action +requested, the users may be required to present VOMS attributes in their +proxy certificates. + +By default, access to information about a job is only allowed to the user +who submitted the job (\ie the job owner). The job owner can also assign an +access control list to his or job in the \LB specifying other users who are +allowed to read the data from \LB. The ACLs are internally represented in +the GridSite GACL format~\cite{gacl2} and are stored in the \LB +database along with the job information. The stored ACL are checked on each +query requesting the data. The ACLs are under control of the job owner, who +can add and remove entries in the ACL arbitrarily using the \LB API or +command-line tools. Each entry of an ACL can specify either a user subject +name or a name of a VOMS group. + +Besides of using the ACLs, the \LB administrator can also specify a~set of +privileged users with access to all job records on a particular \LB server +(\emph{super-users}). These privileged users can \eg collect information on +usage and produce monitoring data based on the \LB information. + +%Data trustworthiness - the events aren't signed, no real non-reputability or +%traceability of the event sources. + + \subsection{User interaction} \begin{figure} \centering @@ -691,94 +733,6 @@ include the job in a list of retrieved jobs) even if the same previous \end{itemize} -\subsection{Security issues} -The events passed between the \LB components as well as the results of -their processing provide detailed information about the corresponding job and -its life. Being used by the users to check status of their jobs and also by -other Grid components to control the job, the information on jobs has to be -reliable and reflect the real jobs' utilization of the Grid. Also, some user -communities (\eg biomedicine researchers) often process sensitive data and -require the information about their processing is kept private so that only the -job owner can access not only the result of the computation but also all -information about the job run. Last but not least, according to legislation of -some countries the information on users' jobs can be treated as the user -private data, which requires an increased level of protection. \LB therefore -must pay special attention to security aspects and access control to the data. - -All \LB components communicate solely over authenticated channels. The TLS -protocol~\cite{tls} is used as the authentication mechanism and each of the -\LB uses an X.509 public key certificate to establish a mutually -authenticated connection. The users usually use their proxy -certificates~\cite{proxycert} when accessing the \LB server and retrieving -information about jobs. -\ludek{Proxy certificates were introduced by the Grid Security -Infrastructure\~cite{gsi} from the Globus project and extend the concepts of -standard public key certificates and identity providers and allows a user to -issue a certificate for herself. Such a proxy certificate is used as a means -for Single Sign-On and rights delegation~\cite{delegation}.} -The proxy -certificate can also contain other information necessary to create a secure -connection, \eg information used for authorization. The \LB security layer is -implemented using the the Generic Security Service API~\cite{gssapi}, which -makes it easier to port the application to an environment using mechanism other -than PKI (\eg Kerberos). - -Apart from providing an authentication mechanism, the TLS protocol also allows -the communicating parties to exchange an encryption key that is used to encrypt -all subsequent communication. The \LB components encrypt all network -communication to keep the messages private. Therefore, together with the access control -rules implemented by the \LB server, the infrastructure provides very high -level of privacy protection. - -By default, access to a job information is only allowed to the user who -submitted the job (the job owner). The job owner can also assign an access -control list to her job in the \LB specifying other users who are allowed -to read the -data from \LB. The ACLs are represented in the GridSite GACL -format~\cite{gacl1,gacl2}, which is a simplified version of common Extensible -Access Control Markup Language (XACML)~\cite{xacml}. The ACLs are stored in -the \LB database along with the job information and are checked at each access to -the data. The GridSite XML policy engine is used for policy evaluation. The -ACLs are under control of the job owner, who can add and remove entries in the -ACL arbitrarily using the \LB API or command-line tools. Each entry of an ACL -can specify either a user subject name or a name of a VOMS group. The -VOMS~\cite{voms2} is a VO attribute provider service, which is maintained -by the EGEE project. It allows to assign a user with groups and roles -membership and issues to the users attribute certificates containing -information about their current attributes. These attribute certificate are -embedded in the user proxy certificate and checked by the \LB server at each -user request handling. - -%Only the Read semantics is implemented so far, for the -%future we consider more complex access control, \eg implementing the access -%control for Write operations (per event) so that particular events could be -%only logged by allowed components. That would allow to generate more -%trusted results since currently each components can log arbitrary events. -%Malicious component can make the \LB server produce inappropriate results. - -Besides of using the ACLs, the \LB administrator can also specify a~set of -privileged users with access to all job records on a particular \LB -server. These privileged users can \eg -collect information on usage and produce a monitoring data based on the \LB -information. - -%Data trustworthiness - the events aren't signed, no real non-reputability or -%traceability of the event sources. - -Since the hostname of the \LB server is part of the job identification, it is -easy for the user to check that the correct \LB server was contacted and no -server spoofing took place and thus the data received from the server can be -trusted. The \LB server on the other hand has no means of checking that the -logged events originated from an authorized component. Everyone on the Grid -possessing a valid certificate from a~trusted CA can send an event to the \LB and -let it store and process the event and possibly change the status of the -corresponding job. This way a malicious user or service can confuse the \LB -server by a forged events. This behavior is not a critical issue in the current -model and the way in which \LB is used, however, we are designing a solution -addressing this weakness. We plan to use the VOMS attributes issued to a -selected components. These VOMS attributes must be presented when critical -events are logged to the \LB server. - \ludek{\subsection{Performance and scalability} The \LB service was designed with performance and scalability issues in mind. We have developed a series of tests of the -- 1.8.2.3