Re: [PATCH] libsepol: support policy modules when roletrans rules not supported

[Joshua Brindle <method@manicmethod.com>]

Eric Paris wrote:
> On Thu, 2011-04-14 at 09:58 -0400, Joshua Brindle wrote:
>> Eric Paris wrote:
>>> So I'm questioning the correctness of the range_transition and
>>> role_transition rules in libsepol.  My main problem is that libsepol
>>> defines SECCLASS_* at all.  Right now if the policy reads in one of
>>> these rules types without a tclass it will set SECCLASS_PROCESS in the
>>> tclasses bitmap.  But we never had any that would declare what the
>>> means.  At link time when we have to map "process" in a module to
>>> "process" in the base policy.  But if the module didn't require
>>> "process" it won't have the mapping.  So the fact that we set the
>>> SECCLASS_PROCESS bit could cause it to get mapped to random crap (or
>>> nothing at all)  Right?
>>>
>>> I know it's ugly but I think we need to do a couple of things.  #1 on
>>> that list is get SECCLASS_* out of libsepol altogether.  Those are
>>> COMPLETELY a construct of policy.  Not libsepol.  After we remove all
>>> of those we need to change the logic of everything that uses them to
>>> instead make sure that the "process" class exists in it's definitions
>>> and if not declare it.  Then set the bitmap for that new object.
>>>
>>> Am I not understanding something about how using SECCLASS_PROCESS
>>> could ever be a good idea?
>> It isn't the first time we've had hardcoded symbols that have to be mapped in
>> the code. See OBJECT_R_VAL as an example.
>>
>> It is a bit wonky though, suppose a type_transition rule were in a XenSE policy,
>> I don't think they have a process object class.
>
> So what it sounds like is that I probably want to look up the "process"
> class every time I would have used SECCLASS_PROCESS and if I don't find
> it, create it, and then look it up.  In this manor a policy which
> doesn't have process at all wouldn't have it forcibly jammed upon it
> (like we do in roles_init for OBJECT_R_VAL) and we wouldn't be mapping
> rules to garbage.  Sound right/ok to others?
>

It isn't the most elegant but there is precedence. I'm fine with it.

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.