request for review of, and collaboration on SELinux models wiki entry

request for review of, and collaboration on SELinux models wiki entry

[Dominick Grift]

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

Recently
http://www.nsa.gov/research/_files/selinux/papers/policy2/x86.shtml came
to my attention and i noticed that this article does not reflect the
current available SELinux models. Also the descriptions seem a bit
technical to me.

Today i decided to make a new introduction to SELinux models with MCS,
MLS and UBAC included for the selinuxproject Wiki. The attempt was to
keep it as easy to read for humans as possible.

I am sure that my entry has mistakes and could use improvements,
therefore i ask you to review the entry and submit any improvements.

You can also send suggestions directly to me.

http://selinuxproject.org/page/SELinux_models

Once we feel comfortable with the content we can add a link on the User
Resource front page.

Thanks in advance.

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: request for review of, and collaboration on SELinux models wiki entry

[Stephen Smalley]

On Thu, 2009-07-02 at 15:40 +0200, Dominick Grift wrote:
> Recently
> http://www.nsa.gov/research/_files/selinux/papers/policy2/x86.shtml came
> to my attention and i noticed that this article does not reflect the
> current available SELinux models. Also the descriptions seem a bit
> technical to me.
> 
> Today i decided to make a new introduction to SELinux models with MCS,
> MLS and UBAC included for the selinuxproject Wiki. The attempt was to
> keep it as easy to read for humans as possible.
> 
> I am sure that my entry has mistakes and could use improvements,
> therefore i ask you to review the entry and submit any improvements.
> 
> You can also send suggestions directly to me.
> 
> http://selinuxproject.org/page/SELinux_models
> 
> Once we feel comfortable with the content we can add a link on the User
> Resource front page.

Feel free to take text from the existing report and update it as
appropriate.

-- 
Stephen Smalley
National Security Agency


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

Re: request for review of, and collaboration on SELinux models wiki entry

[Stephen Smalley]

On Thu, 2009-07-02 at 15:40 +0200, Dominick Grift wrote:
> Recently
> http://www.nsa.gov/research/_files/selinux/papers/policy2/x86.shtml came
> to my attention and i noticed that this article does not reflect the
> current available SELinux models. Also the descriptions seem a bit
> technical to me.
> 
> Today i decided to make a new introduction to SELinux models with MCS,
> MLS and UBAC included for the selinuxproject Wiki. The attempt was to
> keep it as easy to read for humans as possible.
> 
> I am sure that my entry has mistakes and could use improvements,
> therefore i ask you to review the entry and submit any improvements.
> 
> You can also send suggestions directly to me.
> 
> http://selinuxproject.org/page/SELinux_models
> 
> Once we feel comfortable with the content we can add a link on the User
> Resource front page.

- Security contexts are assigned to more than just processes and files.

- MLS/MCS has a single attribute, the MLS/MCS range, which has the
syntax:
lowsensitivity[:lowcategory,...][-highsensitivity[:highcategory,...]]

This is a pair of levels (which in the degenerate case where low==high
is displayed as a single level for conciseness) where each level
consists of a sensitivity value and a category set.

- The motivation of UBAC (which started as rbacsep) was to eliminate the
need for per-role derived domains for programs and derived types for
files.  It isn't really its own distinct model per se, just a particular
configuration of constraints based on SELinux user identity.

- MCS and MLS are just particular configurations of constraints for the
MLS engine and thus share the same field and engine logic.  MCS was an
attempt to make the MLS field and engine useful for general users, and
is being leveraged by sandbox and by svirt for separating multiple
instances of sandboxes or guest VMs.

-- 
Stephen Smalley
National Security Agency


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

Re: request for review of, and collaboration on SELinux models wiki entry

[Dominick Grift]

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

On Thu, 2009-07-02 at 10:29 -0400, Stephen Smalley wrote:
> On Thu, 2009-07-02 at 15:40 +0200, Dominick Grift wrote:
> > Recently
> > http://www.nsa.gov/research/_files/selinux/papers/policy2/x86.shtml came
> > to my attention and i noticed that this article does not reflect the
> > current available SELinux models. Also the descriptions seem a bit
> > technical to me.
> > 
> > Today i decided to make a new introduction to SELinux models with MCS,
> > MLS and UBAC included for the selinuxproject Wiki. The attempt was to
> > keep it as easy to read for humans as possible.
> > 
> > I am sure that my entry has mistakes and could use improvements,
> > therefore i ask you to review the entry and submit any improvements.
> > 
> > You can also send suggestions directly to me.
> > 
> > http://selinuxproject.org/page/SELinux_models
> > 
> > Once we feel comfortable with the content we can add a link on the User
> > Resource front page.
> 
> - Security contexts are assigned to more than just processes and files.

You and i know that but for a common user i think just separation of
files and processes should suffice.

When all is said and done a Linux system is just a bunch of files

I will edit it to read processes and objects although personally i think
objects sound a bit technical.

> - MLS/MCS has a single attribute, the MLS/MCS range, which has the
> syntax:
> lowsensitivity[:lowcategory,...][-highsensitivity[:highcategory,...]]
> 
> This is a pair of levels (which in the degenerate case where low==high
> is displayed as a single level for conciseness) where each level
> consists of a sensitivity value and a category set.

I will edit it to reflect this. I must say that reading a security
context and its fields suggests otherwise: user:role:type:level:category

if each field is a seperate attribute then the context suggests
categories are a separate attribute.

> - The motivation of UBAC (which started as rbacsep) was to eliminate the
> need for per-role derived domains for programs and derived types for
> files.  It isn't really its own distinct model per se, just a particular
> configuration of constraints based on SELinux user identity.

Maybe a it is a concept, like SELinux user identities? maybe i should
explain the difference between models and concepts although i feel that
would make things more complicated than needed.

I noted that it is not a distinct model i think by suggesting that it is
an extension to SELinux User identities.

> - MCS and MLS are just particular configurations of constraints for the
> MLS engine and thus share the same field and engine logic.  MCS was an
> attempt to make the MLS field and engine useful for general users, and
> is being leveraged by sandbox and by svirt for separating multiple
> instances of sandboxes or guest VMs.

I think i touched on that by saying: Multi Category Security is a
implementation of Multi Level Security where the use of assigned
Security Categories is to the discretion of the user.

I will think about ways to clear this up.

Thanks for your suggestions. I will apply the corrections soon.

Also feel free to edit the page.

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: request for review of, and collaboration on SELinux models wiki entry

[Stephen Smalley]

On Thu, 2009-07-02 at 16:54 +0200, Dominick Grift wrote:
> On Thu, 2009-07-02 at 10:29 -0400, Stephen Smalley wrote:
> > On Thu, 2009-07-02 at 15:40 +0200, Dominick Grift wrote:
> > > Recently
> > > http://www.nsa.gov/research/_files/selinux/papers/policy2/x86.shtml came
> > > to my attention and i noticed that this article does not reflect the
> > > current available SELinux models. Also the descriptions seem a bit
> > > technical to me.
> > > 
> > > Today i decided to make a new introduction to SELinux models with MCS,
> > > MLS and UBAC included for the selinuxproject Wiki. The attempt was to
> > > keep it as easy to read for humans as possible.
> > > 
> > > I am sure that my entry has mistakes and could use improvements,
> > > therefore i ask you to review the entry and submit any improvements.
> > > 
> > > You can also send suggestions directly to me.
> > > 
> > > http://selinuxproject.org/page/SELinux_models
> > > 
> > > Once we feel comfortable with the content we can add a link on the User
> > > Resource front page.
> > 
> > - Security contexts are assigned to more than just processes and files.
> 
> You and i know that but for a common user i think just separation of
> files and processes should suffice.
> 
> When all is said and done a Linux system is just a bunch of files

+sockets 
+packets
+sysvipc
+userspace_objects (XSELinux, D-BUS, SEPostgreSQL)

> I will edit it to read processes and objects although personally i think
> objects sound a bit technical.
> 
> > - MLS/MCS has a single attribute, the MLS/MCS range, which has the
> > syntax:
> > lowsensitivity[:lowcategory,...][-highsensitivity[:highcategory,...]]
> > 
> > This is a pair of levels (which in the degenerate case where low==high
> > is displayed as a single level for conciseness) where each level
> > consists of a sensitivity value and a category set.
> 
> I will edit it to reflect this. I must say that reading a security
> context and its fields suggests otherwise: user:role:type:level:category
> 
> if each field is a seperate attribute then the context suggests
> categories are a separate attribute.

Yep, my fault.  Poor choice of syntax, somewhat historical (there was
originally only one level).

> > - The motivation of UBAC (which started as rbacsep) was to eliminate the
> > need for per-role derived domains for programs and derived types for
> > files.  It isn't really its own distinct model per se, just a particular
> > configuration of constraints based on SELinux user identity.
> 
> Maybe a it is a concept, like SELinux user identities? maybe i should
> explain the difference between models and concepts although i feel that
> would make things more complicated than needed.
> 
> I noted that it is not a distinct model i think by suggesting that it is
> an extension to SELinux User identities.
> 
> > - MCS and MLS are just particular configurations of constraints for the
> > MLS engine and thus share the same field and engine logic.  MCS was an
> > attempt to make the MLS field and engine useful for general users, and
> > is being leveraged by sandbox and by svirt for separating multiple
> > instances of sandboxes or guest VMs.
> 
> I think i touched on that by saying: Multi Category Security is a
> implementation of Multi Level Security where the use of assigned
> Security Categories is to the discretion of the user.
> 
> I will think about ways to clear this up.
> 
> Thanks for your suggestions. I will apply the corrections soon.
> 
> Also feel free to edit the page.

-- 
Stephen Smalley
National Security Agency


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

Re: request for review of, and collaboration on SELinux models wiki entry

[Joshua Kramer]

>> - Security contexts are assigned to more than just processes and files.
> You and i know that but for a common user i think just separation of
> files and processes should suffice.
> When all is said and done a Linux system is just a bunch of files

Note that I'm putting together a similar tutorial on Userspace Object 
Managers [1].  There are applications - DBus, SE-PGSQL - that use SELinux 
contexts on arbitrary objects in the program itself, for example, database 
columns.  These objects are not necessarily files, but instead they are 
in-memory data structures.

I'm going way out there and modelling the behavior of a dog pack - sled 
dogs actually - using SELinux contexts.  I'll forward to the group for 
review when it's done.

Cheers,
-JK

-----
http://www.globalherald.net/jb01
GlobalHerald.NET, the Smarter Social Network! (tm)

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

Re: request for review of, and collaboration on SELinux models wiki entry

[Dominick Grift]

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

On Thu, 2009-07-02 at 12:26 -0400, Joshua Kramer wrote:
> >> - Security contexts are assigned to more than just processes and files.
> > You and i know that but for a common user i think just separation of
> > files and processes should suffice.
> > When all is said and done a Linux system is just a bunch of files
> 
> Note that I'm putting together a similar tutorial on Userspace Object 
> Managers [1].  There are applications - DBus, SE-PGSQL - that use SELinux 
> contexts on arbitrary objects in the program itself, for example, database 
> columns.  These objects are not necessarily files, but instead they are 
> in-memory data structures.
> 
> I'm going way out there and modelling the behavior of a dog pack - sled 
> dogs actually - using SELinux contexts.  I'll forward to the group for 
> review when it's done.
> 
> Cheers,
> -JK

Understood. i will change it to read "objects". my reasoning behind the
use of the word files instead was so that it would easier for common
users to understand, Although strictly speaking it is
incomplete/incorrect.

I do not think common users are aware of in-memory data structures and
other low level technical details.

But again, i will edit it to reflect facts instead.

Thanks
> -----
> http://www.globalherald.net/jb01
> GlobalHerald.NET, the Smarter Social Network! (tm)

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: request for review of, and collaboration on SELinux models wiki entry

[Sebastian Pfaff]

hello,

from http://selinuxproject.org/page/SELinux_models (Multi Category  
Security):

[...] Multi Category Security and Multi Level Security are mutually  
exclusive.

> - MCS and MLS are just particular configurations of constraints for  
> the
> MLS engine and thus share the same field and engine logic.  MCS was an
> attempt to make the MLS field and engine useful for general users, and
> is being leveraged by sandbox and by svirt for separating multiple
> instances of sandboxes or guest VMs.

In other words: MCS and MLS are not mutally exclusiv?! Not in SELinux  
and not in gernal? For me, MCS in SELinux is an "extra",  which  you  
can use with MLS (or MLS engine) at the same time. Please correct me,  
if i'm wrong.

Imho, MCS uses "compartments" or categories to realize the need to  
know principle and MLS uses vertical levels to achieve (at least in  
SELinux) confidentiality (BLP model). Imo compartments and levels are  
not mutally exclusive.

--
Sebastian Pfaff


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

Re: request for review of, and collaboration on SELinux models wiki entry

[Dominick Grift]

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

On Thu, 2009-07-02 at 17:25 +0200, Sebastian Pfaff wrote:
> hello,
> 
> from http://selinuxproject.org/page/SELinux_models (Multi Category  
> Security):
> 
> [...] Multi Category Security and Multi Level Security are mutually  
> exclusive.
> 
> > - MCS and MLS are just particular configurations of constraints for  
> > the
> > MLS engine and thus share the same field and engine logic.  MCS was an
> > attempt to make the MLS field and engine useful for general users, and
> > is being leveraged by sandbox and by svirt for separating multiple
> > instances of sandboxes or guest VMs.
> 
> In other words: MCS and MLS are not mutally exclusiv?! Not in SELinux  
> and not in gernal? For me, MCS in SELinux is an "extra",  which  you  
> can use with MLS (or MLS engine) at the same time. Please correct me,  
> if i'm wrong.
> 
> Imho, MCS uses "compartments" or categories to realize the need to  
> know principle and MLS uses vertical levels to achieve (at least in  
> SELinux) confidentiality (BLP model). Imo compartments and levels are  
> not mutally exclusive.

MCS and MLS are SELinux models (MCS and MLS are just particular
configurations of constraints for the MLS engine and thus share the same
field and engine logic.)

The MCS configuration of constraints conflict with the MLS configuration
of constraints.

In MCS the usage of assigned compartments is to the discretion of the
user

In MLS the usage of assigned compartments is mandatory.

As far as i know MCS and MLS are mutually exclusive. 

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

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: request for review of, and collaboration on SELinux models wiki entry

[Stephen Smalley]

On Thu, 2009-07-02 at 17:49 +0200, Dominick Grift wrote:
> On Thu, 2009-07-02 at 17:25 +0200, Sebastian Pfaff wrote:
> > hello,
> > 
> > from http://selinuxproject.org/page/SELinux_models (Multi Category  
> > Security):
> > 
> > [...] Multi Category Security and Multi Level Security are mutually  
> > exclusive.
> > 
> > > - MCS and MLS are just particular configurations of constraints for  
> > > the
> > > MLS engine and thus share the same field and engine logic.  MCS was an
> > > attempt to make the MLS field and engine useful for general users, and
> > > is being leveraged by sandbox and by svirt for separating multiple
> > > instances of sandboxes or guest VMs.
> > 
> > In other words: MCS and MLS are not mutally exclusiv?! Not in SELinux  
> > and not in gernal? For me, MCS in SELinux is an "extra",  which  you  
> > can use with MLS (or MLS engine) at the same time. Please correct me,  
> > if i'm wrong.
> > 
> > Imho, MCS uses "compartments" or categories to realize the need to  
> > know principle and MLS uses vertical levels to achieve (at least in  
> > SELinux) confidentiality (BLP model). Imo compartments and levels are  
> > not mutally exclusive.
> 
> MCS and MLS are SELinux models (MCS and MLS are just particular
> configurations of constraints for the MLS engine and thus share the same
> field and engine logic.)
> 
> The MCS configuration of constraints conflict with the MLS configuration
> of constraints.
> 
> In MCS the usage of assigned compartments is to the discretion of the
> user
> 
> In MLS the usage of assigned compartments is mandatory.
> 
> As far as i know MCS and MLS are mutually exclusive. 

Correct.

-- 
Stephen Smalley
National Security Agency


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

Re: request for review of, and collaboration on SELinux models wiki entry

[Sebastian Pfaff]

> On Thu, 2009-07-02 at 17:49 +0200, Dominick Grift wrote:
>> On Thu, 2009-07-02 at 17:25 +0200, Sebastian Pfaff wrote:
>>> hello,
>>>
>>> from http://selinuxproject.org/page/SELinux_models (Multi Category
>>> Security):
>>>
>>> [...] Multi Category Security and Multi Level Security are mutually
>>> exclusive.
>>>
>>>> - MCS and MLS are just particular configurations of constraints for
>>>> the
>>>> MLS engine and thus share the same field and engine logic.  MCS  
>>>> was an
>>>> attempt to make the MLS field and engine useful for general  
>>>> users, and
>>>> is being leveraged by sandbox and by svirt for separating multiple
>>>> instances of sandboxes or guest VMs.
>>>
>>> In other words: MCS and MLS are not mutally exclusiv?! Not in  
>>> SELinux
>>> and not in gernal? For me, MCS in SELinux is an "extra",  which  you
>>> can use with MLS (or MLS engine) at the same time. Please correct  
>>> me,
>>> if i'm wrong.
>>>
>>> Imho, MCS uses "compartments" or categories to realize the need to
>>> know principle and MLS uses vertical levels to achieve (at least in
>>> SELinux) confidentiality (BLP model). Imo compartments and levels  
>>> are
>>> not mutally exclusive.
>>
>> MCS and MLS are SELinux models (MCS and MLS are just particular
>> configurations of constraints for the MLS engine and thus share the  
>> same
>> field and engine logic.)
>>
>> The MCS configuration of constraints conflict with the MLS  
>> configuration
>> of constraints.
>>
>> In MCS the usage of assigned compartments is to the discretion of the
>> user
>>
>> In MLS the usage of assigned compartments is mandatory.
>>
>> As far as i know MCS and MLS are mutually exclusive.
>
> Correct.
>
> -- 
> Stephen Smalley
> National Security Agency
>


I think this implies that i'm wrong :/

If MLS and MCS are mutally exclusive, why is it possible to use  
categories _and_ levels with MLS policy? Isn't this a conflict?

Is MCS something similar which is generally referred to as  
Multilateral-Security?

Look here (excerpt from book Information Security - Priciples and  
Practice):

http://books.google.com/books?id=Bh45pU0_E_4C&lpg=PP1&dq=Information%20security%20principles&pg=PA185

So far i find the term MCS only or mainly in the context with SELinux,  
so i think it is (maybe) something SELinux specific which does  
neccessarily has something to do with Multilateral-Security.

I would be appreciate, if someone could give me some hints on what is  
wrong with my point of view.

--
Sebastian Pfaff


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

Re: request for review of, and collaboration on SELinux models wiki entry

[Stephen Smalley]

On Thu, 2009-07-02 at 20:12 +0200, Sebastian Pfaff wrote:
> I think this implies that i'm wrong :/
> 
> If MLS and MCS are mutally exclusive, why is it possible to use  
> categories _and_ levels with MLS policy? Isn't this a conflict?
> 
> Is MCS something similar which is generally referred to as  
> Multilateral-Security?
> 
> Look here (excerpt from book Information Security - Priciples and  
> Practice):
> 
> http://books.google.com/books?id=Bh45pU0_E_4C&lpg=PP1&dq=Information%20security%20principles&pg=PA185
> 
> So far i find the term MCS only or mainly in the context with SELinux,  
> so i think it is (maybe) something SELinux specific which does  
> neccessarily has something to do with Multilateral-Security.
> 
> I would be appreciate, if someone could give me some hints on what is  
> wrong with my point of view.

MCS was invented by James Morris,
http://james-morris.livejournal.com/5583.html

It doesn't really correspond to anything in the literature; it just
leverages the MLS label field and policy engine.

MCS and MLS are just different configurations of the MLS policy engine.
The MCS configuration only defines a single sensitivity, while the MLS
configuration defines multiple sensitivities (16 in the Fedora policy).
Both define and use categories (1024 in the Fedora policies).  Under
MCS, the "low level" in the process' range is always s0, and the process
may at its discretion label files with any category from its "high
level" and may access files whose category sets are within the process
"high level".  Under MLS, the "low level" in the process' range
represents its active/current level, any files created by the process
must be labeled at that level, and it may only read-down and write-at
that level unless it has specific type attributes that allow it to
override the usual MLS constraints.  The "high level" under MLS
represents the user's max clearance, with the process able to elevate
its low level up to that max via newrole -l (depending on
configuration).

-- 
Stephen Smalley
National Security Agency


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