From: dsugar@tresys.com (David Sugar)
Date: Wed, 6 Sep 2017 15:39:29 +0000
Subject: [refpolicy] Interface for systemd using SELinuxContext option
In-Reply-To: <20170906065545.GA11086@julius.enp8s0.d30>
References: <1B50C12ACFF4CB42B90D2581155DF50205B4B361@Exchange10.columbia.tresys.com>
<20170905142429.GA22703@julius.enp8s0.d30>
<1B50C12ACFF4CB42B90D2581155DF50205B4C39E@Exchange10.columbia.tresys.com>
<20170905182950.GB22703@julius.enp8s0.d30>
<20170906065545.GA11086@julius.enp8s0.d30>
Message-ID: <1B50C12ACFF4CB42B90D2581155DF50205B4E4A7@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: Wednesday, September 06, 2017 2:56 AM
> To: refpolicy at oss.tresys.com
> Subject: Re: [refpolicy] Interface for systemd using SELinuxContext
> option
>
> On Tue, Sep 05, 2017 at 08:29:50PM +0200, Dominick Grift wrote:
> > On Tue, Sep 05, 2017 at 06:10:22PM +0000, David Sugar via refpolicy
> wrote:
> > >
> > >
> > > > -----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).
> >
> > You're referring to the type transition rule instead of the
> entrypoint?
> >
> > It is true that you can only have one automatic type transition rule,
> > but you can have multiple entrypoints
> >
> > >
> > > 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).
> >
> > unless you do something like domain_entry_file({foo_bar_t foo_baz_t},
> foo_exec_t}) i suppose?
> >
> > >
> > > 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.
> >
> > I think thats probably overdoing it?
> >
> > You can just allow both foo_bar_t as well as foo_baz_t to be entered
> > with foo_exec_t? (thats what i do at least)
> >
> > For example my php-fpm config:
> >
> > 1. my service unit for a php-fpm pool called wordpress (note that i
> use runcon instead of SELinuxContext because SELinuxContext= would also
> apply to the ExecReload=:
> >
> > [Unit]
> > Description=The PHP FastCGI Process Manager After=network.target
> >
> > [Service]
> > Type=notify
> > ExecStart=/usr/bin/runcon sys.id:sys.role:wordpress.subj:s0
> > /usr/sbin/php-fpm --nodaemonize --fpm-config=/etc/wordpress.conf
> > ExecReload=/bin/kill -USR2 PrivateTmp=true
> >
> > [Install]
> > WantedBy=multi-user.target
> >
> > 2. my wordpress module:
> >
> > (block wordpress
> > (blockinherit php_fpm.server_template) (blockinherit
> > web_content.content_template) (call readonly.read (subj)) (call
> > readwrite.map_files (subj)) (call readwrite.manage (subj)) (call
> > readwrite.tmpfs_obj_type_transition (subj)) (call
> > mysql.daemon.unix_stream_connect (subj)) (call
> > http.reserved_port.tcp_connect (subj)) (call
> > http.alt.unreserved_port.tcp_connect (subj)) (call
> > php_fpm.unreserved_port.tcp_bind (subj)) (call
> > smtp.hi_reserved_port.tcp_connect (subj)) (call
> > memcache.unreserved_port.tcp_connect (subj)) (call
> > systemd.system.daemon (subj cmd_file)) (block config (filecon
> > "/etc/wordpress\.conf" file config_file_context) (filecon
> > "/etc/wordpress\.conf\..*" file config_file_context)) (block readwrite
> > (filecon "/wordpress(/.*)?" any file_context)) (block runtime (filecon
> > "/run/wordpress(/.*)?" any runtime_file_context)) (block unit (filecon
> > "/usr/lib/systemd/system/[^/]*wordpress.*" file unit_file_context)
> > (blockinherit systemd.unit_file.obj_template) (call control
> > (service_adm_subj_type_attribute))
> > (call service_obj_type (unit_file))))
> >
> > 3. my php_fpm module:
> >
> > https://github.com/DefenSec/dssp2-standard/blob/master/policy/services
> > /php_fpm.cil
> >
> > The gist is that these domains can be entered both through private
> executable file types as well as the generic php_fpm executable file
> tyoe:
> >
> > So you indeed create to init_daemon_domain() but you allow both
> > domains to additionally be entered via the mail executable file type
> >
> > init_daemon_domain(domain1_t,domain1_exec_t)
> > init_daemon_domain(domain2_t,domain2_exec_t)
> > domain_entry_file({domain1_t domain2_t}, domain0_exec_t)
>
> the above isnt comprehensive, it should be this instead:
>
> init_daemon_domain(domain0_t,domain0_exec_t) # the generic daemon
> init_daemon_domain(domain1_t,domain1_exec_t) # a private daemon that can
> be entered through the generic daemon entry file
> init_daemon_domain(domain2_t,domain2_exec_t) # a private daemon that can
> be entered through the generic daemon entry file
> domain_entry_file({domain1_t domain2_t}, domain0_exec_t) # the private
> entries
>
Dominick thanks for your continued input. I was looking through refpolicy and found the interfaces using the "spec_domtrans_pattern", for example "init_spec_domtrans_script". So maybe something like "init_spec_daemon_domtrans" might be the correct name and it matches other patterns already used in refpolicy. This removes the need to have these unused domains and allow for systemd to do the proper transition.
Thoughts?
> >
> > So you arent actually using domain1_exec_t and domain2_exec_t in
> > practice
> >
> > >
> > > Is there something else I'm missing?
> >
> > >
> > > > >
> > > > > ########################################
> > > > > ##
> > > > > ## Create a domain which can be started by init.
> > > > > ##
> > > > > ##
> > > > > ##
> > > > > ## Type to be used as a domain.
> > > > > ##
> > > > > ##
> > > > > ##
> > > > > ##
> > > > > ## Type of the program being executed when starting this
> domain.
> > > > > ##
> > > > > ##
> > > > > #
> > > > > 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=0x3B6C5F1D2C7B
> > > > 6B02
> > > > Dominick Grift
> > > _______________________________________________
> > > 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
>
>
>
> --
> Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8 02D5 3B6C 5F1D 2C7B 6B02
> https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5F1D2C7B6B02
> Dominick Grift