From: dsugar@tresys.com (David Sugar)
Date: Tue, 5 Sep 2017 18:10:22 +0000
Subject: [refpolicy] Interface for systemd using SELinuxContext option
In-Reply-To: <20170905142429.GA22703@julius.enp8s0.d30>
References: <1B50C12ACFF4CB42B90D2581155DF50205B4B361@Exchange10.columbia.tresys.com>
	<20170905142429.GA22703@julius.enp8s0.d30>
Message-ID: <1B50C12ACFF4CB42B90D2581155DF50205B4C39E@Exchange10.columbia.tresys.com>
To: refpolicy@oss.tresys.com
List-Id: refpolicy.oss.tresys.com



> -----Original Message-----
> From: refpolicy-bounces at oss.tresys.com [mailto:refpolicy-
> bounces at oss.tresys.com] On Behalf Of Dominick Grift via refpolicy
> Sent: Tuesday, September 05, 2017 10:24 AM
> To: refpolicy at oss.tresys.com
> Subject: Re: [refpolicy] Interface for systemd using SELinuxContext
> option
> 
> On Tue, Sep 05, 2017 at 02:05:19PM +0000, David Sugar via refpolicy
> wrote:
> > We have a use case on a system where we have a systemd .service unit
> file that is using the SELinuxContext= [1] option  to specify a context
> for the service being started.  The same .service file
> (/lib/systemd/system/foo at .service) is used to start multiple instances
> of the same executable that are customized with a different drop-in
> .conf file for each.  The context is customized in
> /lib/systemd/system/foo at .service file (based on using
> SELinuxContext=system_u:system_r:foo_%i_t:s0)  [2]
> >
> > We then create /etc/systemd/system/foo at bar.service.d/bar.conf so the
> final running process is in the domain foo_bar_t
> >
> > We have created the following interface (in init.if) to meet our
> needs.  I don't think the interface name is acceptable (I'm open to
> suggestions) and would like to submit a patch for this based on comments
> from the list.  The interface is very much like init_domain except for
> the use of domain_transition_pattern rather than domtrans_pattern
> because the automatic transition doesn't work in this case.
> 
> Why not just make these normal init_daemon_domain() or
> init_system_domain()
> 
> The SELinuxContext= option automatically works for init_daemon_domain()
> init_system_domain()
> 

The interfaces init_daemon_domain and init_system_domain have parameters for both the domain and entrypoint.  But one cannot provide the same entrypoint multiple times (for different domains).

So init_daemon_domain(foo_bar_t,foo_exec_t) and init_daemon_domain(foo_baz_t,foo_exec_t) will cause a problem (because of the domtrans_pattern).

All I guess I could create fake types that just are not used and the problem goes away. 

So init_daemon_domain(foo_bar_t,foo_bar_exec_t) and init_daemon_domain(foo_baz_t,foo_baz_exec_t).  There would be setup such that foo_exec_t is still a valid entrypoint for those domains and maybe some other miscellaneous rules to get it to work.  

Is there something else I'm missing?

> >
> > ########################################
> > ## <summary>
> > ##	Create a domain which can be started by init.
> > ## </summary>
> > ## <param name="domain">
> > ##	<summary>
> > ##	Type to be used as a domain.
> > ##	</summary>
> > ## </param>
> > ## <param name="entry_point">
> > ##	<summary>
> > ##	Type of the program being executed when starting this domain.
> > ##	</summary>
> > ## </param>
> > #
> > interface(`init_manual_trans',`
> > 	gen_require(`
> > 		type init_t;
> > 		role system_r;
> > 	')
> >
> > 	domain_type($1)
> > 	domain_entry_file($1, $2)
> >
> > 	role system_r types $1;
> >
> > 	domain_transition_pattern(init_t, $2, $1)
> >
> > 	ifdef(`init_systemd',`
> > 		allow $1 init_t:unix_stream_socket { getattr read write
> ioctl };
> >
> > 		allow init_t $1:process2 { nnp_transition nosuid_transition
> };
> > 	')
> > ')
> >
> >
> > [1] The SELinuxContext option for systemd is explained
> https://www.freedesktop.org/software/systemd/man/systemd.exec.html
> > [2] The systemd %i (and other specifiers) along with drop-in files are
> explained
> https://www.freedesktop.org/software/systemd/man/systemd.unit.html
> >
> > Input is appreciated.
> > Dave Sugar
> > dsugar at tresys.com
> > _______________________________________________
> > refpolicy mailing list
> > refpolicy at oss.tresys.com
> > http://oss.tresys.com/mailman/listinfo/refpolicy
> 
> --
> Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8  02D5 3B6C 5F1D 2C7B 6B02
> https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5F1D2C7B6B02
> Dominick Grift