libselpol: Sort portcon rules consistently
diff mbox series

Message ID 20200528184056.105774-1-jwcart2@gmail.com
State Accepted
Headers show
Series
  • libselpol: Sort portcon rules consistently
Related show

Commit Message

James Carter May 28, 2020, 6:40 p.m. UTC
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@gmail.com>
Signed-off-by: James Carter <jwcart2@gmail.com>
---
 libsepol/src/kernel_to_common.c | 6 ++----
 1 file changed, 2 insertions(+), 4 deletions(-)

Comments

Stephen Smalley May 29, 2020, 2:57 p.m. UTC | #1
On Thu, May 28, 2020 at 2:41 PM James Carter <jwcart2@gmail.com> 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@gmail.com>
> Signed-off-by: James Carter <jwcart2@gmail.com>

Any idea why it used that logic previously?  And how does this compare
with sepol_port_compare/compare2() used by libsemanage?
Regardless,
Acked-by: Stephen Smalley <stephen.smalley.work@gmail.com>
James Carter May 29, 2020, 3:34 p.m. UTC | #2
On Fri, May 29, 2020 at 10:57 AM Stephen Smalley
<stephen.smalley.work@gmail.com> wrote:
>
> On Thu, May 28, 2020 at 2:41 PM James Carter <jwcart2@gmail.com> 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@gmail.com>
> > Signed-off-by: James Carter <jwcart2@gmail.com>
>
> 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@gmail.com>
Stephen Smalley June 2, 2020, 6:09 p.m. UTC | #3
On Fri, May 29, 2020 at 11:35 AM James Carter <jwcart2@gmail.com> wrote:
>
> On Fri, May 29, 2020 at 10:57 AM Stephen Smalley
> <stephen.smalley.work@gmail.com> wrote:
> >
> > On Thu, May 28, 2020 at 2:41 PM James Carter <jwcart2@gmail.com> 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@gmail.com>
> > > Signed-off-by: James Carter <jwcart2@gmail.com>
> >
> > 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@gmail.com>

Applied.

Patch
diff mbox series

diff --git a/libsepol/src/kernel_to_common.c b/libsepol/src/kernel_to_common.c
index 7b53c92f..a7453d3c 100644
--- a/libsepol/src/kernel_to_common.c
+++ b/libsepol/src/kernel_to_common.c
@@ -470,11 +470,9 @@  static int portcon_data_cmp(const void *a, const void *b)
 	rc = compare_ranges((*aa)->u.port.low_port, (*aa)->u.port.high_port,
 			    (*bb)->u.port.low_port, (*bb)->u.port.high_port);
 	if (rc == 0) {
-		if ((*aa)->u.port.protocol == (*bb)->u.port.protocol) {
-			rc = 0;
-		} else if ((*aa)->u.port.protocol == IPPROTO_TCP) {
+		if ((*aa)->u.port.protocol < (*bb)->u.port.protocol) {
 			rc = -1;
-		} else {
+		} else if ((*aa)->u.port.protocol > (*bb)->u.port.protocol) {
 			rc = 1;
 		}
 	}