From: dwalsh@redhat.com (Daniel J Walsh)
Date: Mon, 13 Jan 2014 15:16:34 -0500
Subject: [refpolicy] systemd policy
In-Reply-To: <1389639753.20228.8.camel@x220.localdomain>
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>
Message-ID: <52D449A2.5080809@redhat.com>
To: refpolicy@oss.tresys.com
List-Id: refpolicy.oss.tresys.com

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

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.


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEARECAAYFAlLUSaIACgkQrlYvE4MpobOCBACgxHyirOGSvJCOlALbYxkdoACh
9/EAn1J/2PYe3SOK9K641BwBxSUt+BGP
=dUCz
-----END PGP SIGNATURE-----