Hi, In my policy I'm currently trying to make use ioctl whitelists. In some discussion with grift, that sparked https://lore.kernel.org/selinux/20200910092905.800461-1-dominick.grift@xxxxxxxxxxx/T/#t we came across various inconsistencies. First some observations about the current behavior: allowx rules requires a related allow rule to permit access: ; E.g. to allow access to ioctlcmd=0x5401 but no other ioctl (allow test.type test1.type (file (ioctl))) ; if this rule is removed access is forbidden (allowx test.type test1.type (ioctl file (0x5401))) dontauditx rules don't seem to work, they require an dontaudit rule but then every ioctl will be audited. auditallowx rules might have the same problem. neverallowx rules treat allow rules without related allowx rules as allowing access to all extended permissions: ; Will error (allow test.type test1.type (file (ioctl))) (neverallowx test.type test1.type (ioctl file (not (0x5401)))) ; Will compile fine (allow test.type test2.type (file (ioctl))) (allowx test.type test2.type (ioctl file (0x5401))) (neverallowx test.type test2.type (ioctl file (not (0x5401)))) Constraints are checked when the kernel checks for access to the normal permission (file (ioctl)). After looking at the CIL docs, it appears that the intended behavior is that a dontauditx / auditallowx rule will only apply to the extended permission it covers. ; Only access with ioctlcmd=0x5401 will be audited, but nothing else (auditallowx test.type test1.type (ioctl file (0x5401))) ; Only access with ioctlcmd=0x5401 will be hidden, but nothing else (dontauditx test.type test1.type (ioctl file (0x5401))) Of the behavior of allowx, dontauditx, auditallowx, neverallowx, I find that neverallowx has the most intuitive and useful behavior. Checking of constraints against (class (ioctl)) even when checking extended permissions is also very useful due to the nature of ioctls. The behavior of dontauditx and auditallowx appears to be broken making them useless. -- bauen1 https://dn42.bauen1.xyz/
