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
http://www.tresys.com | oss.tresys.com
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
> http://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