On Fri, May 29, 2020 at 11:35 AM James Carter <jwcart2@xxxxxxxxx> wrote:
>
> On Fri, May 29, 2020 at 10:57 AM Stephen Smalley
> <stephen.smalley.work@xxxxxxxxx> wrote:
> >
> > On Thu, May 28, 2020 at 2:41 PM James Carter <jwcart2@xxxxxxxxx> wrote:
> > >
> > > The comparison function, portcon_data_cmp(), only made use of the
> > > protocol to put tcp before udp, dccp, and sctp. Rules that have
> > > the same port range, but with different protocols would be considered
> > > equal unless one of the protocols was tcp. When generating a CIL or
> > > conf source policy from a binary or using the "-S" option in
> > > checkpolicy the non-tcp portcon rules with the same port range would
> > > not be consistently sorted.
> > >
> > > Changed portcon_data_cmp() to sort portcon rules like the CIL function
> > > cil_post_portcon_compare().
> > >
> > > Reported-by: Stephen Smalley <stephen.smalley.work@xxxxxxxxx>
> > > Signed-off-by: James Carter <jwcart2@xxxxxxxxx>
> >
> > Any idea why it used that logic previously? And how does this compare
> > with sepol_port_compare/compare2() used by libsemanage?
>
> It originally followed the logic in CIL. I updated the CIL logic in
> 2018 (see commit 4ba19b541 ("libsepol/cil: Improve processing of
> context rules"), but failed to update the logic in kernel_to_common.
>
> The logic is similar, but slightly different. The logic in CIL and in
> kernel_to_common puts smaller port ranges before larger ones, but
> sepol_port_compare/compare2() do not take into account the port range.
> Other than that they are the same (with this patch). I am not sure
> where the CIL ordering logic came from, Steve Lawrence might remember.
>
> Jim
>
> > Regardless,
> > Acked-by: Stephen Smalley <stephen.smalley.work@xxxxxxxxx>
Applied.
