[ogsa-d-wg] Security issues for data services

[Peter Kunszt]

Bill,

we disagree on some points, let me elaborate.. 

> -----Original Message-----
> 
> I disagree that replication services need to enforce common 
> security levels for replicas.  If I have read access to a 
> file, I can copy it and set its access to whatever I want.  
> If that is important data, it is assumed that since I have 
> read access I will take care of it.  A community may wish to 
> impose consistent access rights across replicas, but that is 
> a policy issue not something inherent in replication services.
> 

Replicating access rights is in the interest of the job submission
system: if a file is replicated to site A, the job submission system
assumes that it has the same permissions as elsewhere. If the file at
site A is not readable for the job, then it fails, because of the 
file permissions were not replicated along with the content.

If you degrade security consistency to a VO policy, then why would
any VO that needs this security consistency trust the Grid
infrastructure
with their data? Knowing that the infrastructure will not enforce
consistent
security semantics across sites means to many applications relying on
secure data access (sometimes due to legal issues) that the whole
infrastructure
is unusable to them. Since sites have the last say and VO services are
not part of the site security infrastructure, it is not possible to
enforce
security semantics through VO policies alone (at least this is one of
the
conclusios we came to in EGEE). 

This is a crucial point in the data architecture: Do we 
intend to offer a consistent grid-wide security to the applications
or not? Where does VO policy start and Grid/site security stop? 
How do they interact? Our strong belief is that the infrastructure
has to be able to offer strong security. It may be that some sites
decide not to support it - but then the VOs who rely on strong security
should be able to choose not to include that site in their 
list of supported resources.



> As to the federated security model, I again dont think that 
> is necessary, if I access n different sites, I have to do n 
> authentication and authorization checks and if any one of 
> them fails the access fails. 
>   This does imply some things about uniform identity, they 
> all trust the same CAs, even that they are all using the same 
> security mechanism.  It would also be a major pain to debug 
> access problems, particularly if the system is dynamically 
> choosing the resource so you dont even know where are 
> accessing things.  I suppose it might be possible to query 
> your rights across all the resources and present a federated 
> access rights list that was the least common denominator.

i don't quite follow here.. the user always should know
where and why an access was denied, and a site should always
keep a log of access data (audit trails).

> 
> The idea of users not wanting anyone, including admins 
> knowing what they have stored is a security concern.  How do 
> we know that they are not storing stolen top secret 
> information or that they are actually running bomb design 
> software.  I dont subscribe to this, but I have heard this 
> argument from security folks before.

Biomed applications want to protect their patient's privacy,
as they are required to do BY LAW. therefore they need to 
be able to encrypt files on the storage. If one
does not agree with this policy, then it should be advertised
in the storage policy that such sensitive applications would
not use the resource.

There may be conflicting legislations, we have to be able
to deal with it. That can olny be done by properly advertising
the security semantics of the Grid Sites and VO services..

Peter & Akos

> 
> Bill
> 
> --
> William E. Allcock
> Argonne National Laboratory
> Bldg 221, Office C-115A
> 9700 South Cass Ave
> Argonne, IL 60439-4844
> Office Phone:  +1-630-252-7573
> Office Fax:      +1-630-252-1997
> Cell Phone:      +1-630-854-2842
> 
>