limitations of CONTEXT__CONTAINS interface

limitations of CONTEXT__CONTAINS interface

[Eamon Walsh]

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

The attached C code uses the CONTEXT__CONTAINS permission check to check
dominance, and produces the following output on my mls box:

staff_u:staff_r:staff_t:s15:c0.c255 dominates staff_u:staff_r:staff_t:s0

system_u:object_r:etc_t:s15:c0.c255 does not dominate system_u:object_r:etc_t:s0


Why doesn't this check work in the second case?

My color translation code has a config file that may contain lines such
as (paraphrasing):
range s0 = green
range s1 = yellow
range s1:c1 = blue
range s15:c0.c255 = red

and so forth, which are matched with incoming contexts using a dominance
check.  The observed behavior above is causing this not to work.


-- 
Eamon Walsh <ewalsh@tycho.nsa.gov>
National Security Agency


[-- Attachment #2: test.c --]
[-- Type: text/x-csrc, Size: 1759 bytes --]

#include <stdlib.h>
#include <stdio.h>
#include <string.h>
#include <selinux/flask.h>
#include <selinux/av_permissions.h>
#include <selinux/selinux.h>
#include <selinux/context.h>

#define FAKE_LO_RANGE "s0"
#define FAKE_HI_RANGE "s15:c0.c255"

#define CONVENIENT_FILE "/etc/hosts"

static void check_dominance(char *one, char *two)
{
	unsigned int bit = CONTEXT__CONTAINS;
	struct av_decision avd;
	int rc;

	rc = security_compute_av_raw(one, two, SECCLASS_CONTEXT, bit, &avd);
	if (rc)
		printf("security_compute_av_raw() returned error!\n");
	else if ((bit & avd.allowed) == bit)
		printf("%s dominates %s\n", one, two);
	else
		printf("%s does not dominate %s\n", one, two);
}

static int make_fake_contexts(security_context_t proc_ctx,
			      security_context_t file_ctx)
{
	security_context_t proc_hi, proc_lo, file_hi, file_lo;
	context_t proc_con, file_con;
	unsigned int bit = CONTEXT__CONTAINS;
	struct av_decision avd;

	proc_con = context_new(proc_ctx);
	file_con = context_new(file_ctx);

	context_range_set(proc_con, FAKE_HI_RANGE);
	proc_hi = strdup(context_str(proc_con));
	context_range_set(file_con, FAKE_HI_RANGE);
	file_hi = strdup(context_str(file_con));

	context_range_set(proc_con, FAKE_LO_RANGE);
	proc_lo = strdup(context_str(proc_con));
	context_range_set(file_con, FAKE_LO_RANGE);
	file_lo = strdup(context_str(file_con));

	check_dominance(proc_hi, proc_lo);
	check_dominance(file_hi, file_lo);

	freecon(proc_hi);
	freecon(proc_lo);
	context_free(proc_con);
	freecon(file_hi);
	freecon(file_lo);
	context_free(file_con);
	return 0;
}

int main(int argc, char **argv)
{
	security_context_t proc_ctx, file_ctx;

	getcon(&proc_ctx);
	getfilecon(CONVENIENT_FILE, &file_ctx);

	make_fake_contexts(proc_ctx, file_ctx);

	return 0;
}

Re: limitations of CONTEXT__CONTAINS interface

[Stephen Smalley]

On Fri, 2008-12-05 at 19:46 -0500, Eamon Walsh wrote:
> The attached C code uses the CONTEXT__CONTAINS permission check to check
> dominance, and produces the following output on my mls box:
> 
> staff_u:staff_r:staff_t:s15:c0.c255 dominates staff_u:staff_r:staff_t:s0
> 
> system_u:object_r:etc_t:s15:c0.c255 does not dominate system_u:object_r:etc_t:s0
> 
> 
> Why doesn't this check work in the second case?

Likely due to a TE denial.  The existing policy likely only has:
allow domain self:context contains;
as the original use case for this check was to apply a check between two
subject contexts.

If you want to use it for object contexts, you'll have to allow it for
those types as well.

> My color translation code has a config file that may contain lines such
> as (paraphrasing):
> range s0 = green
> range s1 = yellow
> range s1:c1 = blue
> range s15:c0.c255 = red
> 
> and so forth, which are matched with incoming contexts using a dominance
> check.  The observed behavior above is causing this not to work.

-- 
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: limitations of CONTEXT__CONTAINS interface

[Xavier Toth]

On Mon, Dec 8, 2008 at 8:22 AM, Stephen Smalley <sds@tycho.nsa.gov> wrote:
> On Fri, 2008-12-05 at 19:46 -0500, Eamon Walsh wrote:
>> The attached C code uses the CONTEXT__CONTAINS permission check to check
>> dominance, and produces the following output on my mls box:
>>
>> staff_u:staff_r:staff_t:s15:c0.c255 dominates staff_u:staff_r:staff_t:s0
>>
>> system_u:object_r:etc_t:s15:c0.c255 does not dominate system_u:object_r:etc_t:s0
>>
>>
>> Why doesn't this check work in the second case?
>
> Likely due to a TE denial.  The existing policy likely only has:
> allow domain self:context contains;
> as the original use case for this check was to apply a check between two
> subject contexts.
>
> If you want to use it for object contexts, you'll have to allow it for
> those types as well.
>
>> My color translation code has a config file that may contain lines such
>> as (paraphrasing):
>> range s0 = green
>> range s1 = yellow
>> range s1:c1 = blue
>> range s15:c0.c255 = red
>>
>> and so forth, which are matched with incoming contexts using a dominance
>> check.  The observed behavior above is causing this not to work.
>
> --
> 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.
>

Can anyone help me understand the results I'm getting here? I wrote
this python script (compute_av.py) to test the dominance check:

import selinux
SECCLASS_CONTEXT = selinux.string_to_security_class("context")
CONTEXT__CONTAINS = 2

rc, con = selinux.getcon()
con_array = con.split(":")

avd = selinux.av_decision()
con_array[3] = "s0:c0.c255"
ctx = ':'.join(con_array)
con_array[3] = "s0"
raw = ':'.join(con_array)
rc = selinux.security_compute_av_raw(ctx, raw, SECCLASS_CONTEXT,
CONTEXT__CONTAINS, avd)
print ctx, raw, avd.allowed


[tedx@comms ~]$ runcon system_u:system_r:initrc_t:s0-s15:c0.c1023
python compute_av.py
system_u:system_r:initrc_t:s0:c0.c255 system_u:system_r:initrc_t:s0 0
[tedx@comms ~]$ python compute_av.py
user_u:user_r:user_t:s0:c0.c255 user_u:user_r:user_t:s0 2


I ran these test in permissive mode. Why doesn't
system_u:system_r:initrc_t:s0:c0.c255 dominate
system_u:system_r:initrc_t:s0?

Ted

--
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: limitations of CONTEXT__CONTAINS interface

[Stephen Smalley]

On Fri, 2008-12-19 at 15:27 -0600, Xavier Toth wrote:
> On Mon, Dec 8, 2008 at 8:22 AM, Stephen Smalley <sds@tycho.nsa.gov> wrote:
> > On Fri, 2008-12-05 at 19:46 -0500, Eamon Walsh wrote:
> >> The attached C code uses the CONTEXT__CONTAINS permission check to check
> >> dominance, and produces the following output on my mls box:
> >>
> >> staff_u:staff_r:staff_t:s15:c0.c255 dominates staff_u:staff_r:staff_t:s0
> >>
> >> system_u:object_r:etc_t:s15:c0.c255 does not dominate system_u:object_r:etc_t:s0
> >>
> >>
> >> Why doesn't this check work in the second case?
> >
> > Likely due to a TE denial.  The existing policy likely only has:
> > allow domain self:context contains;
> > as the original use case for this check was to apply a check between two
> > subject contexts.
> >
> > If you want to use it for object contexts, you'll have to allow it for
> > those types as well.
> >
> >> My color translation code has a config file that may contain lines such
> >> as (paraphrasing):
> >> range s0 = green
> >> range s1 = yellow
> >> range s1:c1 = blue
> >> range s15:c0.c255 = red
> >>
> >> and so forth, which are matched with incoming contexts using a dominance
> >> check.  The observed behavior above is causing this not to work.
> >
> > --
> > 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.
> >
> 
> Can anyone help me understand the results I'm getting here? I wrote
> this python script (compute_av.py) to test the dominance check:
> 
> import selinux
> SECCLASS_CONTEXT = selinux.string_to_security_class("context")
> CONTEXT__CONTAINS = 2
> 
> rc, con = selinux.getcon()
> con_array = con.split(":")
> 
> avd = selinux.av_decision()
> con_array[3] = "s0:c0.c255"
> ctx = ':'.join(con_array)
> con_array[3] = "s0"
> raw = ':'.join(con_array)
> rc = selinux.security_compute_av_raw(ctx, raw, SECCLASS_CONTEXT,
> CONTEXT__CONTAINS, avd)
> print ctx, raw, avd.allowed
> 
> 
> [tedx@comms ~]$ runcon system_u:system_r:initrc_t:s0-s15:c0.c1023
> python compute_av.py
> system_u:system_r:initrc_t:s0:c0.c255 system_u:system_r:initrc_t:s0 0
> [tedx@comms ~]$ python compute_av.py
> user_u:user_r:user_t:s0:c0.c255 user_u:user_r:user_t:s0 2
> 
> 
> I ran these test in permissive mode. Why doesn't
> system_u:system_r:initrc_t:s0:c0.c255 dominate
> system_u:system_r:initrc_t:s0?

Existing policy likely only allows context contains permission for the
user domains, as that was the only original use case for it (for
checking whether a specified user context is contained by another).

-- 
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: limitations of CONTEXT__CONTAINS interface

[Xavier Toth]

On Mon, Jan 5, 2009 at 7:18 AM, Stephen Smalley <sds@tycho.nsa.gov> wrote:
> On Fri, 2008-12-19 at 15:27 -0600, Xavier Toth wrote:
>> On Mon, Dec 8, 2008 at 8:22 AM, Stephen Smalley <sds@tycho.nsa.gov> wrote:
>> > On Fri, 2008-12-05 at 19:46 -0500, Eamon Walsh wrote:
>> >> The attached C code uses the CONTEXT__CONTAINS permission check to check
>> >> dominance, and produces the following output on my mls box:
>> >>
>> >> staff_u:staff_r:staff_t:s15:c0.c255 dominates staff_u:staff_r:staff_t:s0
>> >>
>> >> system_u:object_r:etc_t:s15:c0.c255 does not dominate system_u:object_r:etc_t:s0
>> >>
>> >>
>> >> Why doesn't this check work in the second case?
>> >
>> > Likely due to a TE denial.  The existing policy likely only has:
>> > allow domain self:context contains;
>> > as the original use case for this check was to apply a check between two
>> > subject contexts.
>> >
>> > If you want to use it for object contexts, you'll have to allow it for
>> > those types as well.
>> >
>> >> My color translation code has a config file that may contain lines such
>> >> as (paraphrasing):
>> >> range s0 = green
>> >> range s1 = yellow
>> >> range s1:c1 = blue
>> >> range s15:c0.c255 = red
>> >>
>> >> and so forth, which are matched with incoming contexts using a dominance
>> >> check.  The observed behavior above is causing this not to work.
>> >
>> > --
>> > 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.
>> >
>>
>> Can anyone help me understand the results I'm getting here? I wrote
>> this python script (compute_av.py) to test the dominance check:
>>
>> import selinux
>> SECCLASS_CONTEXT = selinux.string_to_security_class("context")
>> CONTEXT__CONTAINS = 2
>>
>> rc, con = selinux.getcon()
>> con_array = con.split(":")
>>
>> avd = selinux.av_decision()
>> con_array[3] = "s0:c0.c255"
>> ctx = ':'.join(con_array)
>> con_array[3] = "s0"
>> raw = ':'.join(con_array)
>> rc = selinux.security_compute_av_raw(ctx, raw, SECCLASS_CONTEXT,
>> CONTEXT__CONTAINS, avd)
>> print ctx, raw, avd.allowed
>>
>>
>> [tedx@comms ~]$ runcon system_u:system_r:initrc_t:s0-s15:c0.c1023
>> python compute_av.py
>> system_u:system_r:initrc_t:s0:c0.c255 system_u:system_r:initrc_t:s0 0
>> [tedx@comms ~]$ python compute_av.py
>> user_u:user_r:user_t:s0:c0.c255 user_u:user_r:user_t:s0 2
>>
>>
>> I ran these test in permissive mode. Why doesn't
>> system_u:system_r:initrc_t:s0:c0.c255 dominate
>> system_u:system_r:initrc_t:s0?
>
> Existing policy likely only allows context contains permission for the
> user domains, as that was the only original use case for it (for
> checking whether a specified user context is contained by another).
>
> --
> Stephen Smalley
> National Security Agency
>
>

I posted a refpolicy patch to allow setrans_t this premission because
the mcstrans color patch requires it.

Ted

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