MLS directory write constraints

MLS directory write constraints

[Christopher J. PeBenito]

After doing some work on some MLS systems last week, I observed some
constraint denials like this:

type=AVC msg=audit(1187122358.679:120): avc:  denied  { write } for
pid=2829 comm="foo" name="run" dev=dm-0 ino=3309608
scontext=system_u:system_r:foo_t:s15:c0.c1023
tcontext=system_u:object_r:var_run_t:s0-s15:c0.c1023
tclass=dir

Where a daemon has TE rules for creating it's PID file in /var/run, but
gets denied by this MLS constraint:

mlsconstrain { file ... dir ... } { write create setattr relabelfrom append unlink link rename mounton }
	(( l1 eq l2 ) or
	 (( t1 == mlsfilewritetoclr ) and ( h1 dom l2 ) and ( l1 domby l2 )) or
	 (( t2 == mlsfilewriteinrange ) and ( l1 dom l2 ) and ( h1 domby h2 )) or
	 ( t1 == mlsfilewrite ) or
	 ( t2 == mlstrustedobject ));

It seems like it should be able to create a file in the directory, since
the daemon's level is within the range of the directory.  The
constraints for the other dir-specific permissions seems to confirm
this:

mlsconstrain dir { add_name remove_name reparent rmdir }
	((( l1 dom l2 ) and ( l1 domby h2 )) or
	 (( t1 == mlsfilewritetoclr ) and ( h1 dom l2 ) and ( l1 domby l2 )) or
	 ( t1 == mlsfilewrite ) or
	 ( t2 == mlstrustedobject ));

But since creating or deleting a file in a directory requires write and
add_name or remove_name, respectively, you still must have equality in
level to create a file in /var/run.  Because of this, I believe there
potentially are superfluous write downs for daemons that don't run in
system low.  I think the constraints should be changed to this:

# single level "write"
mlsconstrain { file ... } { write create setattr relabelfrom append unlink link rename mounton }
	(( l1 eq l2 ) or
	 (( t1 == mlsfilewritetoclr ) and ( h1 dom l2 ) and ( l1 domby l2 )) or
	 (( t2 == mlsfilewriteinrange ) and ( l1 dom l2 ) and ( h1 domby h2 )) or
	 ( t1 == mlsfilewrite ) or
	 ( t2 == mlstrustedobject ));

mlsconstrain dir { create setattr relabelfrom append unlink link rename mounton reparent rmdir }
	(( l1 eq l2 ) or
	 (( t1 == mlsfilewritetoclr ) and ( h1 dom l2 ) and ( l1 domby l2 )) or
	 (( t2 == mlsfilewriteinrange ) and ( l1 dom l2 ) and ( h1 domby h2 )) or
	 ( t1 == mlsfilewrite ) or
	 ( t2 == mlstrustedobject ));

# ranged "write" for adding and removing directory entries
mlsconstrain dir { write add_name remove_name }
	((( l1 dom l2 ) and ( l1 domby h2 )) or
	 (( t1 == mlsfilewritetoclr ) and ( h1 dom l2 ) and ( l1 domby l2 )) or
	 ( t1 == mlsfilewrite ) or
	 ( t2 == mlstrustedobject ));

Comments?

-- 
Chris PeBenito
Tresys Technology, LLC
(410) 290-1411 x150


--
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: MLS directory write constraints

[Klaus Weidner]

On Mon, Aug 20, 2007 at 08:34:57AM -0400, Christopher J. PeBenito wrote:
> After doing some work on some MLS systems last week, I observed some
> constraint denials like this:
> 
> type=AVC msg=audit(1187122358.679:120): avc:  denied  { write } for
> pid=2829 comm="foo" name="run" dev=dm-0 ino=3309608
> scontext=system_u:system_r:foo_t:s15:c0.c1023
> tcontext=system_u:object_r:var_run_t:s0-s15:c0.c1023
> tclass=dir
> 
> Where a daemon has TE rules for creating it's PID file in /var/run, but
> gets denied by this MLS constraint:
> 
> mlsconstrain { file ... dir ... } { write create setattr relabelfrom append unlink link rename mounton }
> 	(( l1 eq l2 ) or
> 	 (( t1 == mlsfilewritetoclr ) and ( h1 dom l2 ) and ( l1 domby l2 )) or
> 	 (( t2 == mlsfilewriteinrange ) and ( l1 dom l2 ) and ( h1 domby h2 )) or
> 	 ( t1 == mlsfilewrite ) or
> 	 ( t2 == mlstrustedobject ));
> 
> It seems like it should be able to create a file in the directory, since
> the daemon's level is within the range of the directory.

Ranged directories are an information leak in an MLS system, the current
restrictions are intentionally set the way they are to prevent them.

For the CC evaluation of LSPP compliance, we needed to draw a line
between explicit data flows (which need to be enforced by the OS), and
covert channels (which are beyond the scope of the evaluation). 

The method we used to decide this was to check if an interface allows
creation of arbitrary textual/binary data that can be read at another
level - if that's the case, the OS needs to enforce the strict LSPP MLS
constraints and prevent write down. Unfortunately directory write
operations to ranged directories would break this constraint since the
filenames can be chosen arbitrarily and read at lower levels, and this
must not be allowed for untrusted subjects.

You'd need to use one of the subject or object override attributes to
permit this access if you need it - that's what they are there for, and
if you need more granularity it may make sense to define a
"mlswritetorangeddir" attribute to allow only this specific override. For
LSPP compliance, the default behavior for untrusted subjects should
remain not to allow it.

-Klaus

--
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: MLS directory write constraints

[Klaus Weidner]

On Mon, Aug 20, 2007 at 08:34:57AM -0400, Christopher J. PeBenito wrote:
> But since creating or deleting a file in a directory requires write and
> add_name or remove_name, respectively, you still must have equality in
> level to create a file in /var/run.  Because of this, I believe there
> potentially are superfluous write downs for daemons that don't run in
> system low.  I think the constraints should be changed to this:

Here's a link to a previous discussion on this list about the
directory constraints:

  http://www.nsa.gov/selinux/list-archive/0612/18627.cfm

(Subject "[PATCH RFC 0/2] stricter MLS policy constraints", Dec 12 2006)

-Klaus

--
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: MLS directory write constraints

[Christopher J. PeBenito]

On Mon, 2007-08-20 at 15:52 -0500, Klaus Weidner wrote: 
> On Mon, Aug 20, 2007 at 08:34:57AM -0400, Christopher J. PeBenito wrote:
> > After doing some work on some MLS systems last week, I observed some
> > constraint denials like this:
> > 
> > type=AVC msg=audit(1187122358.679:120): avc:  denied  { write } for
> > pid=2829 comm="foo" name="run" dev=dm-0 ino=3309608
> > scontext=system_u:system_r:foo_t:s15:c0.c1023
> > tcontext=system_u:object_r:var_run_t:s0-s15:c0.c1023
> > tclass=dir
> > 
> > Where a daemon has TE rules for creating it's PID file in /var/run, but
> > gets denied by this MLS constraint:
> > 
> > mlsconstrain { file ... dir ... } { write create setattr relabelfrom append unlink link rename mounton }
> > 	(( l1 eq l2 ) or
> > 	 (( t1 == mlsfilewritetoclr ) and ( h1 dom l2 ) and ( l1 domby l2 )) or
> > 	 (( t2 == mlsfilewriteinrange ) and ( l1 dom l2 ) and ( h1 domby h2 )) or
> > 	 ( t1 == mlsfilewrite ) or
> > 	 ( t2 == mlstrustedobject ));
> > 
> > It seems like it should be able to create a file in the directory, since
> > the daemon's level is within the range of the directory.
> 
> Ranged directories are an information leak in an MLS system, the current
> restrictions are intentionally set the way they are to prevent them.
> 
> For the CC evaluation of LSPP compliance, we needed to draw a line
> between explicit data flows (which need to be enforced by the OS), and
> covert channels (which are beyond the scope of the evaluation). 
> 
> The method we used to decide this was to check if an interface allows
> creation of arbitrary textual/binary data that can be read at another
> level - if that's the case, the OS needs to enforce the strict LSPP MLS
> constraints and prevent write down. Unfortunately directory write
> operations to ranged directories would break this constraint since the
> filenames can be chosen arbitrarily and read at lower levels, and this
> must not be allowed for untrusted subjects.

Does RHEL5 LSPP have a polyinstantiated /var/run?  If not, then every
daemon that doesn't run with a system low level will need this at a
minimum, thus partially negating what you are trying to do.

> You'd need to use one of the subject or object override attributes to
> permit this access if you need it - that's what they are there for, and
> if you need more granularity it may make sense to define a
> "mlswritetorangeddir" attribute to allow only this specific override. For
> LSPP compliance, the default behavior for untrusted subjects should
> remain not to allow it.

I see that the constraints are different in the 2.4.6-67 LSPP policy.
Is this the final one?  I want to make sure that the LSPP policy changes
have been integrated upstream.

-- 
Chris PeBenito
Tresys Technology, LLC
(410) 290-1411 x150


--
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: MLS directory write constraints

[Klaus Weidner]

On Tue, Aug 21, 2007 at 09:10:23AM -0400, Christopher J. PeBenito wrote:
> On Mon, 2007-08-20 at 15:52 -0500, Klaus Weidner wrote: 
> > Ranged directories are an information leak in an MLS system, the current
> > restrictions are intentionally set the way they are to prevent them.
> > 
> > For the CC evaluation of LSPP compliance, we needed to draw a line
> > between explicit data flows (which need to be enforced by the OS), and
> > covert channels (which are beyond the scope of the evaluation). 
> > 
> > The method we used to decide this was to check if an interface allows
> > creation of arbitrary textual/binary data that can be read at another
> > level - if that's the case, the OS needs to enforce the strict LSPP MLS
> > constraints and prevent write down. Unfortunately directory write
> > operations to ranged directories would break this constraint since the
> > filenames can be chosen arbitrarily and read at lower levels, and this
> > must not be allowed for untrusted subjects.
> 
> Does RHEL5 LSPP have a polyinstantiated /var/run?  If not, then every
> daemon that doesn't run with a system low level will need this at a
> minimum, thus partially negating what you are trying to do.

By default /var/run doesn't get polyinstantiated in the LSPP config, and
I'm not sure if that would have the desired effect. The polyinst
namespace gets chosen at login time based on the interactive user's
properties, so it would not do the right thing for daemons.

It's fine from the CC/LSPP perspective if noninteractive system daemons
have a ranged-directory override attribute for their type, as long as the
interactive users are properly limited. It's still a lot better than
globally permitting everyone to write to ranged directories.

I don't think that the ranged directory write permission for those few
daemons that don't run at SystemLow is a serious security concern in
practice. A main intent of LSPP is to protect against hostile code run by
a user that downgrades information, and TE provides protection against
them abusing system services for that purpose.

In the long term, I think it would be preferable to use different
level-specific directories instead of /var/run/ for other levels, but I'm
not sure if namespace polyinstantiation is the best solution for this. It
could also be configured specifically at run- or compile-time for apps
that run at SystemHigh.

> I see that the constraints are different in the 2.4.6-67 LSPP policy.
> Is this the final one?  I want to make sure that the LSPP policy changes
> have been integrated upstream.

selinux-policy-2.4.6-67.el5 is the evaluated version, that's the one that
is known to match LSPP requirements. The version in the older thread that
I linked to wasn't final yet, we had made some minor modifications last
year to get to the final version. Please use the
selinux-policy-2.4.6-67.el5 constraints for upstream if possible.

-Klaus

--
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: MLS directory write constraints

[Christopher J. PeBenito]

On Thu, 2007-08-23 at 18:05 -0500, Klaus Weidner wrote:
> On Tue, Aug 21, 2007 at 09:10:23AM -0400, Christopher J. PeBenito
> wrote:
> > I see that the constraints are different in the 2.4.6-67 LSPP policy.
> > Is this the final one?  I want to make sure that the LSPP policy changes
> > have been integrated upstream.
> 
> selinux-policy-2.4.6-67.el5 is the evaluated version, that's the one that
> is known to match LSPP requirements. The version in the older thread that
> I linked to wasn't final yet, we had made some minor modifications last
> year to get to the final version. Please use the
> selinux-policy-2.4.6-67.el5 constraints for upstream if possible.

I have updated the refpolicy constraints with the above policy's
constraints.

-- 
Chris PeBenito
Tresys Technology, LLC
(410) 290-1411 x150


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