New MLS constraint?

New MLS constraint?

[Matt Anderson]

With the removal of TCS's dev-allocator the solution for multi-level
printers that came out of the LSPP calls was to set a range on the
printer device, using chcon, and use SELinux to verify that the print
job was inside that range.

I've since added checking code to the server which does not allow jobs
to be enqueued into the spool or queued and printed unless an
avc_has_perm() check passes.  The current check uses SECCLASS_FILE, and
checks FILE__WRITE;

The subject is something like user_u:user_r:user_lpr_t:s2:A
The object is: system_u:object_r:printer_device_t:s2-s15:c0.c1023

When I do this check however, I get denied whenever the user's context
does not equal the lower level.  Is there a constraint that I can apply,
preferably to the object's type (printer_device_t as opposed to *_lpr_t,
) that would allow the above check to succeed?

-matt

--
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: New MLS constraint?

[Christopher J. PeBenito]

On Mon, 2006-10-16 at 12:40 -0400, Matt Anderson wrote:
> With the removal of TCS's dev-allocator the solution for multi-level
> printers that came out of the LSPP calls was to set a range on the
> printer device, using chcon, and use SELinux to verify that the print
> job was inside that range.
> 
> I've since added checking code to the server which does not allow jobs
> to be enqueued into the spool or queued and printed unless an
> avc_has_perm() check passes.  The current check uses SECCLASS_FILE, and
> checks FILE__WRITE;

Why are you using file?  The printer device chr_file.

> The subject is something like user_u:user_r:user_lpr_t:s2:A
> The object is: system_u:object_r:printer_device_t:s2-s15:c0.c1023
> 
> When I do this check however, I get denied whenever the user's context
> does not equal the lower level.

Here is the current (abbreviated) constraint:

mlsconstrain { file chr_file ... } { write ... }
	(( l1 eq l2 ) or
	 (( t1 == mlsfilewritetoclr ) and ( h1 dom l2 ) and ( l1 domby l2 )) or
	 ( t1 == mlsfilewrite ) or
	 ( t2 == mlstrustedobject ));

The first line of the expression explains why you needed write equality
on the level.

> Is there a constraint that I can apply,
> preferably to the object's type (printer_device_t as opposed to *_lpr_t,
> ) that would allow the above check to succeed?

We could add another 'or' on the above constraint:

or ( (t2 == mlsfilewrite_in_range) and (l1 dom l2) and (h1 domby h2) )

I believe that would be the constraint you were looking for.  I don't
like the name of that attribute, but I couldn't come up with a better
one off the top of my head. :)

-- 
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: New MLS constraint?

[Matt Anderson]

Christopher J. PeBenito wrote:
> On Mon, 2006-10-16 at 12:40 -0400, Matt Anderson wrote:
> 
>>With the removal of TCS's dev-allocator the solution for multi-level
>>printers that came out of the LSPP calls was to set a range on the
>>printer device, using chcon, and use SELinux to verify that the print
>>job was inside that range.
>>
>>I've since added checking code to the server which does not allow jobs
>>to be enqueued into the spool or queued and printed unless an
>>avc_has_perm() check passes.  The current check uses SECCLASS_FILE, and
>>checks FILE__WRITE;
> 
> 
> Why are you using file?  The printer device chr_file.

You're right, I'll change that.

>>The subject is something like user_u:user_r:user_lpr_t:s2:A
>>The object is: system_u:object_r:printer_device_t:s2-s15:c0.c1023
>>
>>When I do this check however, I get denied whenever the user's context
>>does not equal the lower level.
> 
> 
> Here is the current (abbreviated) constraint:
> 
> mlsconstrain { file chr_file ... } { write ... }
> 	(( l1 eq l2 ) or
> 	 (( t1 == mlsfilewritetoclr ) and ( h1 dom l2 ) and ( l1 domby l2 )) or
> 	 ( t1 == mlsfilewrite ) or
> 	 ( t2 == mlstrustedobject ));
> 
> The first line of the expression explains why you needed write equality
> on the level.
> 
> 
>>Is there a constraint that I can apply,
>>preferably to the object's type (printer_device_t as opposed to *_lpr_t,
>>) that would allow the above check to succeed?
> 
> 
> We could add another 'or' on the above constraint:
> 
> or ( (t2 == mlsfilewrite_in_range) and (l1 dom l2) and (h1 domby h2) )
> 
> I believe that would be the constraint you were looking for.  I don't
> like the name of that attribute, but I couldn't come up with a better
> one off the top of my head. :)

So far all I've come up with is mlsfilewritewithinrange which isn't any
better in my opinion, or maybe mlsfilewritetorange, but that almost
sounds like something to modify the range portion of the context.

-matt

--
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: New MLS constraint?

[Matt Anderson]

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

Christopher J. PeBenito wrote:
> We could add another 'or' on the above constraint:
> 
> or ( (t2 == mlsfilewrite_in_range) and (l1 dom l2) and (h1 domby h2) )
> 
> I believe that would be the constraint you were looking for.  I don't
> like the name of that attribute, but I couldn't come up with a better
> one off the top of my head. :)
> 

Attached is a patch which I've tested against selinux-policy-2.4.2-1
that implements this additional constraint.  The name is still a bit
forced, but it works.

-matt

[-- Attachment #2: writeinrange.patch --]
[-- Type: text/x-patch, Size: 1943 bytes --]

--- policy/mls	2006-10-27 14:50:37.000000000 -0400
+++ policy/mls-	2006-10-30 10:40:40.000000000 -0500
@@ -89,6 +89,7 @@
 mlsconstrain { file lnk_file fifo_file dir chr_file blk_file sock_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 == mlsfilewritewithinrange ) and ( l1 dom l2) and (h1 domby h2 )) or
 	 ( t1 == mlsfilewrite ) or
 	 ( t2 == mlstrustedobject ));
 
--- policy/modules/kernel/mls.te	2006-10-27 13:50:41.000000000 -0500
+++ policy/modules/kernel/mls.te-	2006-10-30 17:19:18.000000000 -0600
@@ -10,6 +10,7 @@
 attribute mlsfilereadtoclr;
 attribute mlsfilewrite;
 attribute mlsfilewritetoclr;
+attribute mlsfilewritewithinrange;
 attribute mlsfileupgrade;
 attribute mlsfiledowngrade;
 
--- policy/modules/kernel/mls.if	2006-10-30 12:07:32.000000000 -0500
+++ policy/modules/kernel/mls.if-	2006-10-30 12:07:22.000000000 -0500
@@ -470,3 +470,24 @@
 
 	typeattribute $1 mlstranslate;
 ')
+
+########################################
+## <summary>
+##	Make specified domain trusted to
+##	be written to within its MLS range.
+##	The subject's MLS range must be a
+##	proper subset of the object's MLS range.
+## </summary>
+## <param name="domain">
+##	<summary>
+##	Domain allowed access.
+##	</summary>
+## </param>
+#
+interface(`mls_file_write_within_range',`
+	gen_require(`
+		attribute mlsfilewritewithinrange;
+	')
+
+	typeattribute $1 mlsfilewritewithinrange;
+')
--- policy/modules/services/cups.te    2006-10-30 14:41:21.000000000 -0500
+++ policy/modules/services/cups.te-   2006-10-30 14:59:54.000000000 -0500
@@ -223,6 +223,7 @@
 	mls_fd_use_all_levels(cupsd_t)
 	mls_file_downgrade(cupsd_t)
 	mls_file_write_down(cupsd_t)
+        mls_file_write_within_range(printer_device_t)
 	mls_file_read_up(cupsd_t)
 	mls_rangetrans_target(cupsd_t)
 	mls_socket_write_all_levels(cupsd_t)

Re: New MLS constraint?

[Christopher J. PeBenito]

On Tue, 2006-10-31 at 19:47 -0500, Matt Anderson wrote:
> Christopher J. PeBenito wrote:
> > We could add another 'or' on the above constraint:
> > 
> > or ( (t2 == mlsfilewrite_in_range) and (l1 dom l2) and (h1 domby h2) )
> > 
> > I believe that would be the constraint you were looking for.  I don't
> > like the name of that attribute, but I couldn't come up with a better
> > one off the top of my head. :)
> > 
> 
> Attached is a patch which I've tested against selinux-policy-2.4.2-1
> that implements this additional constraint.  The name is still a bit
> forced, but it works.

Merged.  Moved the printer_device_t line to devices.

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