[DSE-Dev] Again about managing CIL modules in Debian

[Laurent Bigonville]

Le Tue, 03 Jun 2014 15:14:31 +0300,
Victor Porton <porton at narod.ru> a écrit :

> I disagree with the opinion that this issue should be set upstream.
> 
> Compare with Apache. In the upstream Apache AFAIK there are no such
> things as "sites available" and "sites enabled". This is a Debian
> invention.
> 
> I think the same principle should be applied to secilc package, that
> is we should invent our policy for Debian specifically.

Well I actually think this is precisely the reason why we should
coordinate with the other distributions and with upstream.

> It would NOT break ease of interoperating with other Linux
> distributives, because the basic logic (base policies and additional
> modules) is the same everywhere. The things which may differ are just
> details.

These are indeed implementation details, but if we are shipping
scripts, we might have to carry patches for quite some time if upstream
is proposing something else.

Like Mika said, we should talk to upstream and see what is the future
they are foreseeing for cil policies.

Refpolicy upstream (<refpolicy at oss.tresys.com>) and selinux upstream
(<selinux at tycho.nsa.gov>) have both dedicated mailing list if you want
to reach them.

Cheers,

Laurent Bigonville

> 03.06.2014, 12:07, "Mika Pflüger" <mika at mikapflueger.de>:
> > Hi Victor,
> >
> > Victor Porton <porton at narod.ru> wrote:
> >>  I have said in this list that we have plenty of time to decide on
> >>  this issue, because upstream cilcilc is not yet ready for
> >> production use. But this does not mean that we should refrain from
> >> solving this issue. Why nobody answers?
> >
> > Sorry that I took so long to reply, I'm quite busy with other
> > stuff. /-:
> >>  I remind my proposal:
> >>  Split collections of CIL modules into two categories:
> >>
> >>  1. Base policies. At a moment of time only one of base policies
> >> may be active.
> >>
> >>  2. Additional modules. These can be added to one or several base
> >>  policies to implement specific universal tasks, such as sandboxing
> >>  (which should work irrespectively of which base policy is
> >> installed).
> >>
> >>  It is unclear how could we specify which additional modules are
> >>  compatible with which base policies. The simplest way to resolve
> >> this issue is to put the burden to decide which additional modules
> >> to enable and which to disable to the system administrator. Or we
> >> can invent something more sophisticated, such as an additional
> >> field in package description file or whatever.
> >>
> >>  Please discuss. I hope we will have stable upstream secilc soon
> >> and we will need to solve how to manage it in Debian.
> >
> > I think the general policy regarding CIL modules should be solved
> > upstream (i.e. by the secilc developers; you could propose them your
> > policy), so that we have a common policy for all linux
> > distributions and can benefit from each other's work. As long as
> > such an upstream policy does not exist, it would be premature for
> > debian to ship an own framework in /usr/(s)bin . I think we should
> > put some example scripts for system administrators
> > into /usr/share/doc/secilc/examples and explain them
> > in /usr/share/doc/secilc/README.Debian , but we do not need to
> > define our own CIL module policy.
> >
> > So to sum up my proposal:
> > * Put CIL module installation scripts and documentation
> >   into /usr/share/doc/secilc/examples for the time being. I think
> > your proposed scripts look good for that.
> > * Work with secilc upstream, possibly refpolicy upstream and other
> >   distributions (mainly fedora and gentoo) on a policy for CIL
> > modules.
> > * As soon as we have an upstream CIL module policy, ship CIL module
> >   installation and support programs/scripts in /usr/(s)bin .
> >
> > Cheers,
> >
> > Mika