From: guido@trentalancia.net (Guido Trentalancia)
Date: Tue, 27 Dec 2016 23:54:58 +0100 (CET)
Subject: [refpolicy] [PATCH] init: run sysvinit without the dangerous
 unconfined_domain() call
In-Reply-To: <20161227233846.6ed0ebf0@gentp.lnet>
References: <1425370720.18751.1482877006863.JavaMail.open-xchange@popper10.register.it>
	<20161227233846.6ed0ebf0@gentp.lnet>
Message-ID: <1320659434.14525.1482879298312.JavaMail.open-xchange@popper05.register.it>
To: refpolicy@oss.tresys.com
List-Id: refpolicy.oss.tresys.com

Hello.

> On the 27th of December 2016 at 23.38 Luis Ressel <aranea@aixah.de> wrote:
> 
> 
> On Tue, 27 Dec 2016 23:16:46 +0100 (CET)
> Guido Trentalancia via refpolicy <refpolicy@oss.tresys.com> wrote:
> 
> > The aim of this patch is to start securing the init module so
> > that it can run in confined mode instead of in the most unsafe
> > unconfined mode.
> > 
> > At the moment it has been fully tested only with sysvinit.
> > 
> > Testing with other init daemons is needed before this is
> > released, so a "permissive" statement has been added in
> > order to log further needed permissions during this testing
> > phase (with systemd, upstart, and so on).
> > 
> > [...]
> >
> > +permissive init_t;
> 
> Please don't add that. Debugging statements such as this one should
> only be added to local policies, not to refpol's master branch. This
> statement would be a huge step backwards for everyone who isn't using
> the 'unconfined' module.

Ok, that's fine. Consider, I have completed testing it with sysvinit, so I
don't really need to debug anything.

It comes from the following recent advice that has been posted (I was
not even aware of the existence of such statement):

http://oss.tresys.com/pipermail/refpolicy/2016-December/008835.html

but, if it is more likely to cause problems, then I can create a new patch
which just dumps the dangerous call to unconfined_domain() and that's
the end of the story.

At the end, there must be a way out of it !

Regards,

Guido