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.
########################################
## <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
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()
>
> ########################################
> ## <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
-------------- 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/412a6148/attachment.bin
> -----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
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?
>
> > >
> > > ########################################
> > > ## <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
> _______________________________________________
> 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
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=:
That is why SELinuxContext= is pretty useless. It applies not only to ExecStart=
Using runcon gives more flexibility because now to can make the transition only apply to ExecStart=
>
> [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?
>
> >
> > > >
> > > > ########################################
> > > > ## <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
> > _______________________________________________
> > 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
-------------- 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/93b3955a/attachment.bin
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
>
> So you arent actually using domain1_exec_t and domain2_exec_t in practice
>
> >
> > 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
> > _______________________________________________
> > 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
-------------- 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/20170906/daa80af7/attachment.bin
> -----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?
> >
> > >
> > > > >
> > > > > ########################################
> > > > > ## <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=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
On Wed, Sep 06, 2017 at 03:39:29PM +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: 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?
I suppose something like that could be an option but I just want to make it clear that the "domains" above arent unused.
Some domain executable file types might or might not be unused. You could also create a wrapper script around the generic daemon executable file and label that script with a private daemon executable file. The solution above give a little extra flexibility with a little extra cost.
All said and done though i think the solution is pretty elegant.
>
> > >
> > > So you arent actually using domain1_exec_t and domain2_exec_t in
> > > practice
> > >
> > > >
> > > > 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=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
> _______________________________________________
> 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/20170906/28af1fe8/attachment.bin