[refpolicy] [PATCH v3 0/3] Support read/append/manage functions for various httpd content

[refpolicy] [PATCH v3 0/3] Support read/append/manage functions for various httpd content

[Sven Vermeulen]

Within this patch set, we make the web content types as defined by the apache
module more generic in use so that other domains, who need to interact with
these types, can do so without getting too many privileges assigned (like with
apache_manage_all_content).

Since v2, the following changes have been incorporated:
- Use double comment for phpfpm's summary

Since v1, the following changes have been incorporated:
- Adding apache_search_all_content within the apache_append_all_ra_content_files
  interface
- Adding phpfpm_t domain as an example user for these interfaces

With thanks to Dominick Grift for his feedback.

[refpolicy] [PATCH v3 1/3] Support read/append/manage functions for various httpd content

[Sven Vermeulen]

Within the apache module, the apache_content_template() allows creation of
additional derived types for "apache web content". But it is actually being
used to label generic web content, and it creates additional types based on
the prefix.

When we want to support additional web servers (or parsers used by web
servers) that do not run within the apache-provided domains, they have a
hard time accessing the data. There is currently one interface available,
called "apache_manage_all_content" but that's a lot of privileges for a
parser that needs to read content.

In this patch, we create additional attributes (like httpd_ra_content and
httpd_rw_content) and define interfaces to manage the types that have these
attributes assigned.

Signed-off-by: Sven Vermeulen <sven.vermeulen@siphos.be>
---
 apache.if |  128 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++-
 1 files changed, 126 insertions(+), 2 deletions(-)

diff --git a/apache.if b/apache.if
index 6480167..a1d1905 100644
--- a/apache.if
+++ b/apache.if
@@ -16,6 +16,8 @@ template(`apache_content_template',`
 		attribute httpdcontent;
 		attribute httpd_exec_scripts;
 		attribute httpd_script_exec_type;
+		attribute httpd_rw_content;
+		attribute httpd_ra_content;
 		type httpd_t, httpd_suexec_t, httpd_log_t;
 	')
 	# allow write access to public file transfer
@@ -41,11 +43,11 @@ template(`apache_content_template',`
 	corecmd_shell_entry_type(httpd_$1_script_t)
 	domain_entry_file(httpd_$1_script_t, httpd_$1_script_exec_t)
 
-	type httpd_$1_rw_content_t, httpdcontent; # customizable
+	type httpd_$1_rw_content_t, httpdcontent, httpd_rw_content; # customizable
 	typealias httpd_$1_rw_content_t alias { httpd_$1_script_rw_t httpd_$1_content_rw_t };
 	files_type(httpd_$1_rw_content_t)
 
-	type httpd_$1_ra_content_t, httpdcontent; # customizable
+	type httpd_$1_ra_content_t, httpdcontent, httpd_ra_content; # customizable
 	typealias httpd_$1_ra_content_t alias { httpd_$1_script_ra_t httpd_$1_content_ra_t };
 	files_type(httpd_$1_ra_content_t)
 
@@ -448,6 +450,128 @@ interface(`apache_dontaudit_rw_tcp_sockets',`
 
 ########################################
 ## <summary>
+##	Read all appendable content.
+## </summary>
+## <param name="domain">
+##	<summary>
+##	Domain allowed access.
+##	</summary>
+## </param>
+## <rolecap/>
+#
+interface(`apache_read_all_ra_content',`
+	gen_require(`
+		attribute httpd_ra_content;
+	')
+
+	read_files_pattern($1, httpd_ra_content, httpd_ra_content)
+	read_lnk_files_pattern($1, httpd_ra_content, httpd_ra_content)
+')
+
+########################################
+## <summary>
+##	Append to all appendable web content files.
+## </summary>
+## <param name="domain">
+##	<summary>
+##	Domain allowed access.
+##	</summary>
+## </param>
+## <rolecap/>
+#
+interface(`apache_append_all_ra_content_files',`
+	gen_require(`
+		attribute httpd_ra_content;
+	')
+
+	apache_search_all_content($1)
+	append_files_pattern($1, httpd_ra_content, httpd_ra_content)
+')
+
+########################################
+## <summary>
+##	Read all read/write content.
+## </summary>
+## <param name="domain">
+##	<summary>
+##	Domain allowed access.
+##	</summary>
+## </param>
+## <rolecap/>
+#
+interface(`apache_read_all_rw_content',`
+	gen_require(`
+		attribute httpd_rw_content;
+	')
+
+	read_files_pattern($1, httpd_rw_content, httpd_rw_content)
+	read_lnk_files_pattern($1, httpd_rw_content, httpd_rw_content)
+')
+
+########################################
+## <summary>
+##	Manage all read/write content.
+## </summary>
+## <param name="domain">
+##	<summary>
+##	Domain allowed access.
+##	</summary>
+## </param>
+## <rolecap/>
+#
+interface(`apache_manage_all_rw_content',`
+	gen_require(`
+		attribute httpd_rw_content;
+	')
+
+	manage_dirs_pattern($1, httpd_rw_content, httpd_rw_content)
+	manage_files_pattern($1, httpd_rw_content, httpd_rw_content)
+	manage_lnk_files_pattern($1, httpd_rw_content, httpd_rw_content)
+')
+
+########################################
+## <summary>
+##	Read all web content.
+## </summary>
+## <param name="domain">
+##	<summary>
+##	Domain allowed access.
+##	</summary>
+## </param>
+## <rolecap/>
+#
+interface(`apache_read_all_content',`
+	gen_require(`
+		attribute httpdcontent, httpd_script_exec_type;
+	')
+
+	read_files_pattern($1, httpdcontent, httpdcontent)
+	read_lnk_files_pattern($1, httpdcontent, httpdcontent)
+
+	read_files_pattern($1, httpd_script_exec_type, httpd_script_exec_type)
+	read_lnk_files_pattern($1, httpd_script_exec_type, httpd_script_exec_type)
+')
+
+########################################
+## <summary>
+##	Search all apache content.
+## </summary>
+## <param name="domain">
+##	<summary>
+##	Domain allowed access.
+##	</summary>
+## </param>
+#
+interface(`apache_search_all_content',`
+	gen_require(`
+		attribute httpdcontent;
+	')
+
+	allow $1 httpdcontent:dir search_dir_perms;
+')
+
+########################################
+## <summary>
 ##	Create, read, write, and delete all web content.
 ## </summary>
 ## <param name="domain">
-- 
1.7.3.4

[refpolicy] [PATCH v3 1/3] Support read/append/manage functions for various httpd content

[Christopher J. PeBenito]

On 06/24/12 07:08, Sven Vermeulen wrote:
> Within the apache module, the apache_content_template() allows creation of
> additional derived types for "apache web content". But it is actually being
> used to label generic web content, and it creates additional types based on
> the prefix.
> 
> When we want to support additional web servers (or parsers used by web
> servers) that do not run within the apache-provided domains, they have a
> hard time accessing the data. There is currently one interface available,
> called "apache_manage_all_content" but that's a lot of privileges for a
> parser that needs to read content.
> 
> In this patch, we create additional attributes (like httpd_ra_content and
> httpd_rw_content) and define interfaces to manage the types that have these
> attributes assigned.
> 
> Signed-off-by: Sven Vermeulen <sven.vermeulen@siphos.be>
> ---
>  apache.if |  128 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++-
>  1 files changed, 126 insertions(+), 2 deletions(-)
> 
> diff --git a/apache.if b/apache.if
> index 6480167..a1d1905 100644
> --- a/apache.if
> +++ b/apache.if
> @@ -16,6 +16,8 @@ template(`apache_content_template',`
>  		attribute httpdcontent;
>  		attribute httpd_exec_scripts;
>  		attribute httpd_script_exec_type;
> +		attribute httpd_rw_content;
> +		attribute httpd_ra_content;
>  		type httpd_t, httpd_suexec_t, httpd_log_t;
>  	')
>  	# allow write access to public file transfer
> @@ -41,11 +43,11 @@ template(`apache_content_template',`
>  	corecmd_shell_entry_type(httpd_$1_script_t)
>  	domain_entry_file(httpd_$1_script_t, httpd_$1_script_exec_t)
>  
> -	type httpd_$1_rw_content_t, httpdcontent; # customizable
> +	type httpd_$1_rw_content_t, httpdcontent, httpd_rw_content; # customizable
>  	typealias httpd_$1_rw_content_t alias { httpd_$1_script_rw_t httpd_$1_content_rw_t };
>  	files_type(httpd_$1_rw_content_t)
>  
> -	type httpd_$1_ra_content_t, httpdcontent; # customizable
> +	type httpd_$1_ra_content_t, httpdcontent, httpd_ra_content; # customizable
>  	typealias httpd_$1_ra_content_t alias { httpd_$1_script_ra_t httpd_$1_content_ra_t };
>  	files_type(httpd_$1_ra_content_t)
>  
> @@ -448,6 +450,128 @@ interface(`apache_dontaudit_rw_tcp_sockets',`
>  
>  ########################################
>  ## <summary>
> +##	Read all appendable content.
> +## </summary>
> +## <param name="domain">
> +##	<summary>
> +##	Domain allowed access.
> +##	</summary>
> +## </param>
> +## <rolecap/>
> +#
> +interface(`apache_read_all_ra_content',`
> +	gen_require(`
> +		attribute httpd_ra_content;
> +	')
> +
> +	read_files_pattern($1, httpd_ra_content, httpd_ra_content)
> +	read_lnk_files_pattern($1, httpd_ra_content, httpd_ra_content)
> +')
> +
> +########################################
> +## <summary>
> +##	Append to all appendable web content files.
> +## </summary>
> +## <param name="domain">
> +##	<summary>
> +##	Domain allowed access.
> +##	</summary>
> +## </param>
> +## <rolecap/>
> +#
> +interface(`apache_append_all_ra_content_files',`

Inconsistent interface naming.  I'm ok w/o the _files.

-- 
Chris PeBenito
Tresys Technology, LLC
www.tresys.com | oss.tresys.com

[refpolicy] [PATCH v3 1/3] Support read/append/manage functions for various httpd content

[Dominick Grift]

> > +########################################
> > +## <summary>
> > +##	Append to all appendable web content files.
> > +## </summary>
> > +## <param name="domain">
> > +##	<summary>
> > +##	Domain allowed access.
> > +##	</summary>
> > +## </param>
> > +## <rolecap/>
> > +#
> > +interface(`apache_append_all_ra_content_files',`
> 
> Inconsistent interface naming.  I'm ok w/o the _files.
> 

SwifT , i was the one who suggesting this change. I'm sorry about that.

I personally prefer this and do not agree with the inconsistency comment
but i guess others do not agree with me.

I guess next time i suggest a similar change feel free to ignore it.

[refpolicy] [PATCH v3 1/3] Support read/append/manage functions for various httpd content

[Christopher J. PeBenito]

On 06/26/12 09:57, Dominick Grift wrote:
> 
>>> +########################################
>>> +## <summary>
>>> +##	Append to all appendable web content files.
>>> +## </summary>
>>> +## <param name="domain">
>>> +##	<summary>
>>> +##	Domain allowed access.
>>> +##	</summary>
>>> +## </param>
>>> +## <rolecap/>
>>> +#
>>> +interface(`apache_append_all_ra_content_files',`
>>
>> Inconsistent interface naming.  I'm ok w/o the _files.
>>
> 
> SwifT , i was the one who suggesting this change. I'm sorry about that.
> 
> I personally prefer this and do not agree with the inconsistency comment
> but i guess others do not agree with me.
> 
> I guess next time i suggest a similar change feel free to ignore it.

Look closely at the naming of all the additions.  Thats what I meant by inconsistency.  They should have the same pattern.

-- 
Chris PeBenito
Tresys Technology, LLC
www.tresys.com | oss.tresys.com

[refpolicy] [PATCH v3 1/3] Support read/append/manage functions for various httpd content

[Sven Vermeulen]

On Tue, Jun 26, 2012 at 10:04:13AM -0400, Christopher J. PeBenito wrote:
> >>> +interface(`apache_append_all_ra_content_files',`
> >>
> >> Inconsistent interface naming.  I'm ok w/o the _files.
> >>
[...]
> Look closely at the naming of all the additions.  Thats what I meant by inconsistency.  They should have the same pattern.

Ok, it was indeed not consistent. 

May I take this opportunity to get some quick feedback on the interface
naming? From the naming convention [1] URL, it sais that the predicate (end
of the interface name) can be ommitted when it is clear what object is being
referenced.

[1] http://oss.tresys.com/projects/refpolicy/wiki/InterfaceNaming

Most actions against file object classes are possible for many of them
(file, symlink, socket, fifo, block, ...). Would it be a good interpretation
if "apache_append_all_ra_content" matches append rights for the entire
class family, whereas "apache_append_all_ra_content_files" is only for the file
class?

And if it does, is it OK to keep the implementation of said interface as
strict as possible (for as long as it is strictly needed) and enlarge (and
update other policies) when necessary?

For instance (since I know the above paragraph isn't clear): take a look at
"apache_read_all_ra_content", which was suggested with the following:

+interface(`apache_read_all_ra_content',`
+	gen_require(`
+		attribute httpd_ra_content;
+	')
+
+	read_files_pattern($1, httpd_ra_content, httpd_ra_content)
+	read_lnk_files_pattern($1, httpd_ra_content, httpd_ra_content)
+')

Although it can be split easily in "apache_read_all_ra_content_files" and
"apache_read_all_ra_content_symlinks", the notion of having a
"apache_read_all_ra_content" which does it just for files and symlinks might
in the future be 'enlarged' to support say fifo files.

In that case, the policy change might 'update' "apache_read_all_ra_content"
to add in read_fifo_files_pattern to it. Any policy that uses this interface
thus gets more privileges, but *knows* this as it used the more
course-grained interface, rather than coding the _files and _symlinks
interfaces in it.

I don't believe it would be a good idea to immediately "fill up" the
interface, like so:

+interface(`apache_read_all_ra_content',`
+	gen_require(`
+		attribute httpd_ra_content;
+	')
+
+	read_files_pattern($1, httpd_ra_content, httpd_ra_content)
+	read_lnk_files_pattern($1, httpd_ra_content, httpd_ra_content)
+	read_fifo_files_pattern($1, httpd_ra_content, httpd_ra_content)
+	read_sock_files_pattern($1, httpd_ra_content, httpd_ra_content)
+	read_blk_files_pattern($1, httpd_ra_content, httpd_ra_content)
+	read_chr_files_pattern($1, httpd_ra_content, httpd_ra_content)
+	list_dirs_pattern($1, httpd_ra_content, httpd_ra_content)
+')

but then policy editors must be aware that an interface might, in the
future, expand to become more course-grained (within the limits of the
interface).


And while I'm on it, what is the difference between a spec_domtrans and a
regular one? Is that only that the transition doesn't occur automatically
(i.e. the application has to be SELinux-aware to use it)?

Wkr,
	Sven Vermeulen

[refpolicy] [PATCH v3 1/3] Support read/append/manage functions for various httpd content

[Dominick Grift]

On Tue, 2012-06-26 at 22:38 +0200, Sven Vermeulen wrote:

> 
> And while I'm on it, what is the difference between a spec_domtrans and a
> regular one? Is that only that the transition doesn't occur automatically
> (i.e. the application has to be SELinux-aware to use it)?

A spec domtrans allows you to specify a target domain.

A normal domtrans takes a single parameter (source) domain.

A spec domtrans takes two parameters (source domain) target domain.

Example:

a myapp_domtrans:

########################################
## <summary>
##	Execute a domain transition to run myapp.
## </summary>
## <param name="domain">
## <summary>
##	Domain allowed to transition.
## </summary>
## </param>
#
interface(`myapp_domtrans',`
	gen_require(`
		type myapp_t, myapp_exec_t;
	')

	domtrans_pattern($1, myapp_exec_t, myapp_t)
')

A myapp_spec_domtrans:

########################################
## <summary>
##	Execute myapp executable files
##	in the specified domain.
## </summary>
## <param name="source_domain">
##	<summary>
##	Domain allowed to transition.
##	</summary>
## </param>
## <param name="target_domain">
##	<summary>
##	The type of the new process.
##	</summary>
## </param>
#
interface(`myapp_spec_domtrans',`
	gen_require(`
		type myapp_exec_t;
	')

	domtrans_pattern($1, myapp_exec_t, $2)
')

As far as i know it has no relationship whatsoever with setexeccon use
other than that it could be used together.

The spec refers to "domain transition from and to a specified domain"

my $0.02

> Wkr,
> 	Sven Vermeulen
> _______________________________________________
> refpolicy mailing list
> refpolicy at oss.tresys.com
> http://oss.tresys.com/mailman/listinfo/refpolicy

[refpolicy] [PATCH v3 1/3] Support read/append/manage functions for various httpd content

[Christopher J. PeBenito]

On 06/26/12 17:10, Dominick Grift wrote:
> On Tue, 2012-06-26 at 22:38 +0200, Sven Vermeulen wrote:
> 
>>
>> And while I'm on it, what is the difference between a spec_domtrans and a
>> regular one? Is that only that the transition doesn't occur automatically
>> (i.e. the application has to be SELinux-aware to use it)?
> 
> A spec domtrans allows you to specify a target domain.
> 
> A normal domtrans takes a single parameter (source) domain.
> 
> A spec domtrans takes two parameters (source domain) target domain.

Actually Sven is right on this one.  Its supposed to be the difference between an automatic domain transition (via type_transition) and specifying the transition in SELinux-aware code (via setexec).  See misc_patterns.spt.

Perhaps we should change "spec" to "setexec" to try to clarify.

-- 
Chris PeBenito
Tresys Technology, LLC
www.tresys.com | oss.tresys.com

[refpolicy] [PATCH v3 1/3] Support read/append/manage functions for various httpd content

[Christopher J. PeBenito]

On 06/26/12 16:38, Sven Vermeulen wrote:
> On Tue, Jun 26, 2012 at 10:04:13AM -0400, Christopher J. PeBenito wrote:
>>>>> +interface(`apache_append_all_ra_content_files',`
>>>>
>>>> Inconsistent interface naming.  I'm ok w/o the _files.
>>>>
> [...]
>> Look closely at the naming of all the additions.  Thats what I meant by inconsistency.  They should have the same pattern.
> 
> Ok, it was indeed not consistent. 
> 
> May I take this opportunity to get some quick feedback on the interface
> naming? From the naming convention [1] URL, it sais that the predicate (end
> of the interface name) can be ommitted when it is clear what object is being
> referenced.
> 
> [1] http://oss.tresys.com/projects/refpolicy/wiki/InterfaceNaming
> 
> Most actions against file object classes are possible for many of them
> (file, symlink, socket, fifo, block, ...). Would it be a good interpretation
> if "apache_append_all_ra_content" matches append rights for the entire
> class family, whereas "apache_append_all_ra_content_files" is only for the file
> class?

I would say apache_append_all_ra_content() works on all typical classes for the content, i.e. dir, file, lnk_file.  If you change it to apache_append_all_ra_content_files(), then you have ra access on files and search (or maybe list) on the dirs.

> And if it does, is it OK to keep the implementation of said interface as
> strict as possible (for as long as it is strictly needed) and enlarge (and
> update other policies) when necessary?

If you make the interface more strict, like apache_append_all_ra_content_files(), the implementation should be strict, so there can be tight least-privilege.  But if you use a more abstract apache_append_all_ra_content(), then we can be a little looser on the least-privilege. 

> I don't believe it would be a good idea to immediately "fill up" the
> interface, like so:
> 
> +interface(`apache_read_all_ra_content',`
> +	gen_require(`
> +		attribute httpd_ra_content;
> +	')
> +
> +	read_files_pattern($1, httpd_ra_content, httpd_ra_content)
> +	read_lnk_files_pattern($1, httpd_ra_content, httpd_ra_content)
> +	read_fifo_files_pattern($1, httpd_ra_content, httpd_ra_content)
> +	read_sock_files_pattern($1, httpd_ra_content, httpd_ra_content)
> +	read_blk_files_pattern($1, httpd_ra_content, httpd_ra_content)
> +	read_chr_files_pattern($1, httpd_ra_content, httpd_ra_content)
> +	list_dirs_pattern($1, httpd_ra_content, httpd_ra_content)
> +')
> 
> but then policy editors must be aware that an interface might, in the
> future, expand to become more course-grained (within the limits of the
> interface).

This goes back to knowing something about typical web content.  Definitely not for device nodes.  Probably not for fifo_file and sock_file, but we could be more flexible in adding it if it became necessary.

-- 
Chris PeBenito
Tresys Technology, LLC
www.tresys.com | oss.tresys.com

[refpolicy] [PATCH v3 2/3] Introducing phpfpm_t domain

[Sven Vermeulen]

The PHP FactCGI Process Manager is a standalone daemon capable of handling web
content and is specifically targeting high-traffic, dynamic sites.

Since it too is a web server, it needs access to the various http content types
as declared through the apache module.

Signed-off-by: Sven Vermeulen <sven.vermeulen@siphos.be>
---
 phpfpm.fc |    5 +++
 phpfpm.if |   30 +++++++++++++++++++++
 phpfpm.te |   86 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
 3 files changed, 121 insertions(+), 0 deletions(-)
 create mode 100644 phpfpm.fc
 create mode 100644 phpfpm.if
 create mode 100644 phpfpm.te

diff --git a/phpfpm.fc b/phpfpm.fc
new file mode 100644
index 0000000..536a5c7
--- /dev/null
+++ b/phpfpm.fc
@@ -0,0 +1,5 @@
+/usr/lib(64)?/php.*/bin/php-fpm		gen_context(system_u:object_r:phpfpm_exec_t,s0)
+
+/var/log/php-fpm.log			gen_context(system_u:object_r:phpfpm_log_t,s0)
+/var/run/php-fpm.pid			gen_context(system_u:object_r:phpfpm_var_run_t,s0)
+
diff --git a/phpfpm.if b/phpfpm.if
new file mode 100644
index 0000000..d9481d9
--- /dev/null
+++ b/phpfpm.if
@@ -0,0 +1,30 @@
+## <summary>PHP FastCGI Process Manager</summary>
+
+#################################################
+## <summary>
+## 	Administrate a phpfpm environment
+## </summary>
+## <param name="domain">
+## 	<summary>
+##	Domain allowed access
+##	</summary>
+## </param>
+# 
+interface(`phpfpm_admin',`
+	gen_require(`
+		type phpfpm_t;
+		type phpfpm_log_t, phpfpm_tmp_t, phpfpm_var_run_t;
+	')
+
+	allow $1 phpfpm_t:process { ptrace signal_perms };
+	ps_process_pattern($1, phpfpm_t)
+
+	logging_list_logs($1)
+	admin_pattern($1, phpfpm_log_t)
+
+	files_list_tmp($1)
+	admin_pattern($1, phpfpm_tmp_t)
+
+	files_list_pids($1)
+	admin_pattern($1, phpfpm_var_run_t)
+')
diff --git a/phpfpm.te b/phpfpm.te
new file mode 100644
index 0000000..2bd30d7
--- /dev/null
+++ b/phpfpm.te
@@ -0,0 +1,86 @@
+policy_module(phpfpm, 1.0)
+
+#######################################
+#
+# Declarations
+#
+
+type phpfpm_t;
+type phpfpm_exec_t;
+init_daemon_domain(phpfpm_t, phpfpm_exec_t)
+
+type phpfpm_tmp_t;
+files_tmp_file(phpfpm_tmp_t)
+
+type phpfpm_var_run_t;
+files_pid_file(phpfpm_var_run_t)
+
+type phpfpm_log_t;
+logging_log_file(phpfpm_log_t)
+
+#######################################
+#
+# Local policy
+#
+
+
+allow phpfpm_t self:process signal;
+allow phpfpm_t self:capability { setuid setgid kill };
+allow phpfpm_t self:tcp_socket rw_stream_socket_perms;
+allow phpfpm_t self:udp_socket connected_socket_perms;
+allow phpfpm_t self:unix_stream_socket accept;
+
+manage_files_pattern(phpfpm_t, phpfpm_log_t, phpfpm_log_t)
+logging_log_filetrans(phpfpm_t, phpfpm_log_t, file)
+
+manage_files_pattern(phpfpm_t, phpfpm_tmp_t, phpfpm_tmp_t)
+manage_dirs_pattern(phpfpm_t, phpfpm_tmp_t, phpfpm_tmp_t)
+files_tmp_filetrans(phpfpm_t, phpfpm_tmp_t, {file dir})
+
+manage_files_pattern(phpfpm_t, phpfpm_var_run_t, phpfpm_var_run_t)
+files_pid_filetrans(phpfpm_t, phpfpm_var_run_t, file)
+
+kernel_read_kernel_sysctls(phpfpm_t)
+
+corecmd_read_bin_symlinks(phpfpm_t)
+corecmd_search_bin(phpfpm_t)
+
+corenet_tcp_bind_all_unreserved_ports(phpfpm_t)
+corenet_tcp_bind_generic_node(phpfpm_t)
+corenet_tcp_bind_generic_port(phpfpm_t)
+# Comment was 'allow ldap connections' -> sysnet_use_ldap ?
+# Also, if it was optional because the application optionally does it, perhaps
+# introduce a tunable for this? phpfpm_allow_ldap?
+corenet_tcp_connect_ldap_port(phpfpm_t)
+
+dev_read_rand(phpfpm_t)
+dev_read_urand(phpfpm_t)
+
+files_read_etc_files(phpfpm_t)
+files_read_usr_files(phpfpm_t)
+files_search_var_lib(phpfpm_t)
+
+miscfiles_read_localization(phpfpm_t)
+
+sysnet_dns_name_resolve(phpfpm_t)
+sysnet_read_config(phpfpm_t)
+
+userdom_search_user_home_dirs(phpfpm_t)
+
+apache_append_all_ra_content(phpfpm_t)
+apache_manage_all_rw_content(phpfpm_t)
+apache_read_sys_content(phpfpm_t)
+apache_dontaudit_search_modules(phpfpm_t)
+
+optional_policy(`
+	mysql_tcp_connect(phpfpm_t)
+')
+
+optional_policy(`
+	postgresql_tcp_connect(phpfpm_t)
+')
+
+optional_policy(`
+	snmp_read_snmp_var_lib_files(phpfpm_t)
+')
+
-- 
1.7.3.4

[refpolicy] [PATCH v3 2/3] Introducing phpfpm_t domain

[Christopher J. PeBenito]

On 06/24/12 07:08, Sven Vermeulen wrote:
> The PHP FactCGI Process Manager is a standalone daemon capable of handling web
> content and is specifically targeting high-traffic, dynamic sites.
> 
> Since it too is a web server, it needs access to the various http content types
> as declared through the apache module.
> 
> Signed-off-by: Sven Vermeulen <sven.vermeulen@siphos.be>
> ---
>  phpfpm.fc |    5 +++
>  phpfpm.if |   30 +++++++++++++++++++++
>  phpfpm.te |   86 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>  3 files changed, 121 insertions(+), 0 deletions(-)
>  create mode 100644 phpfpm.fc
>  create mode 100644 phpfpm.if
>  create mode 100644 phpfpm.te
> 

> diff --git a/phpfpm.te b/phpfpm.te
> new file mode 100644
> index 0000000..2bd30d7
> --- /dev/null
> +++ b/phpfpm.te
> @@ -0,0 +1,86 @@
> +policy_module(phpfpm, 1.0)
> +
> +#######################################
> +#
> +# Declarations
> +#
> +
> +type phpfpm_t;
> +type phpfpm_exec_t;
> +init_daemon_domain(phpfpm_t, phpfpm_exec_t)
> +
> +type phpfpm_tmp_t;
> +files_tmp_file(phpfpm_tmp_t)
> +
> +type phpfpm_var_run_t;
> +files_pid_file(phpfpm_var_run_t)
> +
> +type phpfpm_log_t;
> +logging_log_file(phpfpm_log_t)
> +
> +#######################################
> +#
> +# Local policy
> +#
> +
> +
> +allow phpfpm_t self:process signal;
> +allow phpfpm_t self:capability { setuid setgid kill };
> +allow phpfpm_t self:tcp_socket rw_stream_socket_perms;
> +allow phpfpm_t self:udp_socket connected_socket_perms;
> +allow phpfpm_t self:unix_stream_socket accept;
> +
> +manage_files_pattern(phpfpm_t, phpfpm_log_t, phpfpm_log_t)
> +logging_log_filetrans(phpfpm_t, phpfpm_log_t, file)
> +
> +manage_files_pattern(phpfpm_t, phpfpm_tmp_t, phpfpm_tmp_t)
> +manage_dirs_pattern(phpfpm_t, phpfpm_tmp_t, phpfpm_tmp_t)
> +files_tmp_filetrans(phpfpm_t, phpfpm_tmp_t, {file dir})
> +
> +manage_files_pattern(phpfpm_t, phpfpm_var_run_t, phpfpm_var_run_t)
> +files_pid_filetrans(phpfpm_t, phpfpm_var_run_t, file)
> +
> +kernel_read_kernel_sysctls(phpfpm_t)
> +
> +corecmd_read_bin_symlinks(phpfpm_t)
> +corecmd_search_bin(phpfpm_t)
> +
> +corenet_tcp_bind_all_unreserved_ports(phpfpm_t)
> +corenet_tcp_bind_generic_node(phpfpm_t)
> +corenet_tcp_bind_generic_port(phpfpm_t)

This is a lot of binding.  This can't be narrowed further?

> +# Comment was 'allow ldap connections' -> sysnet_use_ldap ?
> +# Also, if it was optional because the application optionally does it, perhaps
> +# introduce a tunable for this? phpfpm_allow_ldap?
> +corenet_tcp_connect_ldap_port(phpfpm_t)

I'm undecided on this; either way can work.

-- 
Chris PeBenito
Tresys Technology, LLC
www.tresys.com | oss.tresys.com

[refpolicy] [PATCH v3 3/3] Allow sysadm_t to administer phpfpm environment

[Sven Vermeulen]

Signed-off-by: Sven Vermeulen <sven.vermeulen@siphos.be>
---
 policy/modules/roles/sysadm.te |    4 ++++
 1 files changed, 4 insertions(+), 0 deletions(-)

diff --git a/policy/modules/roles/sysadm.te b/policy/modules/roles/sysadm.te
index bd5a2ea..0c30596 100644
--- a/policy/modules/roles/sysadm.te
+++ b/policy/modules/roles/sysadm.te
@@ -260,6 +260,10 @@ optional_policy(`
 ')
 
 optional_policy(`
+	phpfpm_admin(sysadm_t)
+')
+
+optional_policy(`
 	portage_run(sysadm_t, sysadm_r)
 	portage_run_fetch(sysadm_t, sysadm_r)
 	portage_run_gcc_config(sysadm_t, sysadm_r)
-- 
1.7.3.4