All of lore.kernel.org
 help / color / mirror / Atom feed
* RE: Bell & Lapadula Model
       [not found] <Xine.LNX.4.44.0502171518030.7638-100000@thoron.boston.redhat.com>
@ 2005-02-17 22:21 ` Frank Mayer
  2005-02-17 23:25   ` Lorenzo Hernández García-Hierro
  0 siblings, 1 reply; 3+ messages in thread
From: Frank Mayer @ 2005-02-17 22:21 UTC (permalink / raw)
  To: NSA Selinux Mailinglist; +Cc: 'Juan Espino'

> > SELinux enforces a Mandatory Access Control (MAC) Policy based on Bell 
> > and Lapadula Model.  I understand the read control property (no read 
> > up) and the write control (no write down), but in this model there are 
> > another property called tranquility property, I don't know very well 
> > how SELinux enforces this property,
>
> SELinux includes an experimental MLS implementation based on BLP.  This
feature is 
> not currently enabled in Fedora.
>
> Thus, it may be better to discuss the MLS component on the NSA list:
> http://www.nsa.gov/selinux/info/list.cfm?MenuID=41.1.1.9

To be clear, SELinux as most people think about it implements type
enforcement as its MAC, and *not* BLP (i.e., MLS) as you seem to assert. As
James notes the current MLS feature is experimental though there is work to
make it more integral for future release.

With regard to tranquility, it's a property of object/subject labeling,
i.e., that once set security contexts do not change in order to maintain a
consistent security policy throughout all system states. This is an
interesting property for any MAC mechanisms (TE and MLS), and one that is
often by-passed in applications of MAC (because its hard to live within MAC
restrictions, especially the MLS kind). There's a intense debate in the NSA
mail list about security context tranquility for processes, and IMHO, good
TE policies should have greater limitations on all security context changes.

Frank


--
This message was distributed to subscribers of the selinux mailing 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.

^ permalink raw reply	[flat|nested] 3+ messages in thread

* RE: Bell & Lapadula Model
  2005-02-17 22:21 ` Frank Mayer
@ 2005-02-17 23:25   ` Lorenzo Hernández García-Hierro
  0 siblings, 0 replies; 3+ messages in thread
From: Lorenzo Hernández García-Hierro @ 2005-02-17 23:25 UTC (permalink / raw)
  To: Frank Mayer; +Cc: NSA Selinux Mailinglist, 'Juan Espino'

[-- Attachment #1: Type: text/plain, Size: 2149 bytes --]

El jue, 17-02-2005 a las 17:21 -0500, Frank Mayer escribió:
> > > SELinux enforces a Mandatory Access Control (MAC) Policy based on Bell 
> > > and Lapadula Model.  I understand the read control property (no read 
> > > up) and the write control (no write down), but in this model there are 
> > > another property called tranquility property, I don't know very well 
> > > how SELinux enforces this property,
> >
> > SELinux includes an experimental MLS implementation based on BLP.  This
> feature is 
> > not currently enabled in Fedora.
> >
> > Thus, it may be better to discuss the MLS component on the NSA list:
> > http://www.nsa.gov/selinux/info/list.cfm?MenuID=41.1.1.9
> 
> To be clear, SELinux as most people think about it implements type
> enforcement as its MAC, and *not* BLP (i.e., MLS) as you seem to assert. As
> James notes the current MLS feature is experimental though there is work to
> make it more integral for future release.

Concretely, SELinux arguments the Type Enforcement model with the
addition of the standard Role-Based Access Control.

Instead of doing association between user and types, it lets RBAC to
associate users with at least one role and associates at least one type
with each of those roles.

Permission checks and such are handled by TE, RBAC is more an
user-complaining and policy-enhancing "layer".

"Bell-LaPadula MAC model describes access by active entities, called
subjects, to passive entities, called objects. An entity can, depending
on type of access, be in both roles.
From rom the distinction between read and write access four modes of access
can be distinguished: neither read nor write (execute, e), read only
(read, r), write only (append, a) and read-write (write, w). The set of
all access types is named A."
(http://rsbac.org/documentation/models.php#mac)

The access control matrix is slightly different then :)
Your description is accurate for RSBAC, not for SELinux as I explained
above, among Frank's comments.

Cheers,
-- 
Lorenzo Hernández García-Hierro <lorenzo@gnu.org> 
[1024D/6F2B2DEC] & [2048g/9AE91A22][http://tuxedo-es.org]

[-- Attachment #2: Esta parte del mensaje está firmada digitalmente --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

^ permalink raw reply	[flat|nested] 3+ messages in thread

* RE: Bell & Lapadula Model
       [not found] <BAY19-F67BE31277B62F3C14864B846F0@phx.gbl>
@ 2005-02-20 19:11 ` Lorenzo Hernández García-Hierro
  0 siblings, 0 replies; 3+ messages in thread
From: Lorenzo Hernández García-Hierro @ 2005-02-20 19:11 UTC (permalink / raw)
  To: Juan Espino; +Cc: mayerf, selinux

[-- Attachment #1: Type: text/plain, Size: 1827 bytes --]

El sáb, 19-02-2005 a las 17:29 +0000, Juan Espino escribió:
> Wao, Thanks for your explanations.  SELinux supports more applications than 
> RSBAC ¿?

Both frameworks / security suite in SELinux case support an huge amount
of applications because this is independent of the framework/engine
itself, instead, both use policies that can be handled in a fine-grained
manner (most in SELinux case AFAIK).

Sample/default policies such as NSA SELinux policy available for
download from nsa.gov, make the installation easier, but the
administrator is the person in charge of maintaining a concrete policy
for his proper circumstances and case.
They provide the minimal config. to make applications to work as *they
are expected to do*, allowing only the default operations to make the
app. just working, but this differs in personal and concrete
circumstances as I commented above (ie. Fedora C3 & other RH's goodies
policies), so, fine-tuning is needed if the administrator wants to take
advantage of all the power that SELinux can provide.

It's a decision up to you whatever solution to use, just that I don't
want to enter in flames due to personal remarking, but I've used SELinux
more than RSBAC and I think that with a good policy and knowledge
(minimal I mean) on it, you can make even more profit than using RSBAC,
among that SELinux is used under critical environments and developed by
people who can't buy unexpected issues.

Anyways, both are great solutions, so, the decision is up to you.
RSBAC has an huge amount of documentation and well-explained models, and
the people maintaining it are also good guys that do good work.

I hope my comments could help you.
Cheers,
-- 
Lorenzo Hernández García-Hierro <lorenzo@gnu.org> 
[1024D/6F2B2DEC] & [2048g/9AE91A22][http://tuxedo-es.org]

[-- Attachment #2: Esta parte del mensaje está firmada digitalmente --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2005-02-20 19:14 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
     [not found] <BAY19-F67BE31277B62F3C14864B846F0@phx.gbl>
2005-02-20 19:11 ` Bell & Lapadula Model Lorenzo Hernández García-Hierro
     [not found] <Xine.LNX.4.44.0502171518030.7638-100000@thoron.boston.redhat.com>
2005-02-17 22:21 ` Frank Mayer
2005-02-17 23:25   ` Lorenzo Hernández García-Hierro

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.