2020-01-16 14:39:08

by Burgener, Daniel

[permalink] [raw]
Subject: SELint

Hello,

We have created a tool a that I think people on this list may find very
useful as they do refpolicy related work. It's called SELint and does
static code analysis on refpolicy style SELinux policy. You can find
the tool on our git repo here:

https://github.com/TresysTechnology/selint

It currently has 13 checks for common policy issues, and we hope to add
more going forward.

I submitted a pull request to the refpolicy github this morning that
fixes some of the issues reported by the tool, and hope to continue
submitting more over the next few days.

-Daniel


2020-01-16 23:23:03

by jwcart2

[permalink] [raw]
Subject: Re: [Non-DoD Source] SELint

On 1/16/20 9:37 AM, Burgener, Daniel wrote:
> Hello,
>
> We have created a tool a that I think people on this list may find very
> useful as they do refpolicy related work. It's called SELint and does
> static code analysis on refpolicy style SELinux policy. You can find
> the tool on our git repo here:
>
> https://github.com/TresysTechnology/selint
>
> It currently has 13 checks for common policy issues, and we hope to add
> more going forward.
>
> I submitted a pull request to the refpolicy github this morning that
> fixes some of the issues reported by the tool, and hope to continue
> submitting more over the next few days.
>
> -Daniel
>

Interesting work. Some of the tests are similar to those in a tool I created in
2018, selpoltools (https://github.com/jwcart2/selpoltools), but I did not think
of doing a check for a potentially unescaped regex character. I like that your
tool is written in c and that you can disable individual checks with a command
line option.

A couple of comments (which you are probably aware of)
- You will need to teach your program about object_r at some point.

- I ran it on a Refpolicy source tree from earlier in the year and it complained
about system_u being a non-existent user in the fc files, even though it is
defined in users.

- I am a little bit confused by what the line out of order (C-001) wants. For
example, I get the following two warnings

ipsec.te: 118: (C): Line out of order. It is before line 124 that calls
an interface located in the kernel module. (C-001)
ipsec.te: 119: (C): Line out of order. It is before line 124 that is in a
different section. (This node is in the section for ipsec_mgmt_t rules and the
other is in the section for ipsec_t rules.) (C-001)

118 corecmd_shell_domtrans(ipsec_t, ipsec_mgmt_t)
119 allow ipsec_mgmt_t ipsec_t:fd use;
. . .
124 kernel_read_kernel_sysctls(ipsec_t)
125 kernel_rw_net_sysctls(ipsec_t)
126 kernel_* ...

I am guessing that it wants the ipsec_t rules before the ipsec_mgmt_t rules?
I wonder why there aren't similar warnings referring to lines 125-134 which also
refer to kernel interfaces. I am guessing that it recognizes line 124 as the
start of the ipsec_t section?


All in all, it looks promising.
Jim

--
James Carter <[email protected]>
National Security Agency