Re: Rule Set Based Access Control (RSBAC)

From: Simone Fischer-Hübner <>
Subject: Re: Rule Set Based Access Control (RSBAC)
Date: Mon, 09 Apr 2001 13:33:17 +0200

Next Article (by Author): Re: rsbac-v1.1.1-pre4 uploaded Stanislav Ievlev
Previous Article (by Author): Re: Rule Set Based Access Control (RSBAC) Simone Fischer-Hübner
Top of Thread: Re: Rule Set Based Access Control (RSBAC) Amon Ott
Articles sorted by: [Date] [Author] [Subject]

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=
> > 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=
> 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=
> 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=
> > to data classified as non-personal) :
> > In order to prevent illegal information flow , subject (processes) have=
> 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=
> 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=
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=
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=
> 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=
purpose sets, you have to define types for all possible subsets of=20
purposes, because all of them could be potentially needed  (Example: Assume=
there is a personal data object with only one purpose. The data subject of=
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=
> > 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=
> > 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

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

To unsubscribe from the rsbac list, send a mail to with
unsubscribe rsbac
as single line in the body.

Next Article (by Author): Re: rsbac-v1.1.1-pre4 uploaded Stanislav Ievlev
Previous Article (by Author): Re: Rule Set Based Access Control (RSBAC) Simone Fischer-Hübner
Top of Thread: Re: Rule Set Based Access Control (RSBAC) Amon Ott
Articles sorted by: [Date] [Author] [Subject]

Go to Compuniverse LWGate Home Page.