Re: Recently fixed neverallowx checks report (range 0x)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tue, Mar 8, 2022 at 6:21 AM bauen1 <j2468h@xxxxxxxxxxxxxx> wrote:
>
> Hello,
>
> The recently merged commit https://github.com/SELinuxProject/selinux/commit/71291385cf149a0316d5fa995d70641d3b1a0ab3 seems to have caused some neverallowx failures for my pipeline, they're correct.
>
> However during reporting a `(range 0x)` is printed, which does not seem right, please see the log of my CI that failed https://gitlab.com/bauen1/bauen1-policy/-/jobs/2174049183#L1653 the associated commit is 73b511c3050952527fff3050bb75774214691d24 of my policy.
>
> My policy can be build by invoking make, however this involves many modules.
> A smaller policy that still reproduces the bug can be build by creating a `policy/base/test.cil` file with:
> ```
> (type t2)
> (allow t2 .dev.dri.type (chr_file (ioctl)))
> (allowx t2 .dev.dri.type (ioctl chr_file (0x640D)))
> ```
> and `make validate-core` will build a policy with less modules that will still fail the neverallowx checks and print this message:
>
> neverallowx check failed at policy/base/permission_sets.cil:1002
>    (neverallowx all_types all_types (ioctl chr_file (not ((range 0x5401 0x540B) (range 0x540D 0x5410) 0x5413 0x5414 0x5420 (range 0x5429 0x5431) 0x5437 0x5441 0x5456 0x5457 (range 0x5601 0x5603) (range 0x5605 0x5608) 0x4B33 0x4B3A 0x4B3B 0x4B44 0x4B45 0x4B4B 0x4B4E 0x4B64 0x4B67 0x4B68 0x4B6A 0x4B72 0xFD00 (range 0xFD02 0xFD04) (range 0xFD06 0xFD0D) (range 0x9371 0x9374) 0x9376 0x937A (range 0x4501 0x4503) (range 0x4506 0x450A) 0x4518 0x4519 0x451B (range 0x4520 0x457F) 0x4593 0x45A0 (range 0x45C0 0x45FF) 0x690B 0x690D 0x6910 0x6911 (range 0x))
>      <root>
>      allowx at policy/base/test.cil:3
>        (allowx t2 dev.dri.type (ioctl chr_file (0x640D)))
>
> As far as I know the `(range 0x)` appears to be a bug.
>

The output is being truncated because the log buffer has a max size of
512 bytes and the extended permissions would need 1254 bytes. The
easiest fix is to add a message that the log has been truncated. Even
if MAX_LOG_SIZE is increased, you would still want to detect the case
where the message is too large for the buffer.

Thanks,
Jim


> Sadly I don't have the time right now to condense my policy down to a smaller reproducible example.
>
> --
> bauen1
> https://dn42.bauen1.xyz/




[Index of Archives]     [Selinux Refpolicy]     [Linux SGX]     [Fedora Users]     [Fedora Desktop]     [Yosemite Photos]     [Yosemite Camping]     [Yosemite Campsites]     [KDE Users]     [Gnome Users]

  Powered by Linux