SELinux policy module packages
 

Hi hardened-folks

Gentoo Hardened aims to follow the Tresys reference policy closely for the
SELinux policy modules / packages and puts all non-base policies in the
sec-policy/selinux-* packages. We already had a few hints on
#gentoo-hardened about the naming conventions used for those packages.

Naming conventions might seem silly to discuss, but they can make life
difficult in the future so it's better to tackle this before we go to a
stable set of SELinux policies. There are various options available, but let
me first give some information on the issue...

** Naming Collisions, Categories and More...

Well, as you are probably all aware, Gentoo might have naming collisions
when one doesn't provide the category (think app-admin/analog versus
app-emacs/analog). For regular packages, we ask users to provide the category
as well. However, for SELinux policy packages, there's only a single category
currently (sec-policy/), so we might need to provide the necessary naming
conventions in the package names.

However, another problem arises. Some reference policy modules provide
policies for multiple Gentoo packages (think admin/bootloader, which offers
policies for LILO, GRUB, YaBoot and more). If we name our SELinux policy
package to the Gentoo package, what would the package be called then (in
this particular case, bootloader is part of the base policy so doesn't
require a separate sec-policy/ package).

And if that isn't enough, Tresys reference policy also uses categories
(admin, apps, kernel, roles, services and system) so they too might have
naming collisions if one would ignore the category. However, once that
occurs, there will be other issues as well, because the reference policy
sources might have categories, but SELinux doesn't, so the module name
itself would require adjustments (cfr. "semodule -l" output).

** SELinux policy module naming convention

So, how should we (Gentoo Hardened) name our SELinux packages to avoid above
collisions, but also to provide our developers with a consistent guideline
on how to call SELinux module packages?

My suggestion would be to name the packages according to the refpolicy
module name (as it is the source of the package anyhow) without category.
Collisions are unlikely to occur in the near future because SELinux has no
support for categories. In other words, if a collision would occur, the
reference policy would rename their modules (or name the new module
differently) anyhow, so we can easily follow suit.

I rather not follow Gentoo's package names. I know it might make it easier
to deduce which sec-policy/selinux-* packages need to be installed on a
system, but this is a temporary situation - in the long term, we want all
packages that have SELinux policies to have an optional (selinux) dependency
against their sec-policy/selinux-* package. The downside would be that we
need to either make duplicate packages for these tools that have policies
within the same module (think the bootloader case) or use a different naming
convention for those particular packages.

So, what are your thoughts on this?

Wkr,
Sven Vermeulen

SELinux policy module packages
 

On 02/12/2011 09:20 AM, Sven Vermeulen wrote:
> Hi hardened-folks
>
> Gentoo Hardened aims to follow the Tresys reference policy closely for the
> SELinux policy modules / packages and puts all non-base policies in the
> sec-policy/selinux-* packages. We already had a few hints on
> #gentoo-hardened about the naming conventions used for those packages.
>
> Naming conventions might seem silly to discuss, but they can make life
> difficult in the future so it's better to tackle this before we go to a
> stable set of SELinux policies. There are various options available, but let
> me first give some information on the issue...
>
> ** Naming Collisions, Categories and More...
>
> Well, as you are probably all aware, Gentoo might have naming collisions
> when one doesn't provide the category (think app-admin/analog versus
> app-emacs/analog). For regular packages, we ask users to provide the category
> as well. However, for SELinux policy packages, there's only a single category
> currently (sec-policy/), so we might need to provide the necessary naming
> conventions in the package names.
>
> However, another problem arises. Some reference policy modules provide
> policies for multiple Gentoo packages (think admin/bootloader, which offers
> policies for LILO, GRUB, YaBoot and more). If we name our SELinux policy
> package to the Gentoo package, what would the package be called then (in
> this particular case, bootloader is part of the base policy so doesn't
> require a separate sec-policy/ package).
>
> And if that isn't enough, Tresys reference policy also uses categories
> (admin, apps, kernel, roles, services and system) so they too might have
> naming collisions if one would ignore the category. However, once that
> occurs, there will be other issues as well, because the reference policy
> sources might have categories, but SELinux doesn't, so the module name
> itself would require adjustments (cfr. "semodule -l" output).
>
> ** SELinux policy module naming convention
>
> So, how should we (Gentoo Hardened) name our SELinux packages to avoid above
> collisions, but also to provide our developers with a consistent guideline
> on how to call SELinux module packages?
>
> My suggestion would be to name the packages according to the refpolicy
> module name (as it is the source of the package anyhow) without category.
> Collisions are unlikely to occur in the near future because SELinux has no
> support for categories. In other words, if a collision would occur, the
> reference policy would rename their modules (or name the new module
> differently) anyhow, so we can easily follow suit.
>
> I rather not follow Gentoo's package names. I know it might make it easier
> to deduce which sec-policy/selinux-* packages need to be installed on a
> system, but this is a temporary situation - in the long term, we want all
> packages that have SELinux policies to have an optional (selinux) dependency
> against their sec-policy/selinux-* package. The downside would be that we
> need to either make duplicate packages for these tools that have policies
> within the same module (think the bootloader case) or use a different naming
> convention for those particular packages.
>
> So, what are your thoughts on this?
>
> Wkr,
> Sven Vermeulen
>

Robbat2 brought the naming issue up and suggested the ${CAT}-${PN}
scheme, but you make a good point about the mapping being many-to-many
in general.

If we agree to this standard, how to we grandfather in the packages that
are already in sec-policy? Renaming packages is a pita and we should
avoid it if we can.

--
Anthony G. Basile, Ph.D.
Gentoo Developer

SELinux policy module packages
 

On Sat, Feb 12, 2011 at 02:03:40PM -0500, Anthony G. Basile wrote:
> Robbat2 brought the naming issue up and suggested the ${CAT}-${PN}
> scheme, but you make a good point about the mapping being many-to-many
> in general.
>
> If we agree to this standard, how to we grandfather in the packages that
> are already in sec-policy? Renaming packages is a pita and we should
> avoid it if we can.

In theory, when the SELinux state is appropriate for more production-like
use, the packages are being pulled in as a dependency and not as an
emergeable package (so not "emerge selinux-gnupg" but "emerge gnupg" should
pull in the selinux- package).

As such, I think we can have the older one(s) die as long as the
dependencies on the master packages are brought up to date.

I personally dislike packages like "sec-policy/selinux-app-crypt-gnupg" if
"sec-policy/selinux-gpg" works equally well (or better), but I haven't read
the discussion on this online (just heard from others about it). I also
don't mind if general consensus is not my preference as I think it is more
important that we set a rule/guideline for the developers to follow
strictly.

Wkr,
Sven Vermeulen

SELinux policy module packages
 

On 02/12/2011 08:20 AM, Sven Vermeulen wrote:

I rather not follow Gentoo's package names. I know it might make it easier
to deduce which sec-policy/selinux-* packages need to be installed on a
system, but this is a temporary situation - in the long term, we want all
packages that have SELinux policies to have an optional (selinux) dependency
against their sec-policy/selinux-* package. The downside would be that we
need to either make duplicate packages for these tools that have policies
within the same module (think the bootloader case) or use a different naming
convention for those particular packages.


TBH, I really see nothing wrong with the naming convention we are using
now, which (AFAIK) pretty much follows the upstream module naming
convention (which I think is what you are proposing). In all
probability, it seems rather unlikely that there will be multiple
selinux policy modules with the same file name, as the file name tends
to reflect either the module name or its functionality (depending on
what's included in the file), either of which will tend to constrain the
range of both possible and likely names.


I also am not following the argument about 'make duplicate packages'?
If a policy module ebuild can work for multiple different packages, that
is fine. We simply have an optional selinux dependency in each of the
application ebuilds on that same selinux module. If the module is
already installed then the dependency is already satisfied. If not,
then we pull it in. Or am I missing something?


I agree that the long-term goal should be to modify all packages that
need to have an selinux module such that they have an optional selinux
dependency.


As blueness has pointed out, renaming a bunch of packages is a PITA. I
really don't see that we get anything from doing so at this point,
except a bunch of pain.


Later,
Chris

SELinux policy module packages
 

On Sat, Feb 12, 2011 at 01:43:40PM -0600, Chris Richards wrote:
> TBH, I really see nothing wrong with the naming convention we are using
> now, which (AFAIK) pretty much follows the upstream module naming
> convention (which I think is what you are proposing).

Indeed; however I couldn't find a post or something that reflects that we
are indeed trying to following the upstream module naming. For instance, the
packages selinux-acpi (mod=apm), selinux-courier-imap (mod=courier),
selinux-cyrus-sasl (mod=sasl), selinux-desktop (various mods), selinux-ftpd
(mod=ftp), selinux-gnupg (mod=gpg) and more all don't follow this logic,
even though I see no reason why they don't (except for the selinux-desktop
one).

It looked/looks like those packages rather follow the Gentoo package names
instead of the SELinux module.

> I also am not following the argument about 'make duplicate packages'?
> If a policy module ebuild can work for multiple different packages, that
> is fine. We simply have an optional selinux dependency in each of the
> application ebuilds on that same selinux module. If the module is
> already installed then the dependency is already satisfied. If not,
> then we pull it in. Or am I missing something?

Actually, the argument is only valid if we would require our policy packages
to be named after the package. If we follow the reference policy module
names, the argument is void.

> As blueness has pointed out, renaming a bunch of packages is a PITA. I
> really don't see that we get anything from doing so at this point,
> except a bunch of pain.

Actually, I'm rather hoping that if everyone agrees on the guideline that
SELinux policy packages are called "selinux-<modname>" with <modname> being
the policy name used by the reference policy, that we can use that as well
in the Gentoo Hardened SELinux Policy document [1].

By doing so, future developers immediately know how Gentoo Hardened works
(it is documented, so they don't need to start pondering how to call the
policy package for module "foo").

Wkr,
Sven Vermeulen

[1] goo.gl/2U0Zr

SELinux policy module packages
 

On 02/12/2011 02:03 PM, Sven Vermeulen wrote:

Indeed; however I couldn't find a post or something that reflects that we
are indeed trying to following the upstream module naming. For instance, the
packages selinux-acpi (mod=apm), selinux-courier-imap (mod=courier),
selinux-cyrus-sasl (mod=sasl), selinux-desktop (various mods), selinux-ftpd
(mod=ftp), selinux-gnupg (mod=gpg) and more all don't follow this logic,
even though I see no reason why they don't (except for the selinux-desktop
one).

It looked/looks like those packages rather follow the Gentoo package names
instead of the SELinux module.
I rather suspect that, since PeBenito was basically the only one working
on that stuff, he probably named them according to what seemed
appropriate for that specific module. Obviously, with more of us
working on the project now we need a somewhat more formal declaration,
so it is quite appropriate to bring the subject up.

Actually, I'm rather hoping that if everyone agrees on the guideline that
SELinux policy packages are called "selinux-<modname>" with<modname> being
the policy name used by the reference policy, that we can use that as well
in the Gentoo Hardened SELinux Policy document [1].

+1

Later,
Chris

SELinux policy module packages
 

On Sat, Feb 12, 2011 at 02:25:29PM -0600, Chris Richards wrote:
> On 02/12/2011 02:03 PM, Sven Vermeulen wrote:
> > Actually, I'm rather hoping that if everyone agrees on the guideline that
> > SELinux policy packages are called "selinux-<modname>" with<modname> being
> > the policy name used by the reference policy, that we can use that as well
> > in the Gentoo Hardened SELinux Policy document [1].
>
> +1

Okay, with no further feedback received on this, I've added this to the
suggested Gentoo Hardened SELinux Policy document [1].

Wkr,
Sven Vermeulen

[1] goo.gl/2U0Zr

SELinux policy module packages
 

On 02/21/2011 04:57 PM, Sven Vermeulen wrote:
> On Sat, Feb 12, 2011 at 02:25:29PM -0600, Chris Richards wrote:
>> On 02/12/2011 02:03 PM, Sven Vermeulen wrote:
>>> Actually, I'm rather hoping that if everyone agrees on the guideline that
>>> SELinux policy packages are called "selinux-<modname>" with<modname> being
>>> the policy name used by the reference policy, that we can use that as well
>>> in the Gentoo Hardened SELinux Policy document [1].
>>
>> +1
>
> Okay, with no further feedback received on this, I've added this to the
> suggested Gentoo Hardened SELinux Policy document [1].
>
> Wkr,
> Sven Vermeulen
>
> [1] goo.gl/2U0Zr

I am in agreement, but I hesitate because moving packages is a pita. If
it can be done with minimal disruption, then lets move in that
direction. Do you know what current sec-policy/selinux-* are in violation?

--
Anthony G. Basile, Ph.D.
Gentoo Developer

SELinux policy module packages
 

On Mon, Feb 21, 2011 at 05:49:59PM -0500, Anthony G. Basile wrote:
> I am in agreement, but I hesitate because moving packages is a pita. If
> it can be done with minimal disruption, then lets move in that
> direction. Do you know what current sec-policy/selinux-* are in violation?

A quick check shows:
selinux-acpi (apm)
selinux-audio-entropyd (audioentropy)
selinux-courier-imap (courier)
selinux-cyrus-sasl (sasl)
selinux-desktop (xserver xfs mplayer mozilla java mono wine)
selinux-ftpd (ftp)
selinux-gnupg (gpg)
selinux-hal (hal dmidecode)
selinux-jabber-server (jabber)
selinux-nfs (rpc)
selinux-ucspi-tcp (ucspitcp)

The other 193 packages do follow this convention already.

I don't think we need to force a rename. We can just update the
packages that depend on them (there aren't many yet, so the work should be
limited) and let the old ones "die" (in a more ideal scenario, all
sec-policy/ packages are pulled in as dependencies except for the
selinux-base-policy one). Every time the parent packages are updated, we
update the old package as well to become "empty". The new package contains
a blocker on the old package which Portage hopefully resolves correctly (so
that we don't have a file collision on the /usr/share/selinux/*/*.pp files).

Or, in somewhat more schematic approach...

Phase 1 (as-is)
===============

app-crypt/gnupg-A dependson sec-policy/selinux-gnupg-X

Phase 2
=======

In one "commit": update gnupg (A->B), selinux-gnupg (X->Y), introduce
selinux-gpg. As a result, Portage will install selinux-gpg. The blocker
tells Portage that selinux-gnupg needs to be updated (towards the "empty"
package) first. For SELinux itself, this doesn't matter as the policy module
is loaded (even when it has disappeared from /usr/share/selinux/*/*.pp)

app-crypt/gnupg-B dependson sec-policy/selinux-gpg-1
sec-policy/selinux-gnupg-Y blocks !~sec-policy/selinux-gnupg-X

Phase 3 (fade-out)
==================

sec-policy/selinux-gnupg is removed from Portage tree.



BTW, the selinux-desktop one is a weird one and my suggestion would be to
purge it (it's not manageable).

Wkr,
Sven Vermeulen