All of lore.kernel.org
 help / color / mirror / Atom feed
From: dac.override@gmail.com (Dominick Grift)
To: refpolicy@oss.tresys.com
Subject: [refpolicy] [RFC] constraint change
Date: Wed, 4 Mar 2015 21:07:16 +0100	[thread overview]
Message-ID: <20150304200716.GA4231@linksys-wireless-usb.network2> (raw)
In-Reply-To: <54F750BB.6010005@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
> 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 

      reply	other threads:[~2015-03-04 20:07 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-03-04 18:36 [refpolicy] [RFC] constraint change Christopher J. PeBenito
2015-03-04 20:07 ` Dominick Grift [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20150304200716.GA4231@linksys-wireless-usb.network2 \
    --to=dac.override@gmail.com \
    --cc=refpolicy@oss.tresys.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.