On 11/06/2014 09:12 AM, Steve Lawrence wrote:
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.
You're right. That is the better way of handling this.
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.
