On 09/02/2015 02:29 PM, James Carter wrote: > On 08/31/2015 08:53 AM, Steve Lawrence wrote: >> Add three new extended avrule statements with the following syntax: >> >> (allowx source_type target_type permissionx) >> (auditallowx source_type target_type permissionx) >> (dontauditx source_type target_type permissionx) >> >> source_type - type, typeattribute, or typealias >> target_type - type, typeattribute, typealias, or "self" keyword >> permissionx - named or anonymous permissionx statement, which has the >> syntax: >> >> (permissionx name (kind object expression)) >> > > Right now the permissionx name will be fully qualified, but we haven't > been doing that for identifiers that don't show up in the kernel policy > (classpermsets, named contexts, named ranges, named ip addrs, etc). So > it seems like you should exclude walking the permx symtab in > cil_fqn.c:__cil_fqn_qualify_blocks() like we do for these other symtabs. > Yep, this should be excluded from being fully qualified. Will fix. > The other question I have (and I am willing to put this off for now > because I don't know how much work it would be and I don't want to delay > this any longer than I already have) is whether it would be possible to > factor out the common code from checkpolicy's policy_define.c and cil's > cil_binary.c into some common functions in libsepol. > Unfortunately, there really isn't much in common between checkpolicy and CIL for extended avrules. checkpolicy uses an av_ioctl_range_list to keep track of the extended permissions. But since CIL supports more complex expressions and because of expression code reuse, it was easier to just use an ebitmap for evaluating/storing the extended permissions. Additionally, checkpolicy adds extended avrules to the list of avrule_t's, whereas CIL writes directly to the avtab. So they take pretty different approaches to solving the same problem. Really, the only thing they have in common, which was copied directly from policy_define.c, is the xperm_setrangebits function. Now that that function is in CIL/libsepol, it wouldn't be much effort to have checkpolicy use that one and remove the one in policy_define, but I think that's about all the refactoring we could do without maybe rewriting policy_define.c to use ebitmaps, and I'm not even sure that would remove very much code. - Steve _______________________________________________ Selinux mailing list Selinux@xxxxxxxxxxxxx To unsubscribe, send email to Selinux-leave@xxxxxxxxxxxxx. To get help, send an email containing "help" to Selinux-request@xxxxxxxxxxxxx.
