For bit setting in constant time, one could always clear the bit(s) and or
in what you want. I think that logic might be applicable here. I could take
a stab at looking at it today, if no one has anything better by tomorrow
well just merge yours as is. Does that sound reasonable?

On Nov 15, 2016 06:18, "Stephen Smalley" <s...@tycho.nsa.gov> wrote:

> On 11/14/2016 02:41 PM, Roberts, William C wrote:
> >
> >
> >> -----Original Message-----
> >> From: Selinux [mailto:selinux-boun...@tycho.nsa.gov] On Behalf Of
> Roberts,
> >> William C
> >> Sent: Monday, November 14, 2016 10:44 AM
> >> To: Stephen Smalley <s...@tycho.nsa.gov>; selinux@tycho.nsa.gov
> >> Subject: RE: [PATCH v2] libsepol: fix checkpolicy dontaudit compiler bug
> >>
> >>
> >>
> >>> -----Original Message-----
> >>> From: Selinux [mailto:selinux-boun...@tycho.nsa.gov] On Behalf Of
> >>> Stephen Smalley
> >>> Sent: Monday, November 14, 2016 9:48 AM
> >>> To: selinux@tycho.nsa.gov
> >>> Cc: Stephen Smalley <s...@tycho.nsa.gov>
> >>> Subject: [PATCH v2] libsepol: fix checkpolicy dontaudit compiler bug
> >>>
> >>> The combining logic for dontaudit rules was wrong, causing a dontaudit
> >>> A B:C *; rule to be clobbered by a dontaudit A B:C p; rule.
> >>>
> >>> Reported-by: Nick Kralevich <n...@google.com>
> >>> Signed-off-by: Stephen Smalley <s...@tycho.nsa.gov>
> >>> ---
> >>>  libsepol/src/expand.c | 16 ++++++++++++----
> >>>  1 file changed, 12 insertions(+), 4 deletions(-)
> >>>
> >>> diff --git a/libsepol/src/expand.c b/libsepol/src/expand.c index
> >>> 004a029..d7adbf8
> >>> 100644
> >>> --- a/libsepol/src/expand.c
> >>> +++ b/libsepol/src/expand.c
> >>> @@ -1604,7 +1604,8 @@ static int expand_range_trans(expand_state_t *
> >>> state, static avtab_ptr_t find_avtab_node(sepol_handle_t * handle,
> >>>                                avtab_t * avtab, avtab_key_t * key,
> >>>                                cond_av_list_t ** cond,
> >>> -                              av_extended_perms_t *xperms)
> >>> +                              av_extended_perms_t *xperms,
> >>> +                              char *alloced)
> >>>  {
> >>>     avtab_ptr_t node;
> >>>     avtab_datum_t avdatum;
> >>> @@ -1658,6 +1659,11 @@ static avtab_ptr_t
> >>> find_avtab_node(sepol_handle_t * handle,
> >>>                     nl->next = *cond;
> >>>                     *cond = nl;
> >>>             }
> >>> +           if (alloced)
> >>> +                   *alloced = 1;
> >>> +   } else {
> >>> +           if (alloced)
> >>> +                   *alloced = 0;
> >>>     }
> >>>
> >>>     return node;
> >>> @@ -1750,7 +1756,7 @@ static int expand_terule_helper(sepol_handle_t *
> >>> handle,
> >>>                     return EXPAND_RULE_CONFLICT;
> >>>             }
> >>>
> >>> -           node = find_avtab_node(handle, avtab, &avkey, cond, NULL);
> >>> +           node = find_avtab_node(handle, avtab, &avkey, cond, NULL,
> >>> NULL);
> >>>             if (!node)
> >>>                     return -1;
> >>>             if (enabled) {
> >>> @@ -1790,6 +1796,7 @@ static int expand_avrule_helper(sepol_handle_t *
> >>> handle,
> >>>     class_perm_node_t *cur;
> >>>     uint32_t spec = 0;
> >>>     unsigned int i;
> >>> +   char alloced;
> >>>
> >>>     if (specified & AVRULE_ALLOWED) {
> >>>             spec = AVTAB_ALLOWED;
> >>> @@ -1824,7 +1831,8 @@ static int expand_avrule_helper(sepol_handle_t *
> >>> handle,
> >>>             avkey.target_class = cur->tclass;
> >>>             avkey.specified = spec;
> >>>
> >>> -           node = find_avtab_node(handle, avtab, &avkey, cond,
> >>> extended_perms);
> >>> +           node = find_avtab_node(handle, avtab, &avkey, cond,
> >>> +                                  extended_perms, &alloced);
> >>>             if (!node)
> >>>                     return EXPAND_RULE_ERROR;
> >>>             if (enabled) {
> >>> @@ -1850,7 +1858,7 @@ static int expand_avrule_helper(sepol_handle_t *
> >>> handle,
> >>>                      */
> >>>                     avdatump->data &= cur->data;
> >>>             } else if (specified & AVRULE_DONTAUDIT) {
> >>> -                   if (avdatump->data)
> >>> +                   if (!alloced)
> >>>                             avdatump->data &= ~cur->data;
> >>>                     else
> >>>                             avdatump->data = ~cur->data;
> >>
> >> This seems awkward to me. If the insertion created a new empty node why
> >> wouldn't !avdump->data be true (note the addition of the not operator)?
> >
> > I misstated that a bit, but the !avdump->data was the else case. I am
> really
> > saying why didn't this work before? In my mind, we don't care if its
> allocated
> > we care if it's set or not.
>
> The old logic wrongly assumed that !avdatump->data would only be true if
> this was the first dontaudit rule for the (source type, target type,
> target class) and the node had just been allocated by find_avtab_node()
> with a zero avdatump->data value.
> However, if you have a dontaudit A B:C *; rule, then the set complement
> of it will be 0, so we can have !avdatump->data be true in that case
> too.  Thus, if we end up processing:
>         dontaudit A B:C *;
>         dontaudit A B:C { p1 p2 ... };
> we'll end up clobbering avdatump->data with ~{ p1 p2 ... }.
>
> The marlin policy contains:
>         dontaudit su self:capability *;
>         dontaudit domain self:capability sys_module;
> and self rules are expanded (the kernel has no notion of self), so we
> end up with:
>         dontaudit su self:capability *;
>         dontaudit su self:capability sys_module;
>
> We have never encountered this situation before because there are no
> dontaudit A B:C *; rules in refpolicy; that's a corner case that only
> shows up in Android's su policy, and only because it is a permissive
> domain with no explicit allow rules (other than those picked up via
> macros that set up attributes or transitions).
>
> The fix was to replace the avdatump->data test with an explicit
> indication that the node was freshly allocated i.e. this is the first
> such rule.  I agree that it could be clearer, but I was going for the
> simplest, least invasive fix for now, both due to limited time and to
> ease back-porting.
>
> >>
> >> Or perhaps a mechanism to actual set the data on allocation, this way
> the logic is
> >> Just &=.
>
> _______________________________________________
> Selinux mailing list
> Selinux@tycho.nsa.gov
> To unsubscribe, send email to selinux-le...@tycho.nsa.gov.
> To get help, send an email containing "help" to
> selinux-requ...@tycho.nsa.gov.
>
_______________________________________________
Selinux mailing list
Selinux@tycho.nsa.gov
To unsubscribe, send email to selinux-le...@tycho.nsa.gov.
To get help, send an email containing "help" to selinux-requ...@tycho.nsa.gov.

Reply via email to