From: dac.override@gmail.com (Dominick Grift)
Date: Tue, 5 Sep 2017 20:29:50 +0200
Subject: [refpolicy] Interface for systemd using SELinuxContext option
In-Reply-To: <1B50C12ACFF4CB42B90D2581155DF50205B4C39E@Exchange10.columbia.tresys.com>
References: <1B50C12ACFF4CB42B90D2581155DF50205B4B361@Exchange10.columbia.tresys.com>
<20170905142429.GA22703@julius.enp8s0.d30>
<1B50C12ACFF4CB42B90D2581155DF50205B4C39E@Exchange10.columbia.tresys.com>
Message-ID: <20170905182950.GB22703@julius.enp8s0.d30>
To: refpolicy@oss.tresys.com
List-Id: refpolicy.oss.tresys.com
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)
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=0x3B6C5F1D2C7B6B02
> > 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 659 bytes
Desc: not available
Url : http://oss.tresys.com/pipermail/refpolicy/attachments/20170905/afbc0db9/attachment-0001.bin