Re: Rule Set Based Access Control (RSBAC)

From: Stephen Smalley <sds@tislabs.com>
Subject: Re: Rule Set Based Access Control (RSBAC)
Date: Fri, 6 Apr 2001 11:03:51 -0400 (EDT)
Next Article (by Author): About your ad in FAPIA.COM "Steve Power - PDE"
Previous Article (by Author): Re: Rule Set Based Access Control (RSBAC) Stephen Smalley
Top of Thread: Re: Rule Set Based Access Control (RSBAC) Amon Ott
Next in Thread: Re: Rule Set Based Access Control (RSBAC) Amon Ott
Articles sorted by: [Date] [Author] [Subject]
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 mai=
n=20
> authors of the Privacy Model (PM), which is implemented in RSBAC, it was=
=20
> interesting to read that you think that PM can be easily expressed with T=
E.=20
> However, I doubt that you can really express all necessary details and=20
> 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.  I'll try to
answer your additional questions below...

> In particular, you have not discussed how the information flow property c=
an=20
> be expressed to prevent illegal information flow(see also example in our=
=20
> NISS=B498 paper: in a hospital, medical data accessible for medical treat=
ment=20
> purposes could be illegally copied to admission data accessible for=20
> administration purposes, or another example: personal data could be copie=
d=20
> to data classified as non-personal) :
> In order to prevent illegal information flow , subject (processes) have t=
wo=20
> further security attributes: Input-purposes and output-purposes.
<some text deleted>
> I do not see how this information flow control can be easily expressed wi=
th=20
> 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.

> Besides, in order to implement operational separation of duties and to=20
> prevent misuse, all security attributes can only be defined and set by tw=
o=20
> authorized person in cooperation. One is the user in the role data=20
> protection officer (appointed according to German/European privacy=20
> legislation), who creates a ticket to define the security attribute=20
> value/allocation, and one is the user in the role security-officer, who c=
an=20
> then use the ticket to set the respective attribute.
> Besides, there is another condition that only users in the role TP-manage=
r=20
> can define transformation procedures (TPs), but only the security officer=
=20
> in cooperation with the data protection officer is allowed to authorize=
=20
> users for the execution of TPs.
> I do not think that you have such a functionality in RBAC/TE so far ?

As I've said in my response to Amon Ott, you can model n-person control
through pipelines.  But I also suspect that some of these requirements
will end up being enforced by applications in real-world environments,
because they will deal with application services and abstractions such as
database queries and database records that do not map directly onto
individual OS services and abstractions.  In such cases, the OS
can still provide support by protecting the applications against
bypass or tampering, and by confining the potential damage that
can be caused by an errant application.  But such protections
do not require the same logic in the OS security policy.

> Can you also implement access 4-tuples (as we have them in PM), expressin=
g=20
> with what task by performing what TP you can access what object class in=
=20
> what mode ?

In the RBAC/TE model of SELinux, a task could either be a role
or a particular domain within a role.  A TP could either be a
domain or a derived domain (subdomain) that can be entered by
the task through the execution of a program type.  You would
then define permissions from the TP domain to the desired objects,
based on the type and class of the objects.

> Well, this seems to be possible, but then you wont have any easy and=20
> transparent administration of access rights any longer (which should be o=
ne=20
> of the advantage of Role Based Access Control -RBAC).
> Just imagine that you model in your system 10 different purposes. This=20
> means that you have to model with TE 1024 different types (for all possib=
le=20
> 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.

> Besides, by relabeling the personal data to include another purpose to=20
> which the data subjects have agreed, you change the real semantic of the=
=20
> O-purposes attribute of data, which should only stand for the purposes fo=
r=20
> which data for initially collected. Relabeling data in case of a consent=
=20
> would in this case also require that you have to change the type (encodin=
g=20
> 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.


--
Stephen D. Smalley, NAI Labs
ssmalley@nai.com




-
To unsubscribe from the rsbac list, send a mail to
majordomo@rsbac.org with
unsubscribe rsbac
as single line in the body.
Go to Compuniverse LWGate Home Page.