Re: Rule Set Based Access Control (RSBAC)

Re: Rule Set Based Access Control (RSBAC)

[Hubertus Franke]

Looks interesting and reasonable comprehensive.
Could Pete Loscocco or Stephen Smalley give a quick overview
what they think is different in SELinux vs. the RSBAC  system.


Hubertus Franke
Enterprise Linux Group (Mgr),  Linux Technology Center (Member Scalability)
, OS-PIC (Chair)
email: frankeh@us.ibm.com
(w) 914-945-2003    (fax) 914-945-4425   TL: 862-2003



Manoj Srivastava <manoj.srivastava@stdc.com>@tycho.nsa.gov on 04/02/2001
12:44:18 AM

Sent by:  owner-selinux@tycho.nsa.gov


To:   selinux@tycho.nsa.gov
cc:
Subject:  Rule Set Based Access Control (RSBAC)



Hi,

        I am beginning to evaluate SELinux for my company, and I ran
 across RSBAC (http://www.rsbac.de/index.htm) while still in the
 background research phase. Has anyone done a comparison of RSBAC? It
 sounds like it is in the same ballpark as SELinux, and seems to have
 some additional goodies like ACL's.


     manoj

ps. From the web page above:
     ----------------------------------------------------------------------
What is RSBAC?

   RSBAC is a flexible, powerful and fast open source access control
   framework for current Linux kernels, which has been in stable
   production use for over a year (since version 1.0.9a).

   The standard package includes a range of access control models like
   MAC, RC, ACL (see below). Furthermore, the runtime registration
   facility (REG) makes it easy to implement your own access control
   model as a kernel module and get it registered at runtime.

   The RSBAC framework is based on the Generalized Framework for
   Access Control (GFAC) by Abrams and LaPadula. All security relevant
   system calls are extended by security enforcement code. This code
   calls the central decision component, which in turn calls all
   active decision modules and generates a combined decision. This
   decision is then enforced by the system call extensions.

   Decisions are based on the type of access (request type), the
   access target and on the values of attributes attached to the
   subject calling and to the target to be accessed. Additional
   independent attributes can be used by individual modules, e.g. the
   privacy module (PM). All attributes are stored in fully protected
   directories, one on each mounted device.  Thus changes to
   attributes require special system calls provided.

   As all types of access decisions are based on general decision
   requests, many different security policies can be implemented as a
   decision module.  Apart from the builtin models shown below, the
   optional Module Registration (REG) allows for registration of
   additional, individual decision modules at runtime.
----------------------------------------------------------------------


--
 In Corning, Iowa, it's a misdemeanor for a man to ask his wife to
 ride in any motor vehicle.
Manoj Srivastava   <manoj.srivastava@stdc.com>    <srivasta@acm.org>
1024R/C7261095 print CB D9 F4 12 68 07 E4 05  CC 2D 27 12 1D F5 E8 6E
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C

--
You have received this message because you are subscribed to the selinux
list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov
with
the words "unsubscribe selinux" without quotes as the message.




--
You have received this message because you are subscribed to the selinux list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: Rule Set Based Access Control (RSBAC)

[Stephen Smalley]

We've looked at RSBAC, since it has a number of similarities
to SELinux.  In the following discussion, I'll try to summarize
some of our observations about how RSBAC compares with SELinux.
Of course, I'll welcome correction if I am in error about
some aspect of RSBAC.

RSBAC is based on the Generalized Framework for Access Control
(GFAC), while SELinux is based on the Flask security architecture.
Like the Flask architecture, the GFAC separates policy from
enforcement and can support a variety of security policies.
With regard to the specific policy modules implemented in
the two systems, RSBAC provides a Role Compatibility policy module 
that has similarities to the SELinux Type Enforcement policy module.

However, RSBAC also differs from SELinux in a number of ways:

1) The GFAC does not specifically address the issue of atomic policy
changes, so RSBAC lacks the SELinux support for dynamic security 
policies and revocation.

2) RSBAC does not appear to provide policy-independent data types for
security labels (the security context and security identifier in
Flask/SELinux), and it appears to expose policy-specific data types in
its kernel ADF interfaces (through attribute parameters), new system
calls, and on-disk file labels.  Furthermore, the kernel ADF depends on
private kernel data structures and data types, and even takes pointers to
private kernel objects as parameters through an attribute structure for
some decisions.  This weakens the separation between policy and
enforcement.  SELinux provides cleaner separation between the policy and
enforcement through its data types, interfaces, and even in its
security server implementation.  In part, this cleaner separation is a
historical consequence of the fact that the security server was
originally a user space server running on a microkernel in the
predecessors of SELinux (DTMach, DTOS, and Flask).  In SELinux,
the security server is a kernel subsystem, like the RSBAC ADF,
but the interface still provides the same separation as in its
predecessor systems.

3) RSBAC does not appear to have an equivalent to the SELinux
access vector cache (AVC) or AVC entry references in order
to minimize the performance overhead of its controls.

4) RSBAC appears to lack equivalents for the extended API calls and new
API calls of SELinux, instead only providing calls for setting and getting
attributes of existing subjects and objects.  SELinux provides
extended versions of existing system calls for creating new subjects
and objects with specified labels (execve_secure, mkdir_secure).
It also provides new API calls to allow applications to obtain
security policy decisions from the security server in order to
support application policy enforcers.  For example, a windowing
system might be enhanced to provide labeling and separation of
windows, with controlled cut-and-paste between windows, or
a database management system might be enhanced to provide
labeling and separation of individual database records maintained
in a single file.  These application policy enforcers would
still be controlled by the kernel, but could further refine
the granularity of protection provided by the kernel.

5) RSBAC appears to lack a number of the controls provided by SELinux for
each of the kernel subsystems.  Some examples of such gaps in its
controls include:  consistent controls on changes in process
labels, controls on the inheritance and transfer of open file
descriptions across execve or via local IPC, control of asynchronous I/O
signals, control of receiving the exit status via wait, controls on
the use of Linux capabilities, failure to check permission to
all affected directories and files for several of the directory
operations, and the lack of an equivalent to the layered networking
controls provided by SELinux.  Furthermore, the SELinux controls are
designed to address both the case where the ordinary API call is used
(e.g. execve) and the case where the extended API call is used (e.g.
execve_secure) in a consistent manner, while the RSBAC controls
only address the ordinary API calls.

6) RSBAC uses the Linux real user identity attribute for its decisions
and must control changes to this attribute, so it is not completely
orthogonal to the existing Linux access controls.  There is
a configuration option for maintaining a separate user identity
attribute, but the option is not robust and is not recommended.
SELinux maintains a separate user identity attribute as part
of the process security context, and is not dependent on the Linux 
identity attributes for the correct enforcement of the mandatory 
security policy.

7) Most of the RSBAC policy modules are very hardwired in their
policy logic, and can be easily expressed using the SELinux Type
Enforcement (TE) configuration.  The RSBAC Role Compatibility (RC) module 
has many parallels to TE, but it seems to be weaker in its
controls over role/domain changes and it has special cases
that are more cleanly addressed in the TE configuration (e.g.
its special values for inheritance vs. TE transition rules).
The RC module also has some implementation limitations (e.g.
limitation to 64 roles and types) while the SELinux TE module
has no such fixed limitation.  RSBAC does not appear to have an equivalent
to the human-readable SELinux policy configuration files, and it requires
that the policy be configured through a set of new utilities that use new
system calls. 

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









--
You have received this message because you are subscribed to the selinux list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: Rule Set Based Access Control (RSBAC)

[Amon Ott]

Hi!

As the main author of RSBAC, I will try to pick up some issues Stephen Smalley
pointed out. In the end, we might both end up with some new ideas.

My main problem sure is the lack of detailed knowledge about the SELinux
implementation, I just do not have the time to follow its development in detail.

On Mon, 02 Apr 2001 Stephen Smalley wrote:
> We've looked at RSBAC, since it has a number of similarities
> to SELinux.  In the following discussion, I'll try to summarize
> some of our observations about how RSBAC compares with SELinux.
> Of course, I'll welcome correction if I am in error about
> some aspect of RSBAC.

Here we are...
 
> RSBAC is based on the Generalized Framework for Access Control
> (GFAC), while SELinux is based on the Flask security architecture.
> Like the Flask architecture, the GFAC separates policy from
> enforcement and can support a variety of security policies.
> With regard to the specific policy modules implemented in
> the two systems, RSBAC provides a Role Compatibility policy module 
> that has similarities to the SELinux Type Enforcement policy module.
> 
> However, RSBAC also differs from SELinux in a number of ways:
> 
> 1) The GFAC does not specifically address the issue of atomic policy
> changes, so RSBAC lacks the SELinux support for dynamic security 
> policies and revocation.

All policy changes get into effect at once, so the next access control decision
will be based on the new settings. If you e.g. want to revoke file access, turn
on READ/WRITE interception, and after revoking the rights, all following read
attempts will fail.

> 2) RSBAC does not appear to provide policy-independent data types for
> security labels (the security context and security identifier in
> Flask/SELinux),

This is true, there had been no need for them. I rather wanted to have the
compiler control all data types. For the extended runtime policy registration
(REG), generic data storage is in progress.

> and it appears to expose policy-specific data types in
> its kernel ADF interfaces (through attribute parameters), new system
> calls, and on-disk file labels. 

Each decision module controls, which if its attributes can be accessed (read or
modified) by which subject. The attribute names are not hidden ('security by
obscurity'), because there is no need to do that. On-disk attribute data is
inaccessible for any user process.

> Furthermore, the kernel ADF depends on
> private kernel data structures and data types, and even takes pointers to
> private kernel objects as parameters through an attribute structure for
> some decisions.  This weakens the separation between policy and
> enforcement.

Yes, there are pointers given, e.g. dentry pointers. This is necessary for
attribute value inheritance from parent objects (or do you know a better way?).
However, no data in kernel structs is ever modified. Most of these extra
attributes contain simple integer values, e.g. the uid for a CHANGE_OWNER
request.

>  SELinux provides cleaner separation between the policy and
> enforcement through its data types, interfaces, and even in its
> security server implementation.  In part, this cleaner separation is a
> historical consequence of the fact that the security server was
> originally a user space server running on a microkernel in the
> predecessors of SELinux (DTMach, DTOS, and Flask).  In SELinux,
> the security server is a kernel subsystem, like the RSBAC ADF,
> but the interface still provides the same separation as in its
> predecessor systems.

As stated above, I cannot comment on SELinux details. Still, while depending on
some kernel values, this is only gathering data, not deciding anything.

You also have to provide kernel data somehow, because you want to decide about
subjects and objects identified by this data.
   
> 3) RSBAC does not appear to have an equivalent to the SELinux
> access vector cache (AVC) or AVC entry references in order
> to minimize the performance overhead of its controls.

Did you ever benchmark the access control overhead? RSBAC numbers told me to
rather spend work on other parts (see file benchmarks.htm).
  
> 4) RSBAC appears to lack equivalents for the extended API calls and new
> API calls of SELinux, instead only providing calls for setting and getting
> attributes of existing subjects and objects.  SELinux provides
> extended versions of existing system calls for creating new subjects
> and objects with specified labels (execve_secure, mkdir_secure).

For me, this is a clear RSBAC advantage. How many applications are you going to
change for your access control system? How will you keep up to date? How does
the user get support for arbitrary applications?

Careful planning has been done in RSBAC design to *avoid* change of existing
applications to new APIs. This has been done by providing several default value
settings in RSBAC administration. If you need other settings, OK, you can still
apply them after creation etc.

If the (small) time window is a problem, then you have an argument here. You
would have to create in a protected directory, set attributes and move the file
to its final destination.

BTW: For PM model, there are specific calls to create files of certain object
types - the model design does not provide default types.

As to subjects: User accounts are not (yet) controlled by the kernel anyway.
This has to be changed soon to get real kernel security.

So let's come to processes. Here you are wrong: Process attributes are
initialized by the decision modules directly after creation, and before control
is returned to the forking or the new process.

[SELinux]
> It also provides new API calls to allow applications to obtain
> security policy decisions from the security server in order to
> support application policy enforcers.  For example, a windowing
> system might be enhanced to provide labeling and separation of
> windows, with controlled cut-and-paste between windows, or
> a database management system might be enhanced to provide
> labeling and separation of individual database records maintained
> in a single file.  These application policy enforcers would
> still be controlled by the kernel, but could further refine
> the granularity of protection provided by the kernel.

This has been thought about in RSBAC, too (see Nordsec paper on Malware
Scanning). What already exists is the request function itself, which can be
called from within the kernel. The necessary glue to user space can easily be
provided by a kernel module.    

> 5) RSBAC appears to lack a number of the controls provided by SELinux for
> each of the kernel subsystems.  Some examples of such gaps in its
> controls include:  consistent controls on changes in process
> labels,

OK, if you think this is security relevant.

> controls on the inheritance and transfer of open file
> descriptions across execve or via local IPC,

True, but reading from and writing to them is controlled, so what will you use
them for?

> control of asynchronous I/O
> signals, control of receiving the exit status via wait,

OK, if you think that security relevant *and* not sufficiently covered by
existing mechanisms.

> controls on
> the use of Linux capabilities, 

What for? I do not mess with the existing discretionary access control, it is
completely independent. I only control access control data that is relevant for
RSBAC.

> failure to check permission to
> all affected directories and files for several of the directory
> operations,

Which ones? If I missed some security relevant ones, those are bugs to be fixed.

> and the lack of an equivalent to the layered networking
> controls provided by SELinux.

Real, subject and object based network access control has been designed and will
be implemented for version 1.2.0. Clearly, the current network access control is
insufficient.

>  Furthermore, the SELinux controls are
> designed to address both the case where the ordinary API call is used
> (e.g. execve) and the case where the extended API call is used (e.g.
> execve_secure) in a consistent manner, while the RSBAC controls
> only address the ordinary API calls.

No argument, because there are (and will be) no extended APIs in RSBAC (s.a.).
 
> 6) RSBAC uses the Linux real user identity attribute for its decisions
> and must control changes to this attribute, so it is not completely
> orthogonal to the existing Linux access controls.

It is not as independent as it could be. But at least, I do not mess with
capabilities... ;)

I believe that a common thing in all access control models that reside on a
single system is the identity of a user. This is what authentication is meant
to be about.

If users need more than one identity, the model is wrong. She should rather
need several roles, or transaction procedures with additional rights, or
whatever.

> There is
> a configuration option for maintaining a separate user identity
> attribute, but the option is not robust and is not recommended.
> SELinux maintains a separate user identity attribute as part
> of the process security context, and is not dependent on the Linux 
> identity attributes for the correct enforcement of the mandatory 
> security policy.

For my above reasons, the option has been kept inactive. Stability was another
reason which added in the decision, but would be no reason now. The option has
not yet disappeared completely, because I thought about porting to other
operating system types with possibly other user id concepts, e.g. name based.

> 7) Most of the RSBAC policy modules are very hardwired in their
> policy logic, and can be easily expressed using the SELinux Type
> Enforcement (TE) configuration.

I'd really like to see that expressed for PM or RC with ACLs. The logic is
hardwired, because it expresses a fixed model. What is the difference to a
model implemented in a description language other than C, e.g. your description
files? For me it is mostly a significant speedup.

>  The RSBAC Role Compatibility (RC) module 
> has many parallels to TE, but it seems to be weaker in its
> controls over role/domain changes and it has special cases
> that are more cleanly addressed in the TE configuration (e.g.
> its special values for inheritance vs. TE transition rules).

I'll have to get a closer look into your model. We seem to have addressed
similar problems, e.g. transaction procedure support.

What do you think is weaker in the role/domain changes controls of RC?

> The RC module also has some implementation limitations (e.g.
> limitation to 64 roles and types) while the SELinux TE module
> has no such fixed limitation.

This was a compromise with performance. Still, I won't agree to it being a
limitation until you give me an example, where you need more than 64 roles in a
single system, and do not think ACLs to be a better solution.

To give you an example: Our Compuniverse communication server configurations
with firewalling, proxies, Mail server, Webserver, several Web interfaces, Fax
server, Internet application server (Netscape etc.), etc. currently use 13
roles and 15 File/Dir types. I am running out of ideas what to use more roles
and types for.

Also, please do not forget that RSBAC is designed to *combine* different
models - if RC is not suitable, also use MAC or ACL.

> RSBAC does not appear to have an equivalent
> to the human-readable SELinux policy configuration files, and it requires
> that the policy be configured through a set of new utilities that use new
> system calls. 

As explained above, I believe separate mechanisms for RSBAC administration to
be a much better solution than hacking it into existing interfaces. What is the
problem with some extra system calls?


Hopefully, this text makes some ideas easier to understand.

Amon.

--
You have received this message because you are subscribed to the selinux list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: Rule Set Based Access Control (RSBAC)

[Stephen Smalley]

>In the end, we might both end up with some new ideas.

I think that this is a good perspective.  Both RSBAC and SELinux
appear to have similar goals and features, and I'm sure that
each project can learn from the other.

> All policy changes get into effect at once, so the next access control decision
> will be based on the new settings. If you e.g. want to revoke file access, turn
> on READ/WRITE interception, and after revoking the rights, all following read
> attempts will fail.

Our paper from the 8th USENIX Security Symposium (available via
http://www.nsa.gov/selinux/flask-abs.html) about the Flask
security architecture talks at length about the difficulty
in truly supporting dynamic security policies.  You need to
address the potential interleaving of policy changes with
the execution of controlled operations and provide an effective
atomicity for policy changes so that you know when the new policy
is truly in effect.  You also need a mechanism to revoke permissions that
are implicitly retained in the state of the system, e.g. open file
descriptions, memory-mapped files, established TCP connections,
and even operations currently in progress that have already checked
permissions.  The Flask architecture and interfaces were designed to
address these issues, and the SELinux controls were designed to permit
efficient revalidation of permissions on use for many services.  Although
it is true that RSBAC now provides optional READ/WRITE interception on
read/write calls, I don't think it fully addresses these issues.  SELinux
isn't perfect in this area either, but it provides the basic
infrastructure needed to support policy changes and it performs
revalidation of permissions for many services.

> This is true, there had been no need for them. I rather wanted to have the
> compiler control all data types. For the extended runtime policy registration
> (REG), generic data storage is in progress.

This issue is also discussed further in the aforementioned paper.
The content and format of security labels is dependent on the particular
security policy, so you need policy-independent data types for labels
in order to truly encapsulate the security policy.  In SELinux,
the security server interfaces for the kernel, the new system calls,
and the file labels make use of these policy-independent data types.
Hence, the content and format of security labels can be radically
revised without needing to change or even recompile anything other
than the security server.  Also, since the security contexts for
files are stored in each file system, human-readable and meaningful
security information is available if the file system is moved to
another system or the policy is changed, so translation of
security attributes is feasible. 

> Yes, there are pointers given, e.g. dentry pointers. This is necessary for
> attribute value inheritance from parent objects (or do you know a better way?).
> However, no data in kernel structs is ever modified. Most of these extra
> attributes contain simple integer values, e.g. the uid for a CHANGE_OWNER
> request.
> You also have to provide kernel data somehow, because you want to decide about
> subjects and objects identified by this data.

I would encourage you to take a look at the SELinux/Flask interfaces
described in the documentation.  We do not pass any pointers to
any private kernel objects to the security server.  The security
server only needs to know the security labels of the relevant
subjects and objects, not kernel objects or identifiers.  
In part, this difference is architectural - the GFAC subdivides
the responsibility between the enforcement code and the decision
facility differently than Flask.

> Did you ever benchmark the access control overhead? RSBAC numbers told me to
> rather spend work on other parts (see file benchmarks.htm).

Yes, we have run benchmarks, and the results will be published at
the upcoming Freenix.  Macrobenchmark tests (kernel compilation,
WebStone) had almost no overhead, so they didn't really show
the performance benefit of the cache.  But microbenchmark test suites
(lmbench, UnixBench) showed that the cache has a significant benefit
for the performance of individual operations.

> For me, this is a clear RSBAC advantage. How many applications are you going to
> change for your access control system? How will you keep up to date? How does
> the user get support for arbitrary applications?

Perhaps I was unclear.  SELinux is mostly transparent to applications
(except upon access failures, of course).  We provide a set of
extended and new API calls to allow modified and new applications
to be developed that have some degree of awareness of the new
security features.  But existing applications can certainly
run unchanged on SELinux and appropriate default behaviors
are applied when the ordinary API calls are used.  As an
example, we provide a modified ps program that displays
the security contexts of processes.  But you can run the
ordinary ps program if you want - you just won't see the
security contexts with it.  And notice that since we
provide policy-independent data types for security labels,
our modified ps program never needs to be changed even if
the format or content of security labels is radically revised.

> If the (small) time window is a problem, then you have an argument here. You
> would have to create in a protected directory, set attributes and move the file
> to its final destination.
> BTW: For PM model, there are specific calls to create files of certain object
> types - the model design does not provide default types.

Ok, so you already have a case where a policy module requires the
ability to allow applications to create files with a particular label.
By using policy-independent data types for labels, you can have
a single set of APIs (open_secure, mkdir_secure, etc) that can provide
this functionality for any policy.  And yes, it is important to be
able to create objects with a particular label rather than just
creating them with a default and then relabeling them.  Relabeling
has its own complications - do you fully address the revocation problem
for open file descriptions and memory-mapped files?

> As to subjects: User accounts are not (yet) controlled by the kernel anyway.
> This has to be changed soon to get real kernel security.

I'm not entirely sure what you mean by this statement.

> So let's come to processes. Here you are wrong: Process attributes are
> initialized by the decision modules directly after creation, and before control
> is returned to the forking or the new process.

Sure, process attributes are initialized on fork.  But I was talking
about an extended form of execve to allow changes in attributes
upon program execution.  That is the most natural point for
a change in attributes, because you can easily control the
inheritance of state and the initialization in the new label,
and you can establish a binding between the new label and
the executable.  RSBAC supports default label changes on execve
(e.g. RC forced role transitions), but doesn't provide any
way for an application to explicitly request such a transition.

> > It also provides new API calls to allow applications to obtain
> > security policy decisions from the security server in order to
> > support application policy enforcers.  For example, a windowing
> > system might be enhanced to provide labeling and separation of
> > windows, with controlled cut-and-paste between windows, or
> > a database management system might be enhanced to provide
> > labeling and separation of individual database records maintained
> > in a single file.  These application policy enforcers would
> > still be controlled by the kernel, but could further refine
> > the granularity of protection provided by the kernel.
> 
> This has been thought about in RSBAC, too (see Nordsec paper on Malware
> Scanning). What already exists is the request function itself, which can be
> called from within the kernel. The necessary glue to user space can easily be
> provided by a kernel module.    

Ok.  This has actually been done with one of our prior prototypes (DTOS).
One university integrated similar controls into the X Window System,
and another university provides similar functionality in a database
management system.

> OK, if you think that security relevant *and* not sufficiently covered by
> existing mechanisms.

With regard to specific controls, I would encourage you to look at
the Control Requirements sections in our design and implementation
document (available via http://www.nsa.gov/selinux/slinux-abs.html).
They specify the precise set of controls for each system call that
we defined.

> > controls on
> > the use of Linux capabilities, 
> 
> What for? I do not mess with the existing discretionary access control, it is
> completely independent. I only control access control data that is relevant for
> RSBAC.

A number of the capabilities are used to control highly privileged
system operations.  We could define our own separate set of permissions
and add checks to each such privileged operation, but it seems better
to leverage the work being done by the Linux-Privs people and
add a hook to the capable function to perform a permission check as well.
That allows the security policy to control all capability usage, and
thus control a large number of privileged operations with minimal
code modifications.

>  
> > 6) RSBAC uses the Linux real user identity attribute for its decisions
> > and must control changes to this attribute, so it is not completely
> > orthogonal to the existing Linux access controls.
> 
> I believe that a common thing in all access control models that reside on a
> single system is the identity of a user. This is what authentication is meant
> to be about.
> 
> If users need more than one identity, the model is wrong. She should rather
> need several roles, or transaction procedures with additional rights, or
> whatever.

The SELinux controls themselves are only based on a single user identity
- the user identity in the security context.  By providing a separate
usre identity attribute, we can enforce whatever controls we want
over changes to it without affecting compatibility.  I agree
that we want to establish the user's identity and then handle
any needed changes in access rights by changing the role/domain
rather than the user identity itself.  The concern with using the
existing Linux real uid is that we must then balance between
providing rigorous controls over changes to it and maintaining
compatibility.  There is also an acceptability concern; it
seems like the kernel developers would be more open to an
access control scheme that is orthogonal to the existing scheme
than one that is intermingled with it.

> I'll have to get a closer look into your model. We seem to have addressed
> similar problems, e.g. transaction procedure support.
> 
> What do you think is weaker in the role/domain changes controls of RC?

It appears that there are three ways a role change can occur in RSBAC RC:
1) when the Linux real uid is changed (in which case the role is typically
reset to the default role for the new uid), 2) by an explicit call to
change roles, 3) by executing a forced role program.  The RC role compatibility 
vector only controls role changes caused by an explicit system call to
change roles.  The other two kinds of role changes are not constrained by
this vector.

With the SELinux TE module, a domain transition can only occur via an
execve (or execve_secure), and is always controlled in a consistent
manner.  The controls ensure that the old domain can start the
program, that the old domain can transition to the new domain, and that
the new domain can be entered via the program.  They also address
issues such as inheritance of open file descriptions, continuance
of any process tracing in progress, sharing of any state across
the execve, and ultimately whether or not the new domain can
return an exit status to the old domain.  

> This was a compromise with performance. Still, I won't agree to it being a
> limitation until you give me an example, where you need more than 64 roles in a
> single system, and do not think ACLs to be a better solution.

The example configuration provided with SELinux defines 70 domains,
188 file types, and 38 other types (e.g. network-related types).
I don't think that supporting arbitrary numbers of domains and types
has much affect on the performance of our TE implementation.

> > RSBAC does not appear to have an equivalent
> > to the human-readable SELinux policy configuration files, and it requires
> > that the policy be configured through a set of new utilities that use new
> > system calls. 
> 
> As explained above, I believe separate mechanisms for RSBAC administration to
> be a much better solution than hacking it into existing interfaces. What is the
> problem with some extra system calls?

I probably wasn't clear.  With SELinux, you edit the human-readable policy
configuration files to set up your policy (starting with the example
configuration we provide if you want), then compile that policy
into a binary representation and install it.  You can then load
the updated policy into your running kernel (if the policy authorizes
such runtime changes) using a new system call, or you can reboot
(in which case the kernel will load the new policy when it
initializes).  My concern was with the need to run a special
set of utilities that use a special set of system calls to
customize the configuration, as opposed to being able to edit
human-readable configuration files.

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




--
You have received this message because you are subscribed to the selinux list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: Rule Set Based Access Control (RSBAC)

[Amon Ott]

On Die, 03 Apr 2001 Stephen Smalley wrote:
> > All policy changes get into effect at once, so the next access control decision
> > will be based on the new settings. If you e.g. want to revoke file access, turn
> > on READ/WRITE interception, and after revoking the rights, all following read
> > attempts will fail.
> 
> Our paper from the 8th USENIX Security Symposium (available via
> http://www.nsa.gov/selinux/flask-abs.html) about the Flask
> security architecture talks at length about the difficulty
> in truly supporting dynamic security policies.  You need to
> address the potential interleaving of policy changes with
> the execution of controlled operations and provide an effective
> atomicity for policy changes so that you know when the new policy
> is truly in effect.  You also need a mechanism to revoke permissions that
> are implicitly retained in the state of the system, e.g. open file
> descriptions, memory-mapped files, established TCP connections,
> and even operations currently in progress that have already checked
> permissions.  The Flask architecture and interfaces were designed to
> address these issues, and the SELinux controls were designed to permit
> efficient revalidation of permissions on use for many services.  Although

OK, full revoking on policy changes as well as atomicity on whole policy
changes has not been a goal for RSBAC. The revoking will probably not be done,
but atomicity might come. It should be rather easy to do for runtime loaded
policies.

> it is true that RSBAC now provides optional READ/WRITE interception on
> read/write calls, I don't think it fully addresses these issues.  SELinux
> isn't perfect in this area either, but it provides the basic
> infrastructure needed to support policy changes and it performs
> revalidation of permissions for many services.

So does it really e.g. change the access bits on open file descriptors or close
them, when the policy setting that originally granted access is now set so that
access would be denied?

RSBAC design never meant to address such very dynamic behaviour, because policy
changes were thought of as rare. I also did not like the idea of interfering
with such data structures - just thinking of different kernel branches with
different ways of working. There are already too many kernel version checks
necessary in the common RSBAC code.

How do you handle this with a common code base?
        
> > This is true, there had been no need for them. I rather wanted to have the
> > compiler control all data types. For the extended runtime policy registration
> > (REG), generic data storage is in progress.
> 
> This issue is also discussed further in the aforementioned paper.
> The content and format of security labels is dependent on the particular
> security policy, so you need policy-independent data types for labels
> in order to truly encapsulate the security policy.  In SELinux,
> the security server interfaces for the kernel, the new system calls,
> and the file labels make use of these policy-independent data types.
> Hence, the content and format of security labels can be radically
> revised without needing to change or even recompile anything other
> than the security server.  Also, since the security contexts for
> files are stored in each file system, human-readable and meaningful
> security information is available if the file system is moved to
> another system or the policy is changed, so translation of
> security attributes is feasible. 

The fixed RSBAC models were implemented in such a hardwired way, because it
should be conceptually impossible to change them at runtime. Thus I saw no need
for type abstraction, and sure the compiler type checks were useful for coding.

Runtime loaded and registered policies are different. They already have their
opaque data types for registered syscalls, and they will get their persistent,
abstract data storage some time soon.

> > Yes, there are pointers given, e.g. dentry pointers. This is necessary
for
> > attribute value inheritance from parent objects (or do you know a
better way?). > > However, no data in kernel structs is ever modified. Most of
these extra > > attributes contain simple integer values, e.g. the uid for a
CHANGE_OWNER > > request.
> > You also have to provide kernel data somehow, because you want to decide about
> > subjects and objects identified by this data.
> 
> I would encourage you to take a look at the SELinux/Flask interfaces
> described in the documentation.  We do not pass any pointers to
> any private kernel objects to the security server.  The security
> server only needs to know the security labels of the relevant
> subjects and objects, not kernel objects or identifiers.  
> In part, this difference is architectural - the GFAC subdivides
> the responsibility between the enforcement code and the decision
> facility differently than Flask.

After having another look into RSBAC code: The only such pointer really used is
the dentry pointer. How do you handle attribute value inheritance in
filesystems? Do you have such a concept?

Inheritance is an important RSBAC concept, because it greatly reduces the
number of attribute structs ('labels') and makes administration easier.

> > For me, this is a clear RSBAC advantage. How many applications are you going to
> > change for your access control system? How will you keep up to date? How does
> > the user get support for arbitrary applications?
> 
> Perhaps I was unclear.  SELinux is mostly transparent to applications
> (except upon access failures, of course).  We provide a set of
> extended and new API calls to allow modified and new applications
> to be developed that have some degree of awareness of the new
> security features.  But existing applications can certainly
> run unchanged on SELinux and appropriate default behaviors
> are applied when the ordinary API calls are used.  As an
> example, we provide a modified ps program that displays
> the security contexts of processes.  But you can run the
> ordinary ps program if you want - you just won't see the
> security contexts with it.  And notice that since we
> provide policy-independent data types for security labels,
> our modified ps program never needs to be changed even if
> the format or content of security labels is radically revised.

Apart from really providing the programs, I do not see a big difference. The
application can handle extended or extra APIs as well as a limited set of data
types.

Not having to change the tool is sure an advantage, but policy independent ps
output must somehow be connected to the policy afterwards to be of any use, or
am I mistaken here? How is this problem handled? Sure you are not just moving
it to the administrators.

 > > If the (small) time window is a problem, then you
have an argument here. You > > would have to create in a protected directory,
set attributes and move the file > > to its final destination.
> > BTW: For PM model, there are specific calls to create files of certain object
> > types - the model design does not provide default types.
> 
> Ok, so you already have a case where a policy module requires the
> ability to allow applications to create files with a particular label.
> By using policy-independent data types for labels, you can have
> a single set of APIs (open_secure, mkdir_secure, etc) that can provide
> this functionality for any policy.  And yes, it is important to be
> able to create objects with a particular label rather than just
> creating them with a default and then relabeling them.  Relabeling
> has its own complications - do you fully address the revocation problem
> for open file descriptions and memory-mapped files?

As stated above, I do see the problem of time windows. The workaround stated
above still holds: Create the object in a fully controlled environment and move
it after setting the values.

We still seem to have some difference in the way we look at security models:
For me, labelling by a subject should be an exception from the rule, because it
is a discretionary element. Whenever possible, the labels should be mandatory,
chosen by predefined security settings, which are done with as much separation
of duty as possible.

Something special in my point of view is that I distrust all user mode
programs, because they come from unknown sources and might have been modified,
e.g. trojanized or infected by viruses. In some cases I have to rely on them,
e.g. for the (insuffient) Linux style user authentication.

Here we are again with my hardwired policies: They can only be changed by
modifying the kernel source, recompiling the kernel, installing it and
rebooting. Most of the steps can be easily prevented by security settings.

> > As to subjects: User accounts are not (yet) controlled by
the kernel anyway. > > This has to be changed soon to get real kernel security.
> 
> I'm not entirely sure what you mean by this statement.

For me, the current Linux authentication scheme with free setuid for all
programs running as root, files containing passwords with weak encryption,
daemon communication over insecure protocols etc. is a terrible mess, inviting
people to break into the system.

Real account management should be in the kernel, with strong data protection,
strong on-disk encryption and setuid limitation by this account management to
those ids which have been authenticated by the process asking.

> > So let's come to processes. Here you are wrong: Process attributes are
> > initialized by the decision modules directly after creation, and before control
> > is returned to the forking or the new process.
> 
> Sure, process attributes are initialized on fork.  But I was talking
> about an extended form of execve to allow changes in attributes
> upon program execution.  That is the most natural point for
> a change in attributes, because you can easily control the
> inheritance of state and the initialization in the new label,
> and you can establish a binding between the new label and
> the executable.  RSBAC supports default label changes on execve
> (e.g. RC forced role transitions), but doesn't provide any
> way for an application to explicitly request such a transition.

S.a.: I never saw this as something that important, because the model and not
the subject should provide the labels.

Taking the fork example: After forking, the new process usually is a full copy
of the old one. So all labels are simply copied by the models, because the
processes differ by pid only . If the new process wants to do something
different, it can execute another program (labels are changed by the models), or
it can e.g. ask to be allowed to work with another role (RC example).

> > OK, if you think that security relevant *and* not sufficiently covered by
> > existing mechanisms.
> 
> With regard to specific controls, I would encourage you to look at
> the Control Requirements sections in our design and implementation
> document (available via http://www.nsa.gov/selinux/slinux-abs.html).
> They specify the precise set of controls for each system call that
> we defined.
> 
> > > controls on
> > > the use of Linux capabilities, 
> > 
> > What for? I do not mess with the existing discretionary access control, it is
> > completely independent. I only control access control data that is relevant for
> > RSBAC.
> 
> A number of the capabilities are used to control highly privileged
> system operations.  We could define our own separate set of permissions
> and add checks to each such privileged operation, but it seems better
> to leverage the work being done by the Linux-Privs people and
> add a hook to the capable function to perform a permission check as well.
> That allows the security policy to control all capability usage, and
> thus control a large number of privileged operations with minimal
> code modifications.
 
But here you interfere with the existing Linux access control scheme, which
might want to set the capabilities differently.
Or are you only talking about the place of interception of the object access?
Then you have a point here, it could really reduce the modifications, but it
gives you less data to decide upon.

> > > 6) RSBAC uses the Linux real user identity attribute for its decisions
> > > and must control changes to this attribute, so it is not completely
> > > orthogonal to the existing Linux access controls.
> > 
> > I believe that a common thing in all access control models that reside on a
> > single system is the identity of a user. This is what authentication is meant
> > to be about.
> > 
> > If users need more than one identity, the model is wrong. She should rather
> > need several roles, or transaction procedures with additional rights, or
> > whatever.
> 
> The SELinux controls themselves are only based on a single user identity
> - the user identity in the security context.  By providing a separate
> usre identity attribute, we can enforce whatever controls we want
> over changes to it without affecting compatibility.  I agree
> that we want to establish the user's identity and then handle
> any needed changes in access rights by changing the role/domain
> rather than the user identity itself.  The concern with using the
> existing Linux real uid is that we must then balance between
> providing rigorous controls over changes to it and maintaining
> compatibility.  There is also an acceptability concern; it
> seems like the kernel developers would be more open to an
> access control scheme that is orthogonal to the existing scheme
> than one that is intermingled with it.

How do you authenticate and set another id then? Do you provide modified
programs with extra calls for all such cases?

You already pointed out that RSBAC originally had its own process owner
attribute. For usability, I ended up setting it at the same places where the
real uid was set. So I made it optional. Later I realized that I never used
that option, so it got removed. All instability problems could have been
solved, but I just did not see the point in this extra complexity.

> > This was a compromise with performance. Still, I won't agree to it being a
> > limitation until you give me an example, where you need more than 64 roles in a
> > single system, and do not think ACLs to be a better solution.
> 
> The example configuration provided with SELinux defines 70 domains,
> 188 file types, and 38 other types (e.g. network-related types).

And you are sure you do not want to use ACLs instead? How do you keep the
overview over 70 domains and filesystems with 188 file types?

How many domains are for single users only?

> I don't think that supporting arbitrary numbers of domains and types
> has much affect on the performance of our TE implementation.

Access control decisions in RC model are based on bit vectors, combined by
simple and fast logical operations, e.g. if(a & b).  So the limit to 64 bits by
the largest integer type was natural. An unlimited scheme would have needed
lists with search operations or at least dynamical arrays.

> > > RSBAC does not appear to have an equivalent
> > > to the human-readable SELinux policy configuration files, and it requires
> > > that the policy be configured through a set of new utilities that use new
> > > system calls. 
> > 
> > As explained above, I believe separate mechanisms for RSBAC administration to
> > be a much better solution than hacking it into existing interfaces. What is the
> > problem with some extra system calls?
> 
> I probably wasn't clear.  With SELinux, you edit the human-readable policy
> configuration files to set up your policy (starting with the example
> configuration we provide if you want), then compile that policy
> into a binary representation and install it.  You can then load
> the updated policy into your running kernel (if the policy authorizes
> such runtime changes) using a new system call, or you can reboot
> (in which case the kernel will load the new policy when it
> initializes).  My concern was with the need to run a special
> set of utilities that use a special set of system calls to
> customize the configuration, as opposed to being able to edit
> human-readable configuration files.

To keep in these terms: With RSBAC, you can either
1) change your model implementation module, recompile and replace the old one
(under control of the old module), or
2) Make a backup script out of your configuration settings, modify the
(human readable) script and run it to get the new settings.

For security reasons, RSBAC does not allow to modify the settings file
directly, but you could simply run a setup script at boot time - if this script
is allowed to modify the settings.

Out of interest: How is your binary policy representation protected against
unwanted modification?

Amon.

--
You have received this message because you are subscribed to the selinux list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: Rule Set Based Access Control (RSBAC)

[Stephen Smalley]

> So does it really e.g. change the access bits on open file descriptors or close
> them, when the policy setting that originally granted access is now set so that
> access would be denied?

For open file descriptions, SELinux simply revalidates permission on use,
so it doesn't need to modify the file flags or close the descriptors.
The AVC entry references allow SELinux to perform such revalidation
without the overhead of a full permission check computation unless
the policy has changed.  For memory-mapped files, SELinux
invalidates the page cache entries for the relevant file and 
revalidates permission on the subsequent page fault (this support is 
not yet complete in our 2.4 version). 

> The fixed RSBAC models were implemented in such a hardwired way, because it
> should be conceptually impossible to change them at runtime. Thus I saw no need
> for type abstraction, and sure the compiler type checks were useful for coding.

But this is contrary to being flexible in the ability to add, remove,
or completely replace policy modules in the ADF without affecting the rest
of the kernel or applications that deal with labels.

> After having another look into RSBAC code: The only such pointer really used is
> the dentry pointer. How do you handle attribute value inheritance in
> filesystems? Do you have such a concept?
> 
> Inheritance is an important RSBAC concept, because it greatly reduces the
> number of attribute structs ('labels') and makes administration easier.

By inheritance, do you simply mean the behavior when a file
is created and initially assigned a label or do you mean
an implicit labeling mechanism similar to the implicit
typing of DTE?  SELinux stores file labels explicitly,
but it allows labels to be managed using a higher-level
specification based on pathname regular expressions.
We support inheritance of attributes when files are
created, but each file has its own label.  However,
the technique used to store those labels only needs
to store each distinct label once.

> Not having to change the tool is sure an advantage, but policy independent ps
> output must somehow be connected to the policy afterwards to be of any use, or
> am I mistaken here? How is this problem handled? Sure you are not just moving
> it to the administrators.

The two policy-independent data types for security labels are
the security context and the security identifier (SID).  The
security context is simply a human-readable string representation of the
security attributes, while the security identifier is simply
a nonpersistent, local integer that refers to a security context.
Applications such as the modified ps can simply handle and display
security contexts without needing to deal with the internal content and
format of such contexts.  The file system code can likewise handle and
store security contexts for persistent labels (using an intermediate
mapping of persistent security identifiers for efficiency) without
needing to deal with the internals of labels.  Most of the kernel
can simply deal with SIDs for active subjects and objects.  So
you can add or remove attribute fields or completely replace
the security label format/contents without any impact on 
applications or kernel code that deals with labels.

> We still seem to have some difference in the way we look at security models:
> For me, labelling by a subject should be an exception from the rule, because it
> is a discretionary element. Whenever possible, the labels should be mandatory,
> chosen by predefined security settings, which are done with as much separation
> of duty as possible.
> 
> Something special in my point of view is that I distrust all user mode
> programs, because they come from unknown sources and might have been modified,
> e.g. trojanized or infected by viruses. In some cases I have to rely on them,
> e.g. for the (insuffient) Linux style user authentication.

I don't think we really disagree here.  As much as possible, we try to
provide complete transparency to applications through default labeling
behaviors.  But we also believe that there are valid reasons for
providing extended APIs to certain applications.  Providing those
extended APIs doesn't weaken our security, because a single set
of consistent controls is defined that addresses both the ordinary
calls and the extended calls.

> But here you interfere with the existing Linux access control scheme, which
> might want to set the capabilities differently.
> Or are you only talking about the place of interception of the object access?
> Then you have a point here, it could really reduce the modifications, but it
> gives you less data to decide upon.

In addition to our other controls, we provide a parallel
"interception"/control for each of the Linux capabilities that is
implemented in the existing capable function.  That allow us to
leverage what the Linux-Privs people have done to trivially
control a number of privileged operations.  We aren't interfering
with the Linux capabilities scheme any more than we are interfering
with the Linux DAC scheme - we simply provide an additional,
orthogonal control that must also authorize the operation.

> How do you authenticate and set another id then? Do you provide modified
> programs with extra calls for all such cases?

We provide a slightly modified login program to set the initial
security context for the user's login session.  Alternatively,
we could have left login alone and provided a new program
for authenticating and setting our user identity after login,
but it was cleaner to modify login.  Otherwise, we don't care
about changes in the Linux identity attributes during a login
session - they aren't relevant to our controls.

> And you are sure you do not want to use ACLs instead? How do you keep the
> overview over 70 domains and filesystems with 188 file types?
> How many domains are for single users only?

Most of the domains are simply for the various system daemons
and for programs that require special access rights.  For example,
we define domains for init, the rc scripts, getty, syslogd,
klogd, crond, login, inetd, tcpd, ftpd, etc.  For some
programs, we define multiple domains depending on the context
in which they were called, e.g. login runs in different domains
with different permissions depending on whether it was executed
by getty, rlogind, or sshd.  Programs that require special
access rights like insmod or fsck are placed into their
own domains, and we restrict the ability to enter these
domains.

For users, we currently just define two initial login domains, one 
for ordinary users and one for administrators.  However, as users
run programs, these domains automatically transition to derived
domains as needed to gain or shed access rights.  For example,
when users run netscape, they transition to a less privileged
domain so that any downloaded code is confined.  When users
run passwd, they transition to a more privileged domain that
can modify the passwd file.

> Out of interest: How is your binary policy representation protected against
> unwanted modification?

In the same way that any other file is protected - by labeling
appropriately and defining the policy so that write access 
is highly restricted.

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





--
You have received this message because you are subscribed to the selinux list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: Rule Set Based Access Control (RSBAC)

[Amon Ott]

On Mit, 04 Apr 2001 Stephen Smalley wrote:
> > The fixed RSBAC models were implemented in such a hardwired way, because it
> > should be conceptually impossible to change them at runtime. Thus I saw no need
> > for type abstraction, and sure the compiler type checks were useful for coding.
> 
> But this is contrary to being flexible in the ability to add, remove,
> or completely replace policy modules in the ADF without affecting the rest
> of the kernel or applications that deal with labels.

No, you can always add or remove policies by kernel configuration, the
unneeded attributes are then simply unused.

One advantage of keeping e.g. all user attributes in one struct is that for a
run through all decision modules, only one full entry lookup is needed. For the
second and following attribute readings or settings for this user, there is a
shortcut pointer.

> > After having another look into RSBAC code: The only such pointer really used is
> > the dentry pointer. How do you handle attribute value inheritance in
> > filesystems? Do you have such a concept?
> > 
> > Inheritance is an important RSBAC concept, because it greatly reduces the
> > number of attribute structs ('labels') and makes administration easier.
> 
> By inheritance, do you simply mean the behavior when a file
> is created and initially assigned a label or do you mean
> an implicit labeling mechanism similar to the implicit
> typing of DTE?  SELinux stores file labels explicitly,
> but it allows labels to be managed using a higher-level
> specification based on pathname regular expressions.
> We support inheritance of attributes when files are
> created, but each file has its own label.  However,
> the technique used to store those labels only needs
> to store each distinct label once.

In RSBAC, each object can also have its own attribute struct object. However,
in most cases all attribute settings are default values, e.g. 'inherit from
parent'. Struct objects with default values only are regularly cleaned up to
keep the lists small.

When a value is set, a new object is created. When a value is requested, but
there is no struct object, the default values are returned.

An attribute value of 'inherit from parent' means that the lookup recurses to
the next higher object level, e.g. the directory a file is in. If there is no
higher level, but also no struct object for the current object, real default
values are returned.

E.g. ACL model has another, more sophisticated inheritance scheme, with
inheritance masks and accumulation of user, role and group rights.

With this inheritance and default scheme, a complicated setup for a server with
a lot of services (like our Communication Server mentioned before) only needs a
few hundred attribute structs. Most of these are necessary, because /lib and
/usr/lib contain a mixture of libraries and non-libraries.

> > And you are sure you do not want to use ACLs instead? How do you keep the
> > overview over 70 domains and filesystems with 188 file types?
> > How many domains are for single users only?
> 
> Most of the domains are simply for the various system daemons
> and for programs that require special access rights.  For example,
> we define domains for init, the rc scripts, getty, syslogd,
> klogd, crond, login, inetd, tcpd, ftpd, etc.  For some
> programs, we define multiple domains depending on the context
> in which they were called, e.g. login runs in different domains
> with different permissions depending on whether it was executed
> by getty, rlogind, or sshd.  Programs that require special
> access rights like insmod or fsck are placed into their
> own domains, and we restrict the ability to enter these
> domains.

OK, I usually group these services into roles, or use the roles of the users
they run for. As they can only run as certain users (AUTH capability
restrictions), they cannot do much harm.
   
> For users, we currently just define two initial login domains, one 
> for ordinary users and one for administrators.  However, as users
> run programs, these domains automatically transition to derived
> domains as needed to gain or shed access rights.  For example,
> when users run netscape, they transition to a less privileged
> domain so that any downloaded code is confined.  When users
> run passwd, they transition to a more privileged domain that
> can modify the passwd file.

This is usually done with RC using forced roles. Netscape gets its own role,
which is used for all users and can only fully access /home dirs (with some
exceptions, e.g. loading files marked as libraries). Home dirs are protected
individually by either Linux flags or ACL entries with masks.
   
> > Out of interest: How is your binary policy representation protected against
> > unwanted modification?
> 
> In the same way that any other file is protected - by labeling
> appropriately and defining the policy so that write access 
> is highly restricted.

So this is done by careful administration, and probably giving write
access to your policy compiler run by special domains only.

Amon.

--
You have received this message because you are subscribed to the selinux list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: Rule Set Based Access Control (RSBAC)

[Stephen Smalley]

> No, you can always add or remove policies by kernel configuration, the
> unneeded attributes are then simply unused.

You can add policies that are in the set of fixed policies you provide.
But if you want to add a new policy module to this fixed set, then
you have to change a data structure that is visible across the
kernel ADF interface, new system call interfaces, and on-disk
file labels.  And why should users pay the cost for attributes
of policies they never intend to use?

> One advantage of keeping e.g. all user attributes in one struct is that for a
> run through all decision modules, only one full entry lookup is needed. For the
> second and following attribute readings or settings for this user, there is a
> shortcut pointer.

We also keep all of the attributes in a single struct, and only require
a single lookup of the security identifier (SID).  But the struct
definition is completely private to the security server.  Security
labels are only exported outside of the security server using the
policy-independent data types.

> An attribute value of 'inherit from parent' means that the lookup recurses to
> the next higher object level, e.g. the directory a file is in. If there is no
> higher level, but also no struct object for the current object, real default
> values are returned.
> 
> With this inheritance and default scheme, a complicated setup for a server with
> a lot of services (like our Communication Server mentioned before) only needs a
> few hundred attribute structs. Most of these are necessary, because /lib and
> /usr/lib contain a mixture of libraries and non-libraries.

What happens if a file has multiple hard links in different
directories with different attributes?  What happens if a file is
renamed to a directory with different attributes?  What happens
if a file system is mounted at multiple locations?  What happens
if you provide per-process namespaces?  

The explicit label bindings of SELinux only need to maintain
a single additional integer (the SID in memory, and the
persistent SID on disk) for each file.  Only a single copy
of each distinct security context (your attribute struct)
is needed.  Administrators can specify file labels recursively,
and even using pathname regular expressions, but the low-level
binding is explicit and avoids the problems associated with
implicit labeling schemes like yours (and also like DTE).

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




--
You have received this message because you are subscribed to the selinux list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: Rule Set Based Access Control (RSBAC)

[Amon Ott]

On Fre, 06 Apr 2001 Stephen Smalley wrote:
> > No, you can always add or remove policies by kernel configuration, the
> > unneeded attributes are then simply unused.
> 
> You can add policies that are in the set of fixed policies you provide.
> But if you want to add a new policy module to this fixed set, then
> you have to change a data structure that is visible across the
> kernel ADF interface, new system call interfaces, and on-disk
> file labels.  And why should users pay the cost for attributes
> of policies they never intend to use?

Every single model is free to implement its own data structures. PM, AUTH, RC
and ACL already do, but only ACL does not also use the general attribute
struct, except for log settings.

Changing the general structs extends the syscall interface, but it keeps
compatible with previous versions. This is only a matter of recompiling. The
general struct is just pretty convenient for fixed models, where attributes
rarely change.

The overhead of unused attributes is a rather small amount of memory only, and
the biggest parts of the struct are common values for log settings.

The more dynamic runtime added modules have to bring their own data
structures anyway, what is about to be changed to generic persistent data
handling. They can register as many syscalls as they like - without changes to
the framework or the system syscall table. Still, the possibility of runtime
policy modifications can lead to additional security compromises.

> > An attribute value of 'inherit from parent' means that the lookup recurses to
> > the next higher object level, e.g. the directory a file is in. If there is no
> > higher level, but also no struct object for the current object, real default
> > values are returned.
> > 
> > With this inheritance and default scheme, a complicated setup for a server with
> > a lot of services (like our Communication Server mentioned before) only needs a
> > few hundred attribute structs. Most of these are necessary, because /lib and
> > /usr/lib contain a mixture of libraries and non-libraries.
> 
> What happens if a file has multiple hard links in different
> directories with different attributes?

The directory you use for lookup is taken as the valid parent.

>  What happens if a file is
> renamed to a directory with different attributes?

It inherits the new directory's values. This is how the inheritance scheme is
meant to work. If you prefer different settings, you will have to set them
individually for this object. Putting the file into a different filesystem area
is treated as on purpose.

>  What happens
> if a file system is mounted at multiple locations?

The first mount point is taken as parent. This will probably be changed to
somehow reflect the lookup path. Multiple mounts have only recently been added
in the 2.3/2.4 kernel series and are not available in 2.2 kernels.

>  What happens
> if you provide per-process namespaces?  

This has not yet been worked out completely, so I cannot tell for sure. This is
also a rather new feature, which is (as far as I know) still not commonly used.
  
> The explicit label bindings of SELinux only need to maintain
> a single additional integer (the SID in memory, and the
> persistent SID on disk) for each file.  Only a single copy
> of each distinct security context (your attribute struct)
> is needed.  Administrators can specify file labels recursively,
> and even using pathname regular expressions, but the low-level
> binding is explicit and avoids the problems associated with
> implicit labeling schemes like yours (and also like DTE).

We implemented a similar scheme within PM data structures, where identifiers
are used to lookup in another lists. This is the old discussion about explicit
vs. implicit labels. The RSBAC decision for some models (not all) was for
implicit labels, depending on the object context and thus on changes at other
objects.

However, also with RSBAC you can use explicit labels everywhere, if you want
to. If explicit labelling only is chosen, the indirect scheme with SIDs is
probably a good solution - with a focus on inheritance and extensive use of
default values it mostly slows down the recursive lookup.

BTW: The switching between inheritance as default vs. explicit labels has only
for the last version 1.1.1 been reduced to MAC model. All other models that
support inheritance now default to inheritance.

Amon.

--
You have received this message because you are subscribed to the selinux list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: Rule Set Based Access Control (RSBAC)

[Amon Ott]

On Mon, 02 Apr 2001 Stephen Smalley wrote:
> 7) Most of the RSBAC policy modules are very hardwired in their
> policy logic, and can be easily expressed using the SELinux Type
> Enforcement (TE) configuration.

After rereading Section 'Overview' of your 'Security Policy Configuration'
paper, and remembering a similar claim at another place, which I had no way of
answering, I kindly ask for some explanation.

Without knowing your exact model details, I believe your claim 'can be easily
expressed using SELinux Type Enforcement' to be

- completely wrong for Privacy Model (PM), Malware Scan (MS), Role Compatibility
(RC) and Access Control Lists (ACL)

- doubtful for Mandatory Access Control (MAC), File Flags (FF) and
Authentication (AUTH)

- correct for the very simple models Functional Control (FC) and Security
Information Modification (SIM)


Since I regard all modules except FC and SIM as important models (or at least
modules), I hereby ask you to either

- prove your claim or

- officially take it back

for all these models.

Amon.

--
You have received this message because you are subscribed to the selinux list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: Rule Set Based Access Control (RSBAC)

[Stephen Smalley]

Ok, let's look at them one by one:

1) Privacy Model (PM)

Requirements (from your '98 NISS paper):
a) A user may only have access to personal data if this access is
necessary to perform his current task.

This can be specified in the RBAC/TE configuration by defining 
appropriate types for personal data and defining appropriate
roles/domains for users and tasks.

b) The user may only access data in controlled manner by performing
a certified transformation procedure for which the user's current
task is authorized.

This can be specified in the RBAC/TE configuration by binding
the domains that can access personal data to specific program
types, and only labeling certified transformation procedures
with those types.

c) The purpose of the user's task must correspond to the purpose
for which the personal data was obtained or there must be
consent by the data subjects.

This can be specified in the RBAC/TE configuration by encoding
the purpose in the domains and types and only granting access
when the purpose is consistent.  Consent can be expressed
by relabeling the personal data to a type that is consistent
with the desired purpose.

2) Malware Scan

As you admit in your model descriptions, this model is not really
an access control model.  We address the threat of malicious
software using access control, i.e. controlling the execution of software 
based on its label and automatically transitioning untrustworthy
software into less privileged domains.  This model seems out of place
with the rest of your models, and your web page notes that it is only
a working demonstration model.  Also, I would argue that
virus scanning is very poor in comparison to access control 
techniques for addressing malicious software.

3) Role Compatibility

I'm not sure what your objection is here, since RC seems mostly
isomorphic to Type Enforcement, with the substitution of roles for 
domains, weaker controls over role changes, and special cases
for inheritance.  Perhaps you mean the ability to authorize roles to
administer other roles in RC.  If so, then that is true - we 
haven't implemented such support in our TE implementation.
But I'm not sure about the safety properties of your model.
There has been published work in that area by Jonathan Tidswell and
also by Tim Fraser for allowing dynamic changes to DTE configurations
while ensuring that critical security properties are preserved.

4) Access Control Lists

SELinux provides support for flexible _mandatory_ access controls.
Administratively-defined ACLs can be more efficiently represented
and more easily managed using TE domains and types or RC
roles and types.  If you are talking about discretionary ACLs,
we view that as an orthogonal feature.

5) Mandatory Access Controls

You can express traditional MAC using an access matrix, so you
can represent it using TE, with domains defined to represent
clearances and types defined to represent classifications.  
We also provide a separate MLS policy module that is a "native"
implementation of traditional MAC.

6) File Flags

These flags can be represented in TE simply by defining types,
assigning those types to the desired files, and limiting permissions to 
those types appropriately.  Or, in RSBAC, you could achieve
the same effect using RC.

7) Auth

This module is just a support module for your other modules.  
The SELinux policy configuration allows boolean constraints to
be imposed on permissions, and these constraints are used
in the example configuration to limit the ability to change our 
user identity attribute to authorized domains.  The constraints
can be used with greater precision if desired, e.g. specifying
that a particular domain can only change identity to a specific
set of user identities.

8) Functional Control

You agreed that TE can represent this model.

9) Security Information Modification

You agreed that TE can represent this model.

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






--
You have received this message because you are subscribed to the selinux list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: Rule Set Based Access Control (RSBAC)

[Amon Ott]

On Don, 05 Apr 2001 Stephen Smalley wrote:
> Ok, let's look at them one by one:

Here we come to argumenting. I will give you some more documented restrictions
and some examples for these models.

> 1) Privacy Model (PM)
> 
> Requirements (from your '98 NISS paper):
> a) A user may only have access to personal data if this access is
> necessary to perform his current task.
> 
> This can be specified in the RBAC/TE configuration by defining 
> appropriate types for personal data and defining appropriate
> roles/domains for users and tasks.

The definition and assignment of roles and types must be done by two PM
roles working together, and that within a given time limit. These roles are
first Data Protection Officer and second Security Manager.

The four-eyes principle is an important base concept in the whole model.

> b) The user may only access data in controlled manner by performing
> a certified transformation procedure for which the user's current
> task is authorized.
> 
> This can be specified in the RBAC/TE configuration by binding
> the domains that can access personal data to specific program
> types, and only labeling certified transformation procedures
> with those types.

The TP definition and labelling must also be done by two different roles within
a given time limit. This time the roles are TP Manager and Security Officer.

This further restricts the real access to personal data to a six-eyes process,
and everything within time limits measured in seconds.

> c) The purpose of the user's task must correspond to the purpose
> for which the personal data was obtained or there must be
> consent by the data subjects.
> 
> This can be specified in the RBAC/TE configuration by encoding
> the purpose in the domains and types and only granting access
> when the purpose is consistent.  Consent can be expressed
> by relabeling the personal data to a type that is consistent
> with the desired purpose.

This might be possible. However, we are already far away from the term 'easy'.
And again, definition and assignment of purposes and tasks need two roles
working together within a time limit.

BTW: Every user can only have one of these roles, or general user or system
admin. This additionally enforces the separation.

There are some more aspects, like control of information flow, which we could
add to this discussion...

> 2) Malware Scan
> 
> As you admit in your model descriptions, this model is not really
> an access control model.  We address the threat of malicious
> software using access control, i.e. controlling the execution of software 
> based on its label and automatically transitioning untrustworthy
> software into less privileged domains.  This model seems out of place
> with the rest of your models, and your web page notes that it is only
> a working demonstration model.  Also, I would argue that
> virus scanning is very poor in comparison to access control 
> techniques for addressing malicious software.

You were talking about 'most RSBAC modules'. No doubt access control can be
effectively used to avoid changes to programs or execution of uncontrolled
code. But that was not the question here.

What, if users must for some reasons be allowed to create or modify
executables, e.g. software developers? How will you know, if the modification
on behalf of the user was done by malicious code without consent?

How about e.g. text documents containing macros? Web pages with Java applets?
Perl, Python, bash scripts, where the execution is done by an interpreter, and
all you see is a read-open?

Still, we can from now on restrict our discussion to access control in the
traditional sense, if you want. I agree that MS is not finished, but it mostly
lacks a full set of scan strings. The model itself is complete.

> 3) Role Compatibility
> 
> I'm not sure what your objection is here, since RC seems mostly
> isomorphic to Type Enforcement, with the substitution of roles for 
> domains, weaker controls over role changes, and special cases
> for inheritance.  Perhaps you mean the ability to authorize roles to
> administer other roles in RC.  If so, then that is true - we 
> haven't implemented such support in our TE implementation.
> But I'm not sure about the safety properties of your model.

RC's strong administration settings are sure my main objection. It enables
separate administration areas, which can be e.g. used to effectively create
separate, but possibly overlapping work groups.

One example:
Just think of two workgroups W1 and W2. Each work group has a manager role, M1
and M2, and several member roles, let's call them R1a, R1b and R2a, R2b.

It is easy to setup an environment with RC, where
- both M1 and M2 can create users and add them to one of their workgroup roles
   (optionally, the creation could be delegated to another role to separate
these tasks)
- none of them can assign users her own manager role
- none of them can change their own role
- none of them can access or assign the other one's roles
- none of them can assign her own managed roles to a user, who already has one
of the other one's roles
- no other role can do anything of the above items
- none of them can change access rights of one of their roles.
- this setup can be forever fixed - at least, unless the system is restarted
with inactive RC

> There has been published work in that area by Jonathan Tidswell and
> also by Tim Fraser for allowing dynamic changes to DTE configurations
> while ensuring that critical security properties are preserved.

I will sure some day soon work through some of these papers. You probably know
the problem of limited time as well as I do.

> 4) Access Control Lists
> 
> SELinux provides support for flexible _mandatory_ access controls.
> Administratively-defined ACLs can be more efficiently represented
> and more easily managed using TE domains and types or RC
> roles and types.  If you are talking about discretionary ACLs,
> we view that as an orthogonal feature.

ACLs can, but need not be discretionary. It depends on the Access Control and
Supervisor rights. They make it easy to have independent administrators for
separate filesystem areas - without any access for the other administrators.

The ACl inheritance scheme with masks and the accumulation of rights from user,
several group and role entries are sure difficult to emulate with roles and
types - you would need a real lot of them.

Again, one important focus lies on separation of duties. With ACL model, every
user can maintain her own set of user groups, which can optionally be used by
herself or other users for administration. E.g., one user maintains all user
groups, and another grants rights for these groups. None can work alone.

One example:
In a company (or government agency) you have a secret workgroup for internal
investigation. To avoid social problems for workgroup members, only the
workgroup leader knows who is in the group. The workgroup has its own
filesystem area on the company server.

ACL setup: Workgroup leader L defines a private user group. The workgroup's
security officer (possibly as member of another private group) has access
control to the secret area and defines appropiate rights for this group.

Now L can add or remove users to or from the private group, without anybody
else's knowledge. L cannot grant individual access to objects.

What if L leaves the company? L transfers the private group to her successor,
who is now the only one with access to the member list.

> 5) Mandatory Access Controls
> 
> You can express traditional MAC using an access matrix, so you
> can represent it using TE, with domains defined to represent
> clearances and types defined to represent classifications.  
> We also provide a separate MLS policy module that is a "native"
> implementation of traditional MAC.

How dows TE enforce *-property? How many roles and types would TE need to
represent all permutations of 253 levels and 64 compartments?
  
> 6) File Flags
> 
> These flags can be represented in TE simply by defining types,
> assigning those types to the desired files, and limiting permissions to 
> those types appropriately.  Or, in RSBAC, you could achieve
> the same effect using RC.

There are some special effects, e.g. search_only is only valid for directories,
write_only only for files and fifos. You can certainly define a dir and file
type for each permutation of FF flags and use all these types. The definition
is probably also quite easy, and with proper type names even usable.
Inheritance can be emulated by changing the type labels of all affected objects.

So I admit that you can emulate this model, but again not easily.
     
> 7) Auth
> 
> This module is just a support module for your other modules.  
> The SELinux policy configuration allows boolean constraints to
> be imposed on permissions, and these constraints are used
> in the example configuration to limit the ability to change our 
> user identity attribute to authorized domains.  The constraints
> can be used with greater precision if desired, e.g. specifying
> that a particular domain can only change identity to a specific
> set of user identities.

Do you also have the concept of only certain programs or processes being able
to extend the set of accessible user ids, e.g. to enforce proper authentication
by only a privileged set of programs (AUTH attribute auth_may_set_cap)?
   

Additionally you can, as intended, use ACL model as an extension of RC model
by using role subjects in the ACL entries.

You did not claim to be able to emulate a combination of RSBAC models with TE,
but combinations are part of the RSBAC framework design.

Amon.

--
You have received this message because you are subscribed to the selinux list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: Rule Set Based Access Control (RSBAC)

[Stephen Smalley]

> The definition and assignment of roles and types must be done by two PM
> roles working together, and that within a given time limit. These roles are
> first Data Protection Officer and second Security Manager.
> The TP definition and labelling must also be done by two different roles within
> a given time limit. This time the roles are TP Manager and Security Officer.
> This might be possible. However, we are already far away from the term 'easy'.
> And again, definition and assignment of purposes and tasks need two roles
> working together within a time limit.

RBAC/TE can model n-person control through pipelines.  As far
as time limits go, that does not appear to be a fundamental requirement
for the model, just an implementation detail due to your ticket-based
approach.  If you really want a time-based policy, then I would
agree that TE itself is not sufficient to represent it, although
you could easily add such policy logic to the example security server.
I also question the practicality of enforcing this PM policy in
the operating system itself, as opposed to requiring some application
enforcement mechanisms.  In real-world environments, are the personal
data and tasks really implemented just with the operating system
abstractions and services, or are they implemented as application
abstractions and services (e.g. a distributed database system)?

> What, if users must for some reasons be allowed to create or modify
> executables, e.g. software developers? How will you know, if the modification
> on behalf of the user was done by malicious code without consent?

You can protect different classes of users from each other by
not allowing them to execute each other's programs, while still
allowing them to create and execute their own programs.  You
can ensure that any programs downloaded via their web browser
are automatically placed into restricted domains that cannot
modify the user's files except for a restricted set.  You could
define a pipeline for the creation of executable programs that
requires that an application virus scanner approve the program
before any execution, and prohibit subsequent modification
without rescanning.  I'm not fundamentally opposed to virus
scanners, and you can use OS access control to protect application virus
scanners against bypass or tampering, but I'm not sure about embedding
them in the OS itself.

>RC's strong administration settings are sure my main objection. It 
>enables separate administration areas, which can be e.g. used to
>effectively create separate, but possibly overlapping work groups.

The "overlapping" is the area of concern.  What prevents the
administrator of one work group from subverting the intended protections
of another work group by granting his roles permissions to types
that are also accessible/used by the other work group?

> How does TE enforce *-property? How many roles and types would TE need
to
> represent all permutations of 253 levels and 64 compartments?

You can represent both properties simply by defining an access matrix
of clearances and classifications, and defining the permissions for
each pairing so that there are no read-ups or write-downs.  I agree
that it would be cumbersome to represent a large lattice in TE,
which is why we provide a separate MLS policy module.  But some
people would probably be fine with a very small number of levels
and compartments.

> Do you also have the concept of only certain programs or processes being able
> to extend the set of accessible user ids, e.g. to enforce proper authentication
> by only a privileged set of programs (AUTH attribute auth_may_set_cap)?

We can restrict the ability to set the user identity attribute to 
specific programs/processes, and we can specify what user identity
attributes are reachable by a particular program/process.

> You did not claim to be able to emulate a combination of RSBAC models with TE,
> but combinations are part of the RSBAC framework design.

You can provide combinations through the TE configuration, either
by defining separate sets of domains and types to address each
individual model (if they are being applied to separate subjects
and data sets) or by defining a set of complex domains and types
that combine attributes appropriately.  But you can also 
add other policy modules to the example security server, like
the MLS policy module, if desired.  However, this is an area
where RSBAC has an advantage - our example security server does
not provide a framework for easily composing modules like the
RSBAC ADF.  Of course, such a framework could be implemented
in our security server without changing anything else in the
system, since the policy and labels are cleanly encapsulated.

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






--
You have received this message because you are subscribed to the selinux list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: Rule Set Based Access Control (RSBAC)

[Amon Ott]

On Fre, 06 Apr 2001 Stephen Smalley wrote:
> enforcement mechanisms.  In real-world environments, are the personal
> data and tasks really implemented just with the operating system
> abstractions and services, or are they implemented as application
> abstractions and services (e.g. a distributed database system)?

They are modelled with OS abstractions. Simone is the right person to go deeper
into model details.

> >RC's strong administration settings are sure my main objection. It 
> >enables separate administration areas, which can be e.g. used to
> >effectively create separate, but possibly overlapping work groups.
> 
> The "overlapping" is the area of concern.  What prevents the
> administrator of one work group from subverting the intended protections
> of another work group by granting his roles permissions to types
> that are also accessible/used by the other work group?

You can only grant permissions to types that your own role is allowed to access
control. Overlapped types would have to be access controlled by some mediator.
Anyway, in my workgroup example I did not say that the workgroup leaders were
allowed to do any access control settings. They could only assign their
necessary roles to those users, who already have one of these roles.

I was mostly thinking of common roles that could be assigned by both - but
only, if the previous role could also be assigned. You can e.g. use such common
roles to transfer a user account from one workgroup to another, or to establish
a mediator between both groups. The default user role 0 must be in each leaders
role assign set to assign roles to new users.

> > How does TE enforce *-property? How many roles and types would TE need
> to
> > represent all permutations of 253 levels and 64 compartments?
> 
> You can represent both properties simply by defining an access matrix
> of clearances and classifications, and defining the permissions for
> each pairing so that there are no read-ups or write-downs.  I agree
> that it would be cumbersome to represent a large lattice in TE,
> which is why we provide a separate MLS policy module.  But some
> people would probably be fine with a very small number of levels
> and compartments.

Your separate MLS module suits as an answer for me that it is not easily done.
 
> > Do you also have the concept of only certain programs or processes being able
> > to extend the set of accessible user ids, e.g. to enforce proper authentication
> > by only a privileged set of programs (AUTH attribute auth_may_set_cap)?
> 
> We can restrict the ability to set the user identity attribute to 
> specific programs/processes, and we can specify what user identity
> attributes are reachable by a particular program/process.

My description was unclear. With AUTH model, certain privileged processes can
grant setuid capabilities to *other* processes. So if you have an authentication
daemon, this daemon grants the requesting process the capability to setuid to
the authenticated account - nothing more. If authentication fails, setuid will
fail, too.

Amon.

--
You have received this message because you are subscribed to the selinux list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: Rule Set Based Access Control (RSBAC)

[Simone Fischer-Hübner]

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übner 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 
> 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 
well. However, for a secure system implementation, the PM security policy 
should also be enforced/supported at a lower system level and the 
application should rely on the operating system to enforce the PM policy. 
We decided that it is helpful to have a complete model implementation in 
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´98 paper: in a hospital, medical data accessible for medical 
> 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 
> 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, 
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 
currently write-access to. A simple example: the process is allowed to 
write to non-personal data (for which most of the security properties do 
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, 
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 
> 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 
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 
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 
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 
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




--
You have received this message because you are subscribed to the selinux list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: Rule Set Based Access Control (RSBAC)

[Stephen Smalley]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: TEXT/PLAIN; charset=US-ASCII, Size: 5501 bytes --]


On Fri, 6 Apr 2001, Simone [iso-8859-1] Fischer-Hübner 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 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.  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´98 paper: in a hospital, medical data accessible for medical 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 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.

> Besides, in order to implement operational separation of duties and to 
> prevent misuse, all security attributes can only be defined and set by two 
> authorized person in cooperation. One is the user in the role data 
> protection officer (appointed according to German/European privacy 
> legislation), who creates a ticket to define the security attribute 
> value/allocation, and one is the user in the role security-officer, who can 
> then use the ticket to set the respective attribute.
> Besides, there is another condition that only users in the role TP-manager 
> can define transformation procedures (TPs), but only the security officer 
> in cooperation with the data protection officer is allowed to authorize 
> 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), expressing 
> with what task by performing what TP you can access what object class in 
> 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 
> 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 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.

> 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.


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





--
You have received this message because you are subscribed to the selinux list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: Rule Set Based Access Control (RSBAC)

[Simone Fischer-Hübner]

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übner 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 
> 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 
well. However, for a secure system implementation, the PM security policy 
should also be enforced/supported at a lower system level and the 
application should rely on the operating system to enforce the PM policy. 
We decided that it is helpful to have a complete model implementation in 
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´98 paper: in a hospital, medical data accessible for medical 
> 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 
> 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, 
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 
currently write-access to. A simple example: the process is allowed to 
write to non-personal data (for which most of the security properties do 
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, 
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 
> 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 
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 
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 
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 
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




--
You have received this message because you are subscribed to the selinux list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: Rule Set Based Access Control (RSBAC)

[Amon Ott]

On Mit, 04 Apr 2001 Paul D. Robertson wrote:
> On Wed, 4 Apr 2001, Amon Ott wrote:
> > Something special in my point of view is that I distrust all user mode
> > programs, because they come from unknown sources and might have been modified,
> > e.g. trojanized or infected by viruses. In some cases I have to rely on them,
> > e.g. for the (insuffient) Linux style user authentication.
> 
> I'm curious about this- in a best-case scenerio, how do you see user auth?  At
> some point, especially for network aware applications, some user mode
> authenticating piece has to be (probably grudgingly) moved into the TCB.
> For instance with the Dockmaster II stuff, the modified httpd has to be
> part of the TCB because it must be able to allow per-user access.  Is a
> known-goodware scan better than a malware scan for such applications?    

Only the part doing the authentication must be part of the TCB. Take RSBAC
AUTH model as an example, which has been designed to solve this problem:

- User mode process, e.g. running httpd, wants to setuid to access some object
with different rights. It gathers authentication data and calls an independent
auth facility (IPC to a daemon or syscall).
- Authentication facility checks the data and either returns error or adds an
AUTH capability for the requesting process to setuid to the desired uid. This
cap is only valid for this single process.
- Process calls setuid and works on behalf of another user
- If process wants to setuid to another uid (or the original one), the procedure
restarts

In this szenario, the httpd can be mostly untrusted, apart from gathering auth
data - this is difficult to avoid because of the http protocol. Sure the auth
data could be valid for this purpose only, what could be solved on a per-program
basis.

> > Real account management should be in the kernel, with strong data protection,
> > strong on-disk encryption and setuid limitation by this account management to
> > those ids which have been authenticated by the process asking.
> 
> The process asking still has the malware problem though doesn't it?  (Has
> anyone applied RSBAC to an International kernel to get disk encryption?)

I know that several people are planning to combine both in their server
systems. I have not yet tried myself, but in principle it should work.
  
> > > The example configuration provided with SELinux defines 70 domains,
> > > 188 file types, and 38 other types (e.g. network-related types).
> 
> How do the SELinux people expect auditing to take place in such an
> example?  Users switching jobs and system upgrades seem to be difficult to
> audit effectively with that many default permutations, or am I missing
> something?

That's part of what I meant with 'Who keeps the overview'. Just think of adding
a user account and looking the desired role up in a book.
  
> > > I probably wasn't clear.  With SELinux, you edit the human-readable policy
> > > configuration files to set up your policy (starting with the example
> > > configuration we provide if you want), then compile that policy
> > > into a binary representation and install it.  You can then load
> > > the updated policy into your running kernel (if the policy authorizes
> > > such runtime changes) using a new system call, or you can reboot
> > > (in which case the kernel will load the new policy when it
> > > initializes).  My concern was with the need to run a special
> > > set of utilities that use a special set of system calls to
> > > customize the configuration, as opposed to being able to edit
> > > human-readable configuration files.

> [cut]
 
> I'm also still intensely interested in "two man missile key" stuff.  How
> does SELinux handle a model where either multiple adminitstrators should
> be necessary to grant access to something, or granting a subset of grant
> privs. to a subject is possible to stop the subject from granting all
> grant privs. to another subject or itself (which makes it easy to get to
> the first part by requiring both privs. to do something)?  Is it possible to 

These problems have been solved in Simone Fischer-Hübner's Privacy Model
design (RSBAC PM module), where you must be Security Officer *and* need a
'ticket' issued by a Data Protection Officer (or TP Manager in other cases) to
do some administrative task.

Also, RC model separation of admin duty can split admin tasks up into several
roles, which have to work together. E.g., role A sets up role C's rights to
those target types, that role A is allowed to access control, and role B
assigns role C to users.

Of course, all denied changes are logged to syslog and RSBAC internal log.

> set up a system where an administrator doesn't have access to certain
> targets, and whilst they could grant permissions to other targets on the
> same sytem, and even grant access to grant access to other targets, were
> still blocked from seeing the data they're not supposed to have access to
> (obviously along with their grantees)?  [IOW: is granting rights to grant
> rights restrictable in a way other than a binary yes/no fashion?]

RC separation of admin duty does part of this. ACL module administration does
most, but there is currently no way to disallow granting yourself any
additional rights, if you are allowed to grant rights to others.

As often in RSBAC, a combination of RC and ACL does the full trick (full
explanation on request - this is a bit complicated).

Amon.

--
You have received this message because you are subscribed to the selinux list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: Rule Set Based Access Control (RSBAC)

[Stephen Smalley]

> If policy changes aren't rare, both administrative overhead and the
> oppertunity an administrator has to do bad things (maliciously or
> accidently) are higher.   

Most policies require some degree of dynamic behavior, e.g. as
user authorizations change, and some policies must revoke
permissions dynamically based on the history of operations 
performed or in response to some event.  So the idea is to provide the
necessary infrastructure to support policy changes at runtime rather than
requiring that the system be restarted in order to ensure that accesses
are revoked properly.

> > > The example configuration provided with SELinux defines 70 domains,
> > > 188 file types, and 38 other types (e.g. network-related types).
> 
> How do the SELinux people expect auditing to take place in such an
> example?  Users switching jobs and system upgrades seem to be difficult to
> audit effectively with that many default permutations, or am I missing
> something?

As I mentioned in my reply to Amon, most of the domains deal with
system processes and programs that require special access rights.
For users, related domains are grouped into roles, and only a small
number of distinct roles are defined.  If a system upgrade involves
adding new system processes, privileged programs, or sensitive files,
then you would naturally want to update your configuration to address
those entities.  Also, note that this is simply an example policy
configuration.  Administrators are free to find their preferred
balancing point between fine-grained protection (with the cost
of complexity) and ease of management (with the cost of quality
of protection).  But my preference would be to encourage the
development of tools to ease the management without sacrificing
the granularity of protection.

> I assume that the policy compiler is the equivalent of a special set of
> utilities, is that a correct assumption?  Syscall auditing is pretty cut
> and dried, how do you audit policy changes in SELinux between binary
> representations?  How do you deal with an administrator compiling three
> different policies then trying to figure out which one to install a week
> later? 

I'm not sure what you mean by auditing in this context.  
The policy compiler can also be used to load a binary representation
and issue queries against it.  You can use it to test and debug
the policy before installing it (and also to test and debug a
copy of the security server in user space).  I suppose we could
have it "disassemble" a binary representation back into the
human-readable form, or do automatic comparisons with human-readable
forms.

> I'm also still intensely interested in "two man missile key" stuff.  How
> does SELinux handle a model where either multiple adminitstrators should
> be necessary to grant access to something, or granting a subset of grant
> privs. to a subject is possible to stop the subject from granting all
> grant privs. to another subject or itself (which makes it easy to get to
> the first part by requiring both privs. to do something)?  Is it possible to 
> set up a system where an administrator doesn't have access to certain
> targets, and whilst they could grant permissions to other targets on the
> same sytem, and even grant access to grant access to other targets, were
> still blocked from seeing the data they're not supposed to have access to
> (obviously along with their grantees)?  [IOW: is granting rights to grant
> rights restrictable in a way other than a binary yes/no fashion?]

You could model n-person control by defining a n-stage pipeline,
something that TE is naturally suited for.  But I'm curious about
the real intended use for your policy.  Do you really want n-person
control over some operating system service (e.g. a file access), or do
you really need n-person control over some application service?  If
you need it for some application service, then you are likely to need
enforcement support in the application itself, using the OS mechanisms
to protect the application from tampering or bypass and to confine the
damage that might occur if the application mechanism fails.

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





--
You have received this message because you are subscribed to the selinux list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Rule Set Based Access Control (RSBAC)

[Manoj Srivastava]

Hi,

        I am beginning to evaluate SELinux for my company, and I ran
 across RSBAC (http://www.rsbac.de/index.htm) while still in the
 background research phase. Has anyone done a comparison of RSBAC? It
 sounds like it is in the same ballpark as SELinux, and seems to have
 some additional goodies like ACL's. 


	manoj

ps. From the web page above:
     ---------------------------------------------------------------------- 
What is RSBAC?                       

   RSBAC is a flexible, powerful and fast open source access control
   framework for current Linux kernels, which has been in stable
   production use for over a year (since version 1.0.9a).

   The standard package includes a range of access control models like
   MAC, RC, ACL (see below). Furthermore, the runtime registration
   facility (REG) makes it easy to implement your own access control
   model as a kernel module and get it registered at runtime.

   The RSBAC framework is based on the Generalized Framework for
   Access Control (GFAC) by Abrams and LaPadula. All security relevant
   system calls are extended by security enforcement code. This code
   calls the central decision component, which in turn calls all
   active decision modules and generates a combined decision. This
   decision is then enforced by the system call extensions.

   Decisions are based on the type of access (request type), the
   access target and on the values of attributes attached to the
   subject calling and to the target to be accessed. Additional
   independent attributes can be used by individual modules, e.g. the
   privacy module (PM). All attributes are stored in fully protected
   directories, one on each mounted device.  Thus changes to
   attributes require special system calls provided.
             
   As all types of access decisions are based on general decision
   requests, many different security policies can be implemented as a
   decision module.  Apart from the builtin models shown below, the
   optional Module Registration (REG) allows for registration of
   additional, individual decision modules at runtime.
----------------------------------------------------------------------

      
-- 
 In Corning, Iowa, it's a misdemeanor for a man to ask his wife to
 ride in any motor vehicle.
Manoj Srivastava   <manoj.srivastava@stdc.com>    <srivasta@acm.org> 
1024R/C7261095 print CB D9 F4 12 68 07 E4 05  CC 2D 27 12 1D F5 E8 6E
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C

--
You have received this message because you are subscribed to the selinux list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: Rule Set Based Access Control (RSBAC)

[K Mitchell Russell]

On 1 Apr 2001, Manoj Srivastava wrote:

> Hi,
> 
>         I am beginning to evaluate SELinux for my company, and I ran
>  across RSBAC (http://www.rsbac.de/index.htm) while still in the
>  background research phase. Has anyone done a comparison of RSBAC? It
>  sounds like it is in the same ballpark as SELinux, and seems to have
>  some additional goodies like ACL's. 
> 

I have recently begun testing the RSBAC patches.  It seems very
flexible, and it is kept up to date (e.g. Amon Ott released v1.1.1 for
the kernel 2.4.3 yesterday).  I couldn't begin to compare RSBAC to
SELINUX because of my newbie level of knowledge about the details of how
they work.  I have asked this very same question in the RSBAC mailing
list several weeks back however, and haven't seen any response yet.  I
have no opinion about which is better, either way you go I don't think
you can lose.  I am just happy to see people interested in securing the
Linux kernel - this is good for everyone.

K. Mitchell Russell, M.D.
kmrussel@hsc.vcu.edu
www.meditac.com


--
You have received this message because you are subscribed to the selinux list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.