On 09/02/2015 03:00 PM, Steve Lawrence wrote:
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.
OK. Don't worry about then.
Jim
--
James Carter <jwcart2@xxxxxxxxxxxxx>
National Security Agency
_______________________________________________
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.
