Not quite MLS.

Not quite MLS.

[rob myers]

I would like to create a login that has access to one category at the
highest sensitivity level, but in another category only has access at a
lower sensitivity level.  For example, on a system where SystemHigh is
s0-s3:c0.c3, one login could be defined as something similar to:
s0-s1:c0.c3, s2:c2.c3, s3:c3, while another login could be defined as
s0-s2:c0.c3, s3:c0.c2 .

Am I correct that MLS policy cannot support this scenario?

Is this possible under any old, current, or developmental SELinux
policy?

Would it be possible to write such a policy with the existing SELinux
user/kernel land?

Thanks for any pointers,

rob.


--
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: Not quite MLS.

[Stephen Smalley]

On Fri, 2009-08-14 at 17:30 -0400, rob myers wrote:
> I would like to create a login that has access to one category at the
> highest sensitivity level, but in another category only has access at a
> lower sensitivity level.  For example, on a system where SystemHigh is
> s0-s3:c0.c3, one login could be defined as something similar to:
> s0-s1:c0.c3, s2:c2.c3, s3:c3, while another login could be defined as
> s0-s2:c0.c3, s3:c0.c2 .
> 
> Am I correct that MLS policy cannot support this scenario?
> 
> Is this possible under any old, current, or developmental SELinux
> policy?
> 
> Would it be possible to write such a policy with the existing SELinux
> user/kernel land?
> 
> Thanks for any pointers,

I'm not clear on what you are trying to achieve, but I think the answer
is that you would have to modify at least the userland and possibly the
kernel logic for what you describe.

At present, the kernel policy configuration specifies a default level
and a (single) range for each SELinux user identity defined in the
policy.  It also defines what categories can be associated with what
sensitivities, so that you could specify that e.g. c3 can only ever be
associated with s3, although the current refpolicy merely automatically
generates a list of all categories for each sensitivity.

The userland configuration specifies a SELinux user and a (single) range
for each Linux user / login.  That range has to be a subset of the one
authorized for the SELinux user.  That lets you specify subranges for
individual Linux users without having to define each of them within the
kernel policy.

-- 
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: Not quite MLS.

[rob myers]

On Mon, 2009-08-17 at 07:40 -0400, Stephen Smalley wrote:
> On Fri, 2009-08-14 at 17:30 -0400, rob myers wrote:
> > I would like to create a login that has access to one category at the
> > highest sensitivity level, but in another category only has access at a
> > lower sensitivity level.  For example, on a system where SystemHigh is
> > s0-s3:c0.c3, one login could be defined as something similar to:
> > s0-s1:c0.c3, s2:c2.c3, s3:c3, while another login could be defined as
> > s0-s2:c0.c3, s3:c0.c2 .
> > 
> > Am I correct that MLS policy cannot support this scenario?
> > 
> > Is this possible under any old, current, or developmental SELinux
> > policy?
> > 
> > Would it be possible to write such a policy with the existing SELinux
> > user/kernel land?
> > 
> > Thanks for any pointers,
> 
> I'm not clear on what you are trying to achieve

Let me try and be more clear, or at least state things in a different
way.

I want to build a system that stores category 0 (c0) data at each
sensitivity level (s0-s3).  The system also stores category 1 (c1),
category 2 (c2), and category 3 (c3) data at each sensitivity level
(s0-s3).  Therefore the data on the system falls into the s0-s3:c0.c3
range.

Next, I want to add users to this system.  UserA has access to all
categories at the s0 and s1 levels.  At the s2 level UserA has access to
categories 2 and 3.  At the s3 level UserA has access to category 3
data.  UserA's access to data could be thought of as this set of
{ s0-s1:c0.c3, s2:c2.c3, s3:c3 } ranges.  As you can see, UserA should
not be able to read category 0 or 1 data at the s2 level even though
UserA can read category 3 data at the s3 range.

Similarly UserB has access to all categories at the s0, s1 and s2
sensitivity levels.  At the s3 level UserB has access to categories 0,
1, and 2.  UserB's access to data could be thought of as this set of
{ s0-s2:c0.c3, s3:c0.c2 } ranges.  As you can see, UserB should not be
able to read category 3 data at the s3 level even though UserB has
access to category 3 data at lower sensitivity levels and has access to
other sensitivity level 3 data.

Perhaps a better way to express this is on a per category per user
basis:

UserA's access matrix:

category, sl0, sl1, sl2, sl3
       0, yes, yes, no , no 
       1, yes, yes, no , no 
       2, yes, yes, yes, no 
       3, yes, yes, yes, yes 

UserB's access matrix:

category, sl0, sl1, sl2, sl3
       0, yes, yes, yes, yes
       1, yes, yes, yes, yes
       2, yes, yes, yes, yes
       3, yes, yes, yes, no 


I believe the difference between SELinux with MLS policy and what I am
trying to build is that I want higher sensitivity levels to dominate
lower sensitivity levels only on a per category basis.

For example, it is my understanding that under MLS UserB must have
sensitivity level 3 access to category 3 because UserB has access to
sensitivity level 3 access to other categories.  Another possibility
under MLS would be to remove UserB's access to category 3 for all
sensitivities.  Neither of these is what I want the system to do.

Is that more clear about what my goals are?

> At present, the kernel policy configuration specifies a default level
> and a (single) range for each SELinux user identity defined in the
> policy.  It also defines what categories can be associated with what
> sensitivities, so that you could specify that e.g. c3 can only ever be
> associated with s3, although the current refpolicy merely automatically
> generates a list of all categories for each sensitivity.

Ok, thanks for pointing that out.

> The userland configuration specifies a SELinux user and a (single) range
> for each Linux user / login.  That range has to be a subset of the one
> authorized for the SELinux user.  That lets you specify subranges for
> individual Linux users without having to define each of them within the
> kernel policy.

Perhaps what I'm describing is multiple ranges for each user / login.
Could that be achieved with user space modifications only?

Thanks for reading this far,

rob.


--
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: Not quite MLS.

[Glenn Faden]

rob myers wrote:
>
> I believe the difference between SELinux with MLS policy and what I am
> trying to build is that I want higher sensitivity levels to dominate
> lower sensitivity levels only on a per category basis.
>
> For example, it is my understanding that under MLS UserB must have
> sensitivity level 3 access to category 3 because UserB has access to
> sensitivity level 3 access to other categories.  Another possibility
> under MLS would be to remove UserB's access to category 3 for all
> sensitivities.  Neither of these is what I want the system to do.
>   
For MLS systems based on the Mitre/DIA label encodings format it is 
possible to exclude specific categories on a per sensitivity label basis 
from the User Accreditation Range. For an example, see:

    http://docs.sun.com/app/docs/doc/819-0874/sec6-2?a=view

In your example, you could define specify the valid categories for each 
of the four classifications (levels).

    UserA's access matrix:

    category, sl0, sl1, sl2, sl3
           0, yes, yes, no , no 
           1, yes, yes, no , no 
           2, yes, yes, yes, no 
           3, yes, yes, yes, yes 


    UserB's access matrix:

    category, sl0, sl1, sl2, sl3
           0, yes, yes, yes, yes
           1, yes, yes, yes, yes
           2, yes, yes, yes, yes
           3, yes, yes, yes, no 


you could specify

    classification= s10; all compartment combinations valid;
    classification= s11; all compartment combinations valid;
    classification= s12; all compartment combinations valid except:
    c0
    c1
    classification= s13; only valid compartment combinations:
    c3


So it is possible to specify a User Accreditation Range conforming to 
either the UserA or UserB matrix. However, the format only provides for 
a single User Accreditiation Range that would apply to all users. In MLS 
systems I'm familiar with, there is no facility to exclude categories 
from the kernel dominance checks.

--Glenn

--
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: Not quite MLS.

[rob myers]

On Mon, 2009-08-17 at 20:40 -0400, Glenn Faden wrote:
> rob myers wrote:
> >
> > I believe the difference between SELinux with MLS policy and what I am
> > trying to build is that I want higher sensitivity levels to dominate
> > lower sensitivity levels only on a per category basis.
> >
> > For example, it is my understanding that under MLS UserB must have
> > sensitivity level 3 access to category 3 because UserB has access to
> > sensitivity level 3 access to other categories.  Another possibility
> > under MLS would be to remove UserB's access to category 3 for all
> > sensitivities.  Neither of these is what I want the system to do.
> >   
> For MLS systems based on the Mitre/DIA label encodings format it is 
> possible to exclude specific categories on a per sensitivity label basis 
> from the User Accreditation Range. For an example, see:
> 
>     http://docs.sun.com/app/docs/doc/819-0874/sec6-2?a=view
> 
> In your example, you could define specify the valid categories for each 
> of the four classifications (levels).
> 
>     UserA's access matrix:
> 
>     category, sl0, sl1, sl2, sl3
>            0, yes, yes, no , no 
>            1, yes, yes, no , no 
>            2, yes, yes, yes, no 
>            3, yes, yes, yes, yes 
> 
> 
>     UserB's access matrix:
> 
>     category, sl0, sl1, sl2, sl3
>            0, yes, yes, yes, yes
>            1, yes, yes, yes, yes
>            2, yes, yes, yes, yes
>            3, yes, yes, yes, no 
> 
> 
> you could specify
> 
>     classification= s10; all compartment combinations valid;
>     classification= s11; all compartment combinations valid;
>     classification= s12; all compartment combinations valid except:
>     c0
>     c1
>     classification= s13; only valid compartment combinations:
>     c3
> 
> 
> So it is possible to specify a User Accreditation Range conforming to 
> either the UserA or UserB matrix. However, the format only provides for 
> a single User Accreditiation Range that would apply to all users. In MLS 
> systems I'm familiar with, there is no facility to exclude categories 
> from the kernel dominance checks.

Thank you for the useful information.  Unfortunately, specifying
different accreditation ranges for different users is exactly what I'm
trying to achieve.

Thanks,

rob.


--
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: Not quite MLS.

[Stephen Smalley]

On Mon, 2009-08-17 at 17:38 -0400, rob myers wrote:
> On Mon, 2009-08-17 at 07:40 -0400, Stephen Smalley wrote:
> > On Fri, 2009-08-14 at 17:30 -0400, rob myers wrote:
> > > I would like to create a login that has access to one category at the
> > > highest sensitivity level, but in another category only has access at a
> > > lower sensitivity level.  For example, on a system where SystemHigh is
> > > s0-s3:c0.c3, one login could be defined as something similar to:
> > > s0-s1:c0.c3, s2:c2.c3, s3:c3, while another login could be defined as
> > > s0-s2:c0.c3, s3:c0.c2 .
> > > 
> > > Am I correct that MLS policy cannot support this scenario?
> > > 
> > > Is this possible under any old, current, or developmental SELinux
> > > policy?
> > > 
> > > Would it be possible to write such a policy with the existing SELinux
> > > user/kernel land?
> > > 
> > > Thanks for any pointers,
> > 
> > I'm not clear on what you are trying to achieve
> 
> Let me try and be more clear, or at least state things in a different
> way.
> 
> I want to build a system that stores category 0 (c0) data at each
> sensitivity level (s0-s3).  The system also stores category 1 (c1),
> category 2 (c2), and category 3 (c3) data at each sensitivity level
> (s0-s3).  Therefore the data on the system falls into the s0-s3:c0.c3
> range.
> 
> Next, I want to add users to this system.  UserA has access to all
> categories at the s0 and s1 levels.  At the s2 level UserA has access to
> categories 2 and 3.  At the s3 level UserA has access to category 3
> data.  UserA's access to data could be thought of as this set of
> { s0-s1:c0.c3, s2:c2.c3, s3:c3 } ranges.  As you can see, UserA should
> not be able to read category 0 or 1 data at the s2 level even though
> UserA can read category 3 data at the s3 range.
> 
> Similarly UserB has access to all categories at the s0, s1 and s2
> sensitivity levels.  At the s3 level UserB has access to categories 0,
> 1, and 2.  UserB's access to data could be thought of as this set of
> { s0-s2:c0.c3, s3:c0.c2 } ranges.  As you can see, UserB should not be
> able to read category 3 data at the s3 level even though UserB has
> access to category 3 data at lower sensitivity levels and has access to
> other sensitivity level 3 data.
> 
> Perhaps a better way to express this is on a per category per user
> basis:
> 
> UserA's access matrix:
> 
> category, sl0, sl1, sl2, sl3
>        0, yes, yes, no , no 
>        1, yes, yes, no , no 
>        2, yes, yes, yes, no 
>        3, yes, yes, yes, yes 
> 
> UserB's access matrix:
> 
> category, sl0, sl1, sl2, sl3
>        0, yes, yes, yes, yes
>        1, yes, yes, yes, yes
>        2, yes, yes, yes, yes
>        3, yes, yes, yes, no 
> 
> 
> I believe the difference between SELinux with MLS policy and what I am
> trying to build is that I want higher sensitivity levels to dominate
> lower sensitivity levels only on a per category basis.
> 
> For example, it is my understanding that under MLS UserB must have
> sensitivity level 3 access to category 3 because UserB has access to
> sensitivity level 3 access to other categories.  Another possibility
> under MLS would be to remove UserB's access to category 3 for all
> sensitivities.  Neither of these is what I want the system to do.
> 
> Is that more clear about what my goals are?
> 
> > At present, the kernel policy configuration specifies a default level
> > and a (single) range for each SELinux user identity defined in the
> > policy.  It also defines what categories can be associated with what
> > sensitivities, so that you could specify that e.g. c3 can only ever be
> > associated with s3, although the current refpolicy merely automatically
> > generates a list of all categories for each sensitivity.
> 
> Ok, thanks for pointing that out.
> 
> > The userland configuration specifies a SELinux user and a (single) range
> > for each Linux user / login.  That range has to be a subset of the one
> > authorized for the SELinux user.  That lets you specify subranges for
> > individual Linux users without having to define each of them within the
> > kernel policy.
> 
> Perhaps what I'm describing is multiple ranges for each user / login.
> Could that be achieved with user space modifications only?
> 
> Thanks for reading this far,

You could certainly modify the seusers configuration to support a list
of ranges per Linux user rather than only a single range.  That would
require changes to libsemanage and semanage (to add such entries) and to
libselinux and pam_selinux (to read and use such entries).

-- 
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: Not quite MLS.

[Paul McNabb]

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

Glenn is right that the Mitre LEF can only work on a per-system rather 
than a per-user basis for disallowing certain classification and 
compartment/category constraints.  The only MLS system that I know of 
that did what you are asking for is the old Addamax B1st system.  That 
MLS system had user clearances as a set of labels and label ranges that 
allowed a specific user clearance to be something like:

{ unc - ts:1,2,3; unc:4 - sec:4 ; con:5 }

which would allow the user to be cleared from unc to ts in categories 1, 
2, and 3 but have only a unc to sec clearance in category 4 and only con 
for category 5.

Strictly speaking, a system can be "fully MLS" regardless of the 
clearance functionality.  Some MLS systems have been built (and bought) 
without any notion of a user clearance at all, particularly some MLS 
systems built to the first generation of TCSEC requirements.

paul

Glenn Faden wrote:
> rob myers wrote:
>>
>> I believe the difference between SELinux with MLS policy and what I am
>> trying to build is that I want higher sensitivity levels to dominate
>> lower sensitivity levels only on a per category basis.
>>
>> For example, it is my understanding that under MLS UserB must have
>> sensitivity level 3 access to category 3 because UserB has access to
>> sensitivity level 3 access to other categories.  Another possibility
>> under MLS would be to remove UserB's access to category 3 for all
>> sensitivities.  Neither of these is what I want the system to do.
>>   
> For MLS systems based on the Mitre/DIA label encodings format it is 
> possible to exclude specific categories on a per sensitivity label 
> basis from the User Accreditation Range. For an example, see:
>
>
> So it is possible to specify a User Accreditation Range conforming to 
> either the UserA or UserB matrix. However, the format only provides 
> for a single User Accreditiation Range that would apply to all users. 
> In MLS systems I'm familiar with, there is no facility to exclude 
> categories from the kernel dominance checks.
>
> --Glenn

[-- Attachment #2: mcnabb.vcf --]
[-- Type: text/x-vcard, Size: 317 bytes --]

begin:vcard
fn:Paul McNabb
n:McNabb;Paul
org:Argus Systems Group
adr:;;1809 Woodfield Drive;Savoy;IL;61874-9505;USA
email;internet:mcnabb@argus-systems.com
title:Chief Security Architect
tel;work:+1 217-355-6308
tel;fax:+1 217-355-1433
tel;cell:+1 217-493-3818
url:http://www.argus-systems.com
version:2.1
end:vcard

Re: Not quite MLS.

[Casey Schaufler]

Paul McNabb wrote:
> Glenn is right that the Mitre LEF can only work on a per-system rather
> than a per-user basis for disallowing certain classification and
> compartment/category constraints.  The only MLS system that I know of
> that did what you are asking for is the old Addamax B1st system.  That
> MLS system had user clearances as a set of labels and label ranges
> that allowed a specific user clearance to be something like:
>
> { unc - ts:1,2,3; unc:4 - sec:4 ; con:5 }

Trusted Irix also allows ( allowed? :-( ) a list of ranges of labels.
Trix uses something like:

    user:label1:label1 label2 label3...label127 label200 label300...label400

to say that user would get label1 if he didn't specify a login label
and that he could ask for label1, label2, label200, any label that
dominated label3 that was also dominated by label127 or any label that
was dominated by label300 that was also dominated by label400.

The internal structure of Trix labels is sufficiently complicated that
no one ever spelled them out, they always used aliases.
>
> which would allow the user to be cleared from unc to ts in categories
> 1, 2, and 3 but have only a unc to sec clearance in category 4 and
> only con for category 5.
>
> Strictly speaking, a system can be "fully MLS" regardless of the
> clearance functionality.  Some MLS systems have been built (and
> bought) without any notion of a user clearance at all, particularly
> some MLS systems built to the first generation of TCSEC requirements.

The Trix kernel never had a notion of clearance. All clearance
processing was done in user space. Trix did get a B1 and an LSPP.
Sold pretty well, too. Never did use the Mitre/DIA encodings, either.
At first Mitre wouldn't let us have it, then we figured out we could
live better without it. Not having it may have cost a deal or two,
but we certainly made up for it with simpler interfaces.


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