From: dominick.grift@gmail.com (Dominick Grift)
Date: Tue, 14 Jan 2014 12:24:24 +0100
Subject: [refpolicy] systemd policy
In-Reply-To: <52D449A2.5080809@redhat.com>
References: <5992094.YlEUt0BCZP@russell.coker.com.au>
	<20140112131841.71f6da37@fornost.bigon.be>
	<5347508.kSSh66cgIv@russell.coker.com.au> <52D401D3.5040900@redhat.com>
	<1389639753.20228.8.camel@x220.localdomain>
	<52D449A2.5080809@redhat.com>
Message-ID: <1389698664.28251.35.camel@x220.localdomain>
To: refpolicy@oss.tresys.com
List-Id: refpolicy.oss.tresys.com

On Mon, 2014-01-13 at 15:16 -0500, Daniel J Walsh wrote:
> On 01/13/2014 02:02 PM, Dominick Grift wrote:
> > On Mon, 2014-01-13 at 10:10 -0500, Daniel J Walsh wrote:
> > 
> >> I rely on Dominick and Miroslav to get Fedora changes/fixes upstream.
> >> 
> >> Could you guys take care of getting systemd policy upstream.
> >> 
> > 
> > We rely on Chris
> > 
> > I recently submitted a small patch just to get the ball rolling but it did
> > not get any reply.
> > 
> > Other than that, Fedora is also to blame to an extent.
> > 
> > It would help if Fedora also considers things, also for its own benefit.
> > 
> > For example:
> > 
> > Fedora recently remove the init_run_daemon(unconfined_t) from her policy,
> > while i submitted a solution here on this list that i believe is 
> > sustainable but it was ignore without any comments.
> > 
> > I know Fedora does not have to , or wants to support other init systems but
> > reference policy does not have that luxury. By going your own way, i 
> > believe you're shutting the door to alternative init systems in Fedora and
> > you decrease chances of getting stuff up streamed.
> > 
> > Now with every commit Fedora does i have to worry about this because i know
> > Fedora seems to not care about other scenarios
> > 
> > And then there is the issue that i am taking a bit of distance from the 
> > community. I have to focus on other things unfortunately, but ces't la vie
> > 
> > _______________________________________________
> >> refpolicy mailing list refpolicy at oss.tresys.com 
> >> http://oss.tresys.com/mailman/listinfo/refpolicy
> > 
> > 
> Well I would not say we don't care about other init systems, since we still
> need to support systemV init scripts.  I removed init_run_daemon(unconfined_t)
> because it was causing us problems with "Daemons" attempting to run as
> unconfined_u:system_r:unconfined_t:s0.  We are attempting to tighten security
> on confined domains being able to transition to unconfined domains.  Currently
> we allow unconfined domains to be entered by all file types.  We wanted to
> remove this since a confined domain that transitions to an unconfined domain.
> samba_t -> samba_unconfined_exec_t -> samba_unconfined_t, was only intended to
> happen on scripts labeled samba_unconfined_exec_t.  But we were not blocking
> the entrypoint, so potentially if samba was allowed to do
> setexeccon(samba_unconfined_t) it could execute any script to get to it.
> 
> After we turned off the entrypoint ability for all confined domains, then we
> saw this problem with unconfined_t.
> 
> My understanding of the auto transitions for initscripts was supposed to be
> 
> unconfined_r:unconfined_t @ *initrc_t -> system_r:initrc_t @httpd_exec_t ->
> system_r:httpd_t.
> 
> The interface we removed was causing
> 
> unconfined_r:unconfined_t @ httpd_exec_t -> system_r:unconfined_t and
> generating an entrypoint error.
> 
> I don't see why we want unconfined_r role changing to system_r just because it
> executed a daemon domain.
> 
> 

Let me try this another way:

Your solution "solves" the issue only for unconfined_t.

My solution: 1. fixes a broken interface, 2. "solves" the issue for
sysadm_t as well as for unconfined_t. 3. Does not break direct_initrc
(or at least should work with my other patches titled "make
direct_initrc apply to unconfined_t", if they are applied fully)