On 11/04/2014 03:26 PM, James Carter wrote:
> On 11/04/2014 01:08 PM, Sven Vermeulen wrote:
>> On Mon, Nov 3, 2014 at 2:36 PM, Steve Lawrence <slawrence@xxxxxxxxxx>
>> wrote:
>>> It looks like you are correct, that unconfined_t is the problem. The
>>> unconfined_domain_noaudit interface has a gen_require on unconfined_t.
>>> However, CIL does not have a concept of gen_require. It just tries to
>>> resolve all statements inside an optional block, and if any of them fail
>>> then the optional is disabled. So in refpolicy, this interface depends
>>> on the unconfined_t type, even though it never uses it.
>>>
>>> One solution would create a tyepattribute that isn't used in any
>>> statements (and so won't become part of the final kernel policy) but
>>> that types that are gen_required are associated with. This should cause
>>> a failure of the optional without affecting anything alse. Kindof a
>>> hack, and it only works for types/roles since with have attributes for
>>> those, but probably the only way to mimic gen_require in CIL.
>>
>> Or perhaps inside the optional_policy() block I can define a rule
>> that, if unconfined was enabled, would be applicable anyway, like so:
>>
>> allow unconfined_t self:process signal;
>>
>> (assuming that that is a rule that is applied to unconfined_t - can't
>> verify it at this moment).
>>
>> As the unconfined_t isn't defined (unconfined module is not loaded)
>> then this part blocks as well.
>>
>> Of course, it's indeed a hack (similar to the typeattribute one).
>> Having a simple comment above it to make clear that it is to work
>> around this situation should make it clear.
>>
>
> Steve, how hard would it be to keep a list of the types that have been
> declared in the require block and check if they have been used directly?
> When you reached the end of the block any that have not been used could
> be placed in a rule like Sven suggests.
It probably wouldn't be too difficult to only add statements for types
that aren't used in the optional block. I just finished writing out
gen_requires for everything, regardless of if they are used or not, and
got some interesting numbers. With all the extra gen_require
typeattribute statements (~46000 of them), compiling CIL generated from
refpolicy pp's was actually faster (25 seconds vs 18 seconds). However,
it used about 13MB extra memory (129MB vs 142MB). Not really sure why
there was such a relatively dramatic decrease in compile time though.
I'll look into only adding symbols that are used in the optional and see
if there are noticeable differences, but I suspect performance would be
similar to how it before this change.
> Although, I would suggest "allow
> > TYPE self: file getattr;" which I know that all domains allow
A typeattribute statement would prevent us from having to worry about
this kind of stuff. I was thinking something like this:
In the base module, we would also define this:
(typeattribute cil_gen_require)
And then in optionals, we could have something like thi:
(option optional_foo
(typeattributeset cil_gen_require unconfined_t)
)
This doesn't change the policy at all (since cil_gen_require isn't used
in any statements, it won't be added to the binary), and a similar idea
can be used for roles as well, though I don't think there are any cases
were roles need to be 'cil_gen_required' in the converted CIL.
>>> Another option would be to change refpolicy so that the unconfined
>>> attributes are defined in the unconfined module rather than in
>>> kernel/domain/fs/etc, but maybe the way unconfined works would make the
>>> difficult. It's also not backwards compatible, so we'd probably still
>>> need the pp change anyway.
>>
>> This was actually what I was thinking about implementing on Gentoo to
>> "fix" this, but might take some time.
>>
>
> We do not need to fix any policy sources. This is an artifact of
> generating CIL from the pp files and is due to the fact that the
> interfaces have already been expanded. In a CIL policy that has been
> generated from the policy source, if the unconfined module is not loaded
> then the interface unconfined_domain_noaudit() does not exist, optional
> blocks will be disabled as required, and everything works.
>
> Speaking of require block issues. CIL generated from source policy has a
> problem that the CIL generated from pp files does not have. There are a
> handful of cases in the Fedora policy where require blocks in an
> interface are met because of an alias in another module. So these
> interfaces are expanded and appear in the policy even if the modules
> containing those interfaces are disabled. I currently have to manually
> add these interfaces.
>
> By the way, there is now a fedora branch for the cilpolicy on bitbucket:
> https://bitbucket.org/jwcarter/cilpolicy
>
>> Do you have an idea how we could find similar cases? I think the
>> unconfined ones are the only ones that use such a construction
>> (gen_require without directly using it) but I rather be certain.
>>
>
> I seem to remember a few instances in the past were there where typos in
> the require block which caused the block to always be removed. But I
> don't see that in the current policy.
>
Testing this, I actually did notice some optional blocks in refpolicy
that are always disabled due to non-existent types/typos. I'll report
those to the refpolicy list.
- 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.
