Existence of "helper" functions (specifcally MLS)

Existence of "helper" functions (specifcally MLS)

[Michael C Thompson]

Hey all,

I haven't looked extensively, but I was wondering if there exist any 
funcitons (probably in libselinux?) which would do comparisons on MLS 
labels and would return back whether or not one dominates another, or if 
the categories are equal (or a subset), etc.

Thanks much,
Mike


--
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: Existence of "helper" functions (specifcally MLS)

[David Quigley]

On Thu, 2006-07-20 at 15:51 -0500, Michael C Thompson wrote:
> Hey all,
> 
> I haven't looked extensively, but I was wondering if there exist any 
> funcitons (probably in libselinux?) which would do comparisons on MLS 
> labels and would return back whether or not one dominates another, or if 
> the categories are equal (or a subset), etc.
> 
> Thanks much,
> Mike
> 
> 
> --
> 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.

Hello,
	Sorry for the late reply but I was at OLS all of last week. I currently
have this implemented but it is not upstreamed yet. It required changes
in both libselinux and in the kernel. I can generate a set of patches
for you if you need it before I can get it upstream however they are
currently against 2.6.18-rc1.

-- 
David Quigley <dpquigl@tycho.nsa.gov>


--
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: Existence of "helper" functions (specifcally MLS)

[Joe Nall]

On Jul 24, 2006, at 8:45 AM, David Quigley wrote:

> On Thu, 2006-07-20 at 15:51 -0500, Michael C Thompson wrote:
>> Hey all,
>>
>> I haven't looked extensively, but I was wondering if there exist any
>> funcitons (probably in libselinux?) which would do comparisons on MLS
>> labels and would return back whether or not one dominates another,  
>> or if
>> the categories are equal (or a subset), etc.
>>
>> Thanks much,
>> Mike
>>
>
> Hello,
> 	Sorry for the late reply but I was at OLS all of last week. I  
> currently
> have this implemented but it is not upstreamed yet. It required  
> changes
> in both libselinux and in the kernel. I can generate a set of patches
> for you if you need it before I can get it upstream however they are
> currently against 2.6.18-rc1.

Why does this require kernel changes? I would expect this to be a  
function comparing the levels and category bitmaps.

joe

--
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: Existence of "helper" functions (specifcally MLS)

[Stephen Smalley]

On Mon, 2006-07-24 at 09:15 -0500, Joe Nall wrote:
> On Jul 24, 2006, at 8:45 AM, David Quigley wrote:
> 
> > On Thu, 2006-07-20 at 15:51 -0500, Michael C Thompson wrote:
> >> Hey all,
> >>
> >> I haven't looked extensively, but I was wondering if there exist any
> >> funcitons (probably in libselinux?) which would do comparisons on MLS
> >> labels and would return back whether or not one dominates another,  
> >> or if
> >> the categories are equal (or a subset), etc.
> >>
> >> Thanks much,
> >> Mike
> >>
> >
> > Hello,
> > 	Sorry for the late reply but I was at OLS all of last week. I  
> > currently
> > have this implemented but it is not upstreamed yet. It required  
> > changes
> > in both libselinux and in the kernel. I can generate a set of patches
> > for you if you need it before I can get it upstream however they are
> > currently against 2.6.18-rc1.
> 
> Why does this require kernel changes? I would expect this to be a  
> function comparing the levels and category bitmaps.

Only the policy engine can interpret the security labels.  So you have
two choices:  ask the kernel's policy engine via selinuxfs or use
libsepol on the on-disk policy file.  Advantage of the former is that a)
the kernel has already parsed and loaded the policy into memory, so you
avoid that cost again, and b) you ensure that you are dealing with the
same exact policy that the kernel is enforcing.

-- 
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: Existence of "helper" functions (specifcally MLS)

[Joe Nall]

On Jul 24, 2006, at 9:30 AM, Stephen Smalley wrote:

> On Mon, 2006-07-24 at 09:15 -0500, Joe Nall wrote:
>> On Jul 24, 2006, at 8:45 AM, David Quigley wrote:
>>
>>> On Thu, 2006-07-20 at 15:51 -0500, Michael C Thompson wrote:
>>>> Hey all,
>>>>
>>>> I haven't looked extensively, but I was wondering if there exist  
>>>> any
>>>> funcitons (probably in libselinux?) which would do comparisons  
>>>> on MLS
>>>> labels and would return back whether or not one dominates another,
>>>> or if
>>>> the categories are equal (or a subset), etc.
>>>>
>>>> Thanks much,
>>>> Mike
>>>>
>>>
>>> Hello,
>>> 	Sorry for the late reply but I was at OLS all of last week. I
>>> currently
>>> have this implemented but it is not upstreamed yet. It required
>>> changes
>>> in both libselinux and in the kernel. I can generate a set of  
>>> patches
>>> for you if you need it before I can get it upstream however they are
>>> currently against 2.6.18-rc1.
>>
>> Why does this require kernel changes? I would expect this to be a
>> function comparing the levels and category bitmaps.
>
> Only the policy engine can interpret the security labels.  So you have
> two choices:  ask the kernel's policy engine via selinuxfs or use
> libsepol on the on-disk policy file.  Advantage of the former is  
> that a)
> the kernel has already parsed and loaded the policy into memory, so  
> you
> avoid that cost again, and b) you ensure that you are dealing with the
> same exact policy that the kernel is enforcing.

I understand this if you include non-MLS components, but how does the
interpretation of the MLS component of a context vary with policy on one
machine?

joe

--
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: Existence of "helper" functions (specifcally MLS)

[Stephen Smalley]

On Mon, 2006-07-24 at 10:25 -0500, Joe Nall wrote:
> > Only the policy engine can interpret the security labels.  So you have
> > two choices:  ask the kernel's policy engine via selinuxfs or use
> > libsepol on the on-disk policy file.  Advantage of the former is  
> > that a)
> > the kernel has already parsed and loaded the policy into memory, so  
> > you
> > avoid that cost again, and b) you ensure that you are dealing with the
> > same exact policy that the kernel is enforcing.
> 
> I understand this if you include non-MLS components, but how does the
> interpretation of the MLS component of a context vary with policy on one
> machine?

The relationship between s0 and s1 is not implicit in the names; s0
could dominate s1; that is entirely defined by the policy itself.

Also, in general, we try to avoid MLS-specific logic outside of the
policy engine; in many cases, applications that might historically have
done a specific MLS dominance check on a traditional trusted OS should
instead be performing a SELinux permission check via avc_has_perm or
security_compute_av, and then you can internally map that permission to
a MLS relationship via the mlsconstrain statements in the policy.  So
the first question is whether this application should be performing a
MLS label comparison at all, or whether we can abstract that to a
service permission check.

-- 
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: Existence of "helper" functions (specifcally MLS)

[Casey Schaufler]

--- Stephen Smalley <sds@tycho.nsa.gov> wrote:

> Also, in general, we try to avoid MLS-specific logic
> outside of the
> policy engine; in many cases, applications that
> might historically have
> done a specific MLS dominance check on a traditional
> trusted OS should
> instead be performing a SELinux permission check via
> avc_has_perm or
> security_compute_av, and then you can internally map
> that permission to
> a MLS relationship via the mlsconstrain statements
> in the policy.  So
> the first question is whether this application
> should be performing a
> MLS label comparison at all, or whether we can
> abstract that to a
> service permission check.

Are you making the assumption that the
objects involved are among those protected
by the kernel? Application objects (e.g.
print jobs, mail messages, X11 windows, cron
jobs) may be maintained strictly by an
application that enforces policy. In such
cases the application requires access to
mechanism to determine on its own if an
access should be permitted. In the context
of an evaluation it will be very important
for the MLS policy enforcement on application
objects to be concise and clearly defined.
I expect that, as you mention above,
security_compute_av(3) is the "right" choice
for doing this. It does put the burden
of proof on the lower level function. I'd
be concerned regarding performance, but
I'm sure that issue will recieve all the
attention it needs.


Casey Schaufler
casey@schaufler-ca.com

--
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: Existence of "helper" functions (specifcally MLS)

[Stephen Smalley]

On Mon, 2006-07-24 at 09:25 -0700, Casey Schaufler wrote:
> 
> --- Stephen Smalley <sds@tycho.nsa.gov> wrote:
> 
> > Also, in general, we try to avoid MLS-specific logic
> > outside of the
> > policy engine; in many cases, applications that
> > might historically have
> > done a specific MLS dominance check on a traditional
> > trusted OS should
> > instead be performing a SELinux permission check via
> > avc_has_perm or
> > security_compute_av, and then you can internally map
> > that permission to
> > a MLS relationship via the mlsconstrain statements
> > in the policy.  So
> > the first question is whether this application
> > should be performing a
> > MLS label comparison at all, or whether we can
> > abstract that to a
> > service permission check.
> 
> Are you making the assumption that the
> objects involved are among those protected
> by the kernel?

No, this applies to userspace object managers aka policy-enforcing
applications as well.

>  Application objects (e.g.
> print jobs, mail messages, X11 windows, cron
> jobs) may be maintained strictly by an
> application that enforces policy. In such
> cases the application requires access to
> mechanism to determine on its own if an
> access should be permitted.

Yes; that is what security_compute_av(3) or avc_has_perm(3) provides;
both functions are provided by libselinux for this purpose.  Already in
use by several applications (e.g. dbusd, crond) and the
not-yet-upstreamed XACE/XSELinux work.

>  In the context
> of an evaluation it will be very important
> for the MLS policy enforcement on application
> objects to be concise and clearly defined.
> I expect that, as you mention above,
> security_compute_av(3) is the "right" choice
> for doing this. It does put the burden
> of proof on the lower level function. I'd
> be concerned regarding performance, but
> I'm sure that issue will recieve all the
> attention it needs.

The userspace AVC deals with the performance overhead.

-- 
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: Existence of "helper" functions (specifcally MLS)

[Joe Nall]

On Jul 24, 2006, at 10:34 AM, Stephen Smalley wrote:

> On Mon, 2006-07-24 at 10:25 -0500, Joe Nall wrote:
>>> Only the policy engine can interpret the security labels.  So you  
>>> have
>>> two choices:  ask the kernel's policy engine via selinuxfs or use
>>> libsepol on the on-disk policy file.  Advantage of the former is
>>> that a)
>>> the kernel has already parsed and loaded the policy into memory, so
>>> you
>>> avoid that cost again, and b) you ensure that you are dealing  
>>> with the
>>> same exact policy that the kernel is enforcing.
>>
>> I understand this if you include non-MLS components, but how does the
>> interpretation of the MLS component of a context vary with policy  
>> on one
>> machine?
>
> The relationship between s0 and s1 is not implicit in the names; s0
> could dominate s1; that is entirely defined by the policy itself.

I had totally missed that. I mapped the s[n] to the integers we
use on the CMW without any thought that they were arbitrary.

> Also, in general, we try to avoid MLS-specific logic outside of the
> policy engine; in many cases, applications that might historically  
> have
> done a specific MLS dominance check on a traditional trusted OS should
> instead be performing a SELinux permission check via avc_has_perm or
> security_compute_av, and then you can internally map that  
> permission to
> a MLS relationship via the mlsconstrain statements in the policy.  So
> the first question is whether this application should be performing a
> MLS label comparison at all, or whether we can abstract that to a
> service permission check.

We have an application that combines data of multiple levels and has to
compute the aggregate classification before saving it to a file or  
sharing
it with another process. Will there be a function to compute an  
aggregate
context from a list of contexts?

joe

--
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: Existence of "helper" functions (specifcally MLS)

[Stephen Smalley]

On Mon, 2006-07-24 at 11:48 -0500, Joe Nall wrote:
> > The relationship between s0 and s1 is not implicit in the names; s0
> > could dominate s1; that is entirely defined by the policy itself.
> 
> I had totally missed that. I mapped the s[n] to the integers we
> use on the CMW without any thought that they were arbitrary.

There is an explicit dominance definition in the policy that establishes
the relationship.

> We have an application that combines data of multiple levels and has to
> compute the aggregate classification before saving it to a file or  
> sharing
> it with another process. Will there be a function to compute an  
> aggregate
> context from a list of contexts?

For that kind of specialized application, I suspect we'd create an
interface to libsepol for that purpose rather than extending the kernel
interface.  The other issue for that kind of function is whether the
label encoding library needs to be brought into play to deal with
complex relationships among the compartments that only it presently
knows about (which ideally the kernel would understand too, but that
isn't presently the case).

-- 
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: Existence of "helper" functions (specifcally MLS)

[Joshua Brindle]

Stephen Smalley wrote:
> On Mon, 2006-07-24 at 11:48 -0500, Joe Nall wrote:
>   
>>> The relationship between s0 and s1 is not implicit in the names; s0
>>> could dominate s1; that is entirely defined by the policy itself.
>>>       
>> I had totally missed that. I mapped the s[n] to the integers we
>> use on the CMW without any thought that they were arbitrary.
>>     
>
> There is an explicit dominance definition in the policy that establishes
> the relationship.
>
>   
>> We have an application that combines data of multiple levels and has to
>> compute the aggregate classification before saving it to a file or  
>> sharing
>> it with another process. Will there be a function to compute an  
>> aggregate
>> context from a list of contexts?
>>     
>
>   
This sounds like you want to ditch TE altogether and revert to MLS 
entirely. That is, it seems like you have to since there is no such 
thing as an aggregate type. How could we possibly reconcile the user, 
role and type fields in a list of contexts? This seems like an enormous 
step backward and makes the application (whatever it is) incapable of 
using the stronger points of SELinux and from being applied to 
environments outside of the miltary/government realm.

I wonder if the hierarchal namespace for  roles and types could be 
useful here.. that would impose even more limitations on what the 
contexts could look like though but its probably better than simply 
ignoring those parts of the context.

> For that kind of specialized application, I suspect we'd create an
> interface to libsepol for that purpose rather than extending the kernel
> interface.  The other issue for that kind of function is whether the
> label encoding library needs to be brought into play to deal with
> complex relationships among the compartments that only it presently
> knows about (which ideally the kernel would understand too, but that
> isn't presently the case).
>   

--
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: Existence of "helper" functions (specifcally MLS)

[Joe Nall]

>>> We have an application that combines data of multiple levels and  
>>> has to
>>> compute the aggregate classification before saving it to a file  
>>> or  sharing
>>> it with another process. Will there be a function to compute an   
>>> aggregate
>>> context from a list of contexts?
>>>
>>
>>
> This sounds like you want to ditch TE altogether and revert to MLS  
> entirely.

Not at all.

Imagine you have a directory with a number of files with
the same type but different classification. A system high
daemon has the task of summarizing a subset of the files
into a report. The system high daemon computes a context
that will allow an unprivileged child process to read all
of the files, launches a child process which then generates
the report. The result being an appropriately classified
report - even if the system high daemon launched the child
process at the wrong level. Throughout the process, type
enforcement is mediating access to system resources.

> That is, it seems like you have to since there is no such thing as  
> an aggregate type. How could we possibly reconcile the user, role  
> and type fields in a list of contexts? This seems like an enormous  
> step backward and makes the application (whatever it is) incapable  
> of using the stronger points of SELinux and from being applied to  
> environments outside of the miltary/government realm.

There may be a type with read access to all of the data.

In the our applications there are two computations that
we perform regularly that may not have clear analogues
in the TE world:

  1) What is the classification of this collection? Often
     recast as 'What clearance must a user have to see
     this collection of data?'

  2) At what classification can these users collaborate?
     Often recast as 'What is the clearance of this group?'

joe

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