Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

Re: [2600] action item 480 - referring to ownership of documents in rules about function data

Carmen,

I hope you don't mind if I reply to the P2600 list with this, because you bring up some good points and questions.

If you look at the definition of D.FUNC that we have been using, it has two parts:
User Function Data are the information about a user’s document or job to be processed by the TOE.
One part is information about a user's document, and the other part is information about a user's job. So I think that we need to make sure that our access control rules express the intent of protection without being too restrictive for both parts.

As I see it, "ownership" of D.FUNC would also have two parts: the document owner would own information about the document, and the job owner would own information about the job.

In the Common Access Control SFP, we say that a normal user cannot modify or delete D.FUNC "except for his/her own documents", and I think that only addresses the first part. Therefore, by restating the rule to say "except for his/her/ own user function data", the rule can cover both parts and its specific interpretation would depend on the particular implementation that is being evaluated.

There are so many ways to implement functions like incoming fax and document storage/retrieval that I am a little worried that the way we write the rules in the PP may cause problems for some implementations, or at least, some implementations will need to jump through hoops to show how they fulfill the intent of protection.

I think that both examples you gave would be handled by transfer or joint ownership: each user would have full permission to do as they wish with the document and its function data, and the function data associated with their document processing jobs.

I am more concerned about situations when someone owns a document and gives limited permissions to another user. For example:
  • I store a document and give you access to read it. I own the document and function data associated with the document. You can execute a "read" operation and you would own the function data associated with that operation. This is fairly straightforward, but I think it would help if we restated the D.FUNC rule in terms of ownership of function data instead of ownership of documents. But what if I have permission to modify the document, but not to delete it? That might imply that I am changing user function data associated with the document (file size, page count, timestamp, etc.), so in this case maybe I need to be considered to be a joint owner of the document but with limited permission.
  • An incoming fax is owned by a fax administrator. The fax admin sees that it is addressed to Brian and Carmen, and gives each of us permission to access the document. Now, what? Can one of us delete the document before the other has had a chance to read it? Or do we each get a copy, so I can delete mine and without deleting yours? Or do we only get access to read it, and the fax admin will delete it later? Some of these cases might be handled by transfer or joint ownership, others might be handled only by permissions.
I think we'll go insane, or at least I will, trying to think through all of the possible implementations. Therefore, I think that the best strategy is to express the rules in term so the effected assets (D.DOC in terms of  "his/her own documents" and D.FUNC in terms of "his/her own user function data"). Perhaps we should make an app note about the notion that D.FUNC can have a part that is related to documents and a part that is related to jobs, and some further description in the PP Guide about all of that.

But also take a look at the D.DOC rules in the DSR package. It restricts read access for normal users except for when you own the document or "if authorized by another role or mechanism if such functions are provided by a conforming TOE". This was intended to allow someone to store a document, retain ownership, but also give read access to other normal users. The ST author could add additional rules in a similar form for modification, but not for deletion because deletion is more restrictively specified in the Common PP's SFP. I wonder two things about this:
  1. Will "if authorized by another role or mechanism if such functions are provided by a conforming TOE" be acceptable to evaluators, and could it be misused by ST authors?
  2. If it is acceptable and unlikely to be misused, should we consider adding this escape clause in the PP or other packages?
I think the answers are: (1) I hope so and I hope not, and (2) no, it is only needed in DSR and if you want to give permission in DSR for another user to delete your document then you should transfer or create joint ownership. But I don't know...
--
Regards,
Brian Smithson
Project Manager, Security Research
PMP, SSCP, CISSP, CISA, ISO 27000 PA
Advanced Imaging and Network Technologies
Ricoh Americas Corporation
(408)346-4435


Aubry, Carmen wrote: 
Brian,

I think that the situation where a user is performing operations on a document owned by another user can be covered in different ways, depending on vendors choices and implementations. 

1. One might decide that:

If a user is performing an operation on a document that is owned by another user, the owner can give to another user whatever permissions he wants: retrieve D.DOC, modify D.FUNC , delete D.DOC...
In this case, the other user will have permissions to do some actions, even though he will not be the owner. The ST author will just need to add an access control rule describing the behaviour.

2. Another possibility would be to say that the owner is a group of users  (the users in the group being able to do a cooperative work on the documents submitted by each one). 

It is not clear for me why are you making the difference between what happens for D.DOC and for D.FUNC when a user is retrieving a document from a DSR, document submitted by another user? Are you suggesting that some access control policy is implicit in this case like?
You say: "The user performing the operation owns the function data associated with the retrieval job, but does not own the document": what "own the document means"? Does it mean that an implementation where the vendor decides that the owner can give to another user the right to delete D.DOC for instance would not be compliant?

That being said, I don't have nothing against the proposal to use: "except for his/her own function data" in PP. I'm just afraid of having some implicit requirements for DSR that I have not understand yet. Do you think that the 2 use cases suggested bellow are not compliant to this PP?


Best regards,


_________________________________________________________
Carmen AUBRY, 
GSNA, CISSP
Oce Print Logic Technologies S.A. -R&D -http://www.oce.com
Phone: +33 (0)1 48 98 80 22 - Fax: +33 (0)1 48 98 54 50
1, rue Jean Lemoine  -  BP 113  -  94015 Créteil Cedex  - FRANCE
_________________________________________________________

-----Original Message-----
From: Brian Smithson [mailto:brian.smithson@xxxxxxxxxxxxx] 
Sent: Thursday, November 13, 2008 10:10 PM
To: STDS-2600@xxxxxxxxxxxxxxxxx
Subject: [2600] action item 480 - referring to ownership of documents in rules about function data

At the Lexington meeting (see comment #96 in http://grouper.ieee.org/groups/2600/comment-tracking/P2600X_2008_10_v02.pdf.),
I identified an potential issue in the access control rules for D.FUNC.

For example, in 10.4, the Common Access Control SFP rule for D.FUNC says that U.NORMAL cannot modify or delete D.FUNC "except for his/her own documents". The potential issue is that a user may be performing an operation on a document that is owned by another user, such as retrieving (with permission to do so) a document from a storage/retrieval system. The user performing the operation owns the function data associated with the retrieval job, but does not own the document or the function data associated with the document.

I had proposed that we change such rules from "except for his/her own documents" to "except for his/her own jobs". However, Helmut Kurth pointed out that we would need to define an entity "job", rules associated with its ownership, etc., so it was not such a simple change.
I agree with that.

I think that it might be acceptable and much easier if we change the rules to say "except for his/her own function data". This would be consistent with the rules for D.DOC which say "except for his/her own documents".

Before I submit this as a comment against the current draft, I would like to open it up for discussion on this email list (as promised).

What do you all think? Is there an issue with having rules for D.FUNC that are stated in terms of ownership of documents? If so, would stating it in terms of ownership of function data be a good resolution to the issue?

--
Regards,
Brian Smithson
Project Manager, Security Research
PMP, SSCP, CISSP, CISA, ISO 27000 PA
Advanced Imaging and Network Technologies Ricoh Americas Corporation
(408)346-4435