From: Simone Fischer-Hübner <Simone.Fischer-Huebner@kau.se>
Subject: Re: Rule Set Based Access Control (RSBAC)
Date: Mon, 09 Apr 2001 13:33:17 +0200
Next Article (by Date): Bencsath Boldizsar
Previous Article (by Date): Re: kernel compile times Amon Ott
Top of Thread: Re: Rule Set Based Access Control (RSBAC) Amon Ott
Articles sorted by: [Date]
[Author]
[Subject]
Hi, here is a quick reply before I leave for the weekend: At 11:03 2001-04-06 -0400, you wrote: >On Fri, 6 Apr 2001, Simone [iso-8859-1] Fischer-H=FCbner wrote: > > > I have followed some of the discussions over the lists. As one of the= main > > authors of the Privacy Model (PM), which is implemented in RSBAC, it was > > interesting to read that you think that PM can be easily expressed with= =20 > TE. > > However, I doubt that you can really express all necessary details and > > security properties. >In my recent response to Amon, I discussed n-person control and time >limits, and I raised the question of the right place for enforcing some >of the privacy model restrictions (application vs. OS). Naturally, >I'll be interested in your views on that as well. It may be appropriate to enforce the privacy policy at database level as=20 well. However, for a secure system implementation, the PM security policy=20 should also be enforced/supported at a lower system level and the=20 application should rely on the operating system to enforce the PM policy.=20 We decided that it is helpful to have a complete model implementation in=20 the operating system. >I'll try to >answer your additional questions below... > > > In particular, you have not discussed how the information flow property= =20 > can > > be expressed to prevent illegal information flow(see also example in our > > NISS=B498 paper: in a hospital, medical data accessible for medical=20 > treatment > > purposes could be illegally copied to admission data accessible for > > administration purposes, or another example: personal data could be= copied > > to data classified as non-personal) : > > In order to prevent illegal information flow , subject (processes) have= =20 > two > > further security attributes: Input-purposes and output-purposes. ><some text deleted> > > I do not see how this information flow control can be easily expressed= =20 > with > > RBAC/TE ? > >You've chosen a particular approach for preventing illegal information >flow in your model. But that isn't the only way to achieve the same >high-level security requirement. Rather than dynamically adjusting >the purpose attributes of the process as it performs reads and writes, >you can simply set the purpose attributes when the process is created >based on your intended task, and conservatively prohibit reads or writes >that would violate your information flow restrictions. The same >is true for Multi-Level Security restrictions. Well, this approach will be more restrictive. According to our approach,=20 the allowed read and write accesses for a process performing a certain task= =20 can vary depending on what data the process has read and what data it has=20 currently write-access to. A simple example: the process is allowed to=20 write to non-personal data (for which most of the security properties do=20 not apply) unless it had already read access to personal data (because then= =20 it could illegally write personal data to unprotected non-personal data). Thus, if you decide on read and write accesses before process execution,=20 you will be more restrictive than necessary. > > Well, this seems to be possible, but then you wont have any easy and > > transparent administration of access rights any longer (which should be= =20 > one > > of the advantage of Role Based Access Control -RBAC). > > Just imagine that you model in your system 10 different purposes. This > > means that you have to model with TE 1024 different types (for all=20 > possible > > subsets of purposes). > >It seems unlikely that all combinations of purposes are needed or >that a large number of purposes must be associated with any object >at any given point in time. Well, if you want to include relabeling in case that data subjects have=20 given their consents for a usage of their data for potentially any possible= =20 purpose sets, you have to define types for all possible subsets of=20 purposes, because all of them could be potentially needed (Example: Assume= =20 there is a personal data object with only one purpose. The data subject of= =20 this object could potentially give his/her consent that this object could=20 be used for any possible subset of the set of the remaining purposes). > > Besides, by relabeling the personal data to include another purpose to > > which the data subjects have agreed, you change the real semantic of the > > O-purposes attribute of data, which should only stand for the purposes= for > > which data for initially collected. Relabeling data in case of a consent > > would in this case also require that you have to change the type= (encoding > > purposes) in the list of necessary accesses as well. > >I suppose you could encode two purpose sets in each type to >represent both the original purposes and the current purposes. >But I'm not sure how critical these characteristics are to meeting >the high-level security requirements, as opposed to just being >aspects of your approach. Still, a change of the type in the list of necessary accesses would be=20 necessary. Best regards, Simone Fischer-Huebner. ----------------------------------------------------------------------- Prof. Dr. Simone Fischer-Huebner Karlstad University Department of Computer Science Universitetsgatan 1 S 651 88 Karlstad / Sweden Tel: +46 54 700 1723 Fax: +46 54 700 1828 http://www.cs.kau.se/~simone/ simone.fischer-huebner@kau.se - To unsubscribe from the rsbac list, send a mail to majordomo@rsbac.org with unsubscribe rsbac as single line in the body.
Next Article (by Date): Bencsath Boldizsar
Previous Article (by Date): Re: kernel compile times Amon Ott
Top of Thread: Re: Rule Set Based Access Control (RSBAC) Amon Ott
Articles sorted by: [Date]
[Author]
[Subject]