[refpolicy] [RFC] constraint change

[refpolicy] [RFC] constraint change

[Christopher J. PeBenito]

I was looking at the constraints, and I saw this one which has been
around forever (along with a similar one for sockets):

constrain dir_file_class_set { create relabelto relabelfrom }
(
        u1 == u2
        or t1 == can_change_object_identity
);

Which has the idea that you can only create and relabelto/from files
that match your seuser.  I was thinking that the intent might be clearer
if we combine with a validatetrans:

constrain dir_file_class_set { create relabelfrom }
(
        u1 == u2
        or t1 == can_change_object_identity
);

validatetrans dir_file_class_set
(
        u1 == u2
        or t3 == can_change_object_identity
);

Thoughts?


(on a side note I think it would be even clearer if language syntax
permitted the validatetrans to have u1 == u3, but I suspect it requires
a kernel change)

-- 
Chris PeBenito
Tresys Technology, LLC
www.tresys.com | oss.tresys.com

[refpolicy] [RFC] constraint change

[Dominick Grift]

On Wed, Mar 04, 2015 at 01:36:43PM -0500, Christopher J. PeBenito wrote:
> I was looking at the constraints, and I saw this one which has been
> around forever (along with a similar one for sockets):
> 
> constrain dir_file_class_set { create relabelto relabelfrom }
> (
>         u1 == u2
>         or t1 == can_change_object_identity
> );
> 
> Which has the idea that you can only create and relabelto/from files
> that match your seuser.  I was thinking that the intent might be clearer
> if we combine with a validatetrans:
> 
> constrain dir_file_class_set { create relabelfrom }
> (
>         u1 == u2
>         or t1 == can_change_object_identity
> );
> 
> validatetrans dir_file_class_set
> (
>         u1 == u2
>         or t3 == can_change_object_identity
> );
> 
> Thoughts?

I am not sure how you figure that the intent might be clearer this way because it adds another block of expressions.

I would argue that turning one block into two blocks might make the intent less clear.

In the end though i have no strong feelings about this one way or another as long as the end result is the same.

> 
> 
> (on a side note I think it would be even clearer if language syntax
> permitted the validatetrans to have u1 == u3, but I suspect it requires
> a kernel change)
> 
> -- 
> Chris PeBenito
> Tresys Technology, LLC
> www.tresys.com | oss.tresys.com
> _______________________________________________
> refpolicy mailing list
> refpolicy at oss.tresys.com
> http://oss.tresys.com/mailman/listinfo/refpolicy

-- 
02DFF788
4D30 903A 1CF3 B756 FB48  1514 3148 83A2 02DF F788
http://keys.gnupg.net/pks/lookup?op=vindex&search=0x314883A202DFF788
Dominick Grift
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 648 bytes
Desc: not available
Url : http://oss.tresys.com/pipermail/refpolicy/attachments/20150304/bd9d3c69/attachment.bin