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. Although, I would suggest "allow TYPE self: file getattr;" which
I know that all domains allow.
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.
--
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.
