On Sun, Jul 31, 2022 at 10:07 PM <chris.lindee@xxxxxxxxx> wrote: > > Provide basic support for allowxperm, auditallowxperm, dontauditxperm and neverallowxperm. While I would prefer additional changes to help avoid the presence of magic numbers (e.g. a new macro, much like interface, but for recursively defining named xperm numbers), this patch set is sufficient for my and - hopefully - the majority of the community's needs. > > In particular, this change will keep /usr/bin/sepolgen-ifgen from spewing errors on the following policy every time selinux-policy-targeted gets updated: https://github.com/openzfs/zfs/pull/13271/files#diff-70b325e496b997b3c4a5a9f0aacee16343b82e07a8ed8220304ccb5f6504a582 > > Signed-off-by: Chris Lindee <chris.lindee+github@xxxxxxxxx> I have been looking at these two patches. Either there is a problem in them or there is a problem elsewhere. I can't tell. What I did to test them was to modify python/sepolgen/tests/test_refparser.py and add an interface to the interface_example string. This is what I added: define(`XPERM1',`0x9901') interface(`test_extended_permissions',` gen_require(` type device_t; ') allow $1 device_t:chr_file {ioctl}; allowxperm $1 device_t:chr_file ioctl 0x9910; dontauditxperm $1 device_t:chr_file ioctl 0x9911; auditallowxperm $1 device_t:chr_file ioctl 0x9912; neverallowxperm $1 device_t:chr_file ioctl 0x9913; allowxperm $1 device_t:chr_file ioctl { 0x9914 }; allowxperm $1 device_t:chr_file ioctl { 0x9915 0x9916 }; allowxperm $1 device_t:chr_file ioctl { 0x9917-0x9919 }; allowxperm $1 device_t:chr_file ioctl XPERM1; ') I then uncommented the "refpolicy.print_tree(h)" line in test_refparser.py. If I comment out the definition of XPERM1 and every xperm rule except the first four (the first allowxperm, dontauditxperm, auditallowxperm, and neverallowxperm) then the tree will printed out (although the rules are printed in reverse order). There is one weirdness in that the operation is printed out as "['ioctl']", but that is not due to anything in your patches. If any xperm rule with curly brackets is used or the definition of XPERM1, then the test_extended_permissions() interface is not printed out. It appears that parsing is abandoned as soon as one of those rules is encountered without an error being given. I literally typed random characters on the line after the definition of XPERM1 and no error was given. I don't see any obvious error in what you have done and it is very possible that the problem is elsewhere. The xperm stuff that is in sepolgen is strange. In access.py, xperms are stored in the AccessVector class as a dictionary with the operation being used as the key. In refpolicy.py, xperms have their own class, AVExtRule, with the operation being one field and the xperms being another field that is an XpermSet. At this point, your patches might remove the parsing errors, but that will only give a false sense that the xperms are actually being handled, when they are not. I am not sure where to go from here. I don't know the python code very well. Thanks, Jim > --- > python/sepolgen/src/sepolgen/refparser.py | 96 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++- > python/sepolgen/src/sepolgen/refpolicy.py | 18 ++++++++++++++++++ > 2 files changed, 113 insertions(+), 1 deletion(-) > >
