Mailing List Archive

On Sun, Jul 12, 2015 at 04:46:03PM -0700, S. Lockwood-Childs wrote:
> I'd appreciate feedback on a blog-style article[1] talking about
> how CIL is going to improve SELinux policy maintenance, and in
> particular, the last section where I try to point out how good Gentoo
> is for experimenting with SELinux technologies. The article is
> maintained as an rst file in github[2], so corrections/additions
> could be submitted as a pull request if desired (though plain old
> mailing list replies are equally welcome).
>
> [1] http://vctlabs.com/posts/2015/Jul/12/selinux_cil/
> [2] https://github.com/VCTLabs/vct-web/blob/master/content/articles/selinux_cil.rst

Hi,

Overall a good article. One thing which I would also point out together
with the move to CIL is that there is now no "base" module. In the 2.3
and earlier userlands, all the important things were in "base.pp" and
then other things were added separately as modules. One of the reasons
why modifying ports works in the 2.4 userland is that there is no more
base, it is treated just like any other module now so the limitations of
eg ports must be in base no longer apply.

Secondly, related to "poor support for preserving local changes across
system updates". The tools now have the concept of priority so users can
easy completely replace a distro-provided module at a higher priority
(semodule -X 900 -i foo.pp). I haven't (yet) updated our selinux eclass
to install at a lower priority but will hopefully do that soon.

Not sure if you are aware of it, but there is also a project to write a
direct refpol -> cil compiler without going via .pp[1]. It looks like it
has stagnated for a while but it will hopefully make the generated cil
files a little less ugly than they currently are.
[1]: https://bitbucket.org/jwcarter/fpp.git

-- Jason

On Mon, Jul 13, 2015 at 1:31 PM, Jason Zaman <perfinion@gentoo.org> wrote:
> Overall a good article. One thing which I would also point out together
> with the move to CIL is that there is now no "base" module. In the 2.3
> and earlier userlands, all the important things were in "base.pp" and
> then other things were added separately as modules. One of the reasons
> why modifying ports works in the 2.4 userland is that there is no more
> base, it is treated just like any other module now so the limitations of
> eg ports must be in base no longer apply.

I'd be careful with the "no base". This heavily depends on how the
userland utilities will work with the CIL, which isn't fully clarified
yet.

> Secondly, related to "poor support for preserving local changes across
> system updates". The tools now have the concept of priority so users can
> easy completely replace a distro-provided module at a higher priority
> (semodule -X 900 -i foo.pp). I haven't (yet) updated our selinux eclass
> to install at a lower priority but will hopefully do that soon.

We work with the default 400 (100 is for the migrated modules). Do you
see a reason why we have to explicitly support a particular priority
in our eclass?

Wkr,
Sven Vermeulen

On Mon, Jul 13, 2015 at 03:02:55PM +0200, Sven Vermeulen wrote:
> On Mon, Jul 13, 2015 at 1:31 PM, Jason Zaman <perfinion@gentoo.org> wrote:
> > Secondly, related to "poor support for preserving local changes across
> > system updates". The tools now have the concept of priority so users can
> > easy completely replace a distro-provided module at a higher priority
> > (semodule -X 900 -i foo.pp). I haven't (yet) updated our selinux eclass
> > to install at a lower priority but will hopefully do that soon.
>
> We work with the default 400 (100 is for the migrated modules). Do you
> see a reason why we have to explicitly support a particular priority
> in our eclass?

Hmm. I thought the point of the priorities was that things the user has
done should be separate from what the distro provides. Either the distro
uses 400 and any overrides the user does in a higher level or we change
the eclass to use a lower level and the user gets the default. That way
its easier for the user to see what customizations have been made.

I was going to make a patch first then discuss but the basic idea was to
semodule -X 100 -i $MOD.pp then remove the module from level 400
afterwards if it exists. Thoughts? And if we do, do we want to use level
100? 200?

-- Jason

On Mon, Jul 13, 2015 at 3:51 PM, Jason Zaman <perfinion@gentoo.org> wrote:
> On Mon, Jul 13, 2015 at 03:02:55PM +0200, Sven Vermeulen wrote:
>> On Mon, Jul 13, 2015 at 1:31 PM, Jason Zaman <perfinion@gentoo.org> wrote:
>> > Secondly, related to "poor support for preserving local changes across
>> > system updates". The tools now have the concept of priority so users can
>> > easy completely replace a distro-provided module at a higher priority
>> > (semodule -X 900 -i foo.pp). I haven't (yet) updated our selinux eclass
>> > to install at a lower priority but will hopefully do that soon.
>>
>> We work with the default 400 (100 is for the migrated modules). Do you
>> see a reason why we have to explicitly support a particular priority
>> in our eclass?
>
> Hmm. I thought the point of the priorities was that things the user has
> done should be separate from what the distro provides. Either the distro
> uses 400 and any overrides the user does in a higher level or we change
> the eclass to use a lower level and the user gets the default. That way
> its easier for the user to see what customizations have been made.
>
> I was going to make a patch first then discuss but the basic idea was to
> semodule -X 100 -i $MOD.pp then remove the module from level 400
> afterwards if it exists. Thoughts? And if we do, do we want to use level
> 100? 200?

I think that it is sufficient to inform users that they can override
modules by picking a level higher than 400. If we would use a lower
value ourselves, we should've done that before the 2.4 migration went
stable and with sufficient documentation support. And I'm personally
not convinced we should go that route anyway.

If we implement logic right now, then how would we make sure that this
logic is only executed once? You'd need to hack some logic in the
(already somewhat complex) eclass to only do this once (if
successfull). And to what benefit?

The priority stuff is nice, but I find that it is somewhat a feature
that was implemented "because it was easy" and not because it is well
thought through (sorry for whomever implemented it - nothing
personal). Policy developers and users who do some policy enhancements
(which is the scope of the exercise we're talking about) who want to
overrule an existing policy will want to still benefit from evolutions
in the interfaces that they call. But that isn't the case, because
interface updates require rebuilds of the policy (CIL *might* remove
this obstacle depending on the implementation).

In other words, if I overrule the xserver module with my own, and the
init_daemon_domain() interface is updated, then this update will not
be taken into account. Whereas within Gentoo, we do a full policy
update (revbump) to make sure that updates on the interfaces are taken
up.

The priority stuff makes more sense in a managed environment, for
instance where you do policy "upgrades" and validate if things still
work properly. If they don't, unload them again, otherwise unload the
previous versions of the modules. But this needs to be managed and
supported. Right now, I'm guessing 95% of our users still have their
old policy in the 100-range.

Remember the kdevtmpfs related patch I once suggested to the eclass?
[1] Its horrible code, and this one didn't have to deal with "just
doing this once".

[1] https://archives.gentoo.org/gentoo-hardened/message/08b8c81d79720857045d762bb8cdbf62

I think we should put our focus elsewhere. Module priorities are nice,
but are not the innovative solution that our users are waiting for.

Unlike some of the CIL promises that we still need to see land ;-)

Wkr,
Sven Vermeulen

On Mon, Jul 13, 2015 at 1:46 AM, S. Lockwood-Childs
<sjl@dent.vctlabs.com> wrote:
> I'd appreciate feedback on a blog-style article[1] talking about
> how CIL is going to improve SELinux policy maintenance, and in
> particular, the last section where I try to point out how good Gentoo
> is for experimenting with SELinux technologies. The article is
> maintained as an rst file in github[2], so corrections/additions
> could be submitted as a pull request if desired (though plain old
> mailing list replies are equally welcome).
>
> [1] http://vctlabs.com/posts/2015/Jul/12/selinux_cil/
> [2] https://github.com/VCTLabs/vct-web/blob/master/content/articles/selinux_cil.rst

It's always nice to see posts on SELinux and Gentoo.

Some points of attention though.

The commercial usage isn't hindered by the three bullet points you
mention (not that those bullet points are wrong). It's hindered
because the policy implementation that is currently used (and I don't
mean this demeaning towards the policy) focuses on fine-grained access
controls with a rigid almost peer-reviewed process for policy
enhancements, and is meant to be fully encompassing. Any commercial
product owner who wants to support his application in a
SELinux-enabled system would need to provide a policy that matches the
principles of this policy. Sadly, this is extremely difficult,
especially when the product can be used in a very broad manner. Try
creating a policy for an Oracle DB within one company and then reuse
it in another company.

Developing policies means to get (and expose!) insights in how a
product works (and also doesn't work). Although this information can
be retrieved from profiling the application, many companies do not
want to "fix" their product behaviour within a policy. Products
evolve, and policies should evolve with them, but most product
development does not hold any roles for security policy developments.

Hell, many product vendors don't even have a nice overview of the
firewall rules needed to get their product components to interact with
each other. Let alone a policy approach.

The third bullet in your overview (poor support for preserving local
changes) might need more explanation. Local changes can be semanage
changes, and can be policy changes. Locally made semanage changes can
be exported/imported using "semanage export" and "semanage import",
and policy changes - well, those will require a software management or
configuration management system anyway. Not even CIL would simplify
this.

Wkr,
Sven Vermeulen

Thanks both Jason and Sven for your feedback. I'll try for an update
taking it into account this weekend. Also, thanks for your ongoing work
towards keeping Gentoo SELinux support in good shape!

--SJLC