[refpolicy] [PATCH/RFC] Reintroduce httpd_user_content_type and httpd_user_script_exec_type attributes

[refpolicy] [PATCH/RFC] Reintroduce httpd_user_content_type and httpd_user_script_exec_type attributes

[Sven Vermeulen]

Hi all,

The httpd_user_content_type and httpd_user_script_exec_type attributes were
erroneously removed a while ago, but while trying to reintroduce them I did
notice that they were removed because there was no way for users to actually
use them (or I'm completely misreading the policy code).

Below a first attempt at the patch, which also introduces two interfaces:
apache_user_content_type() and apache_user_script_exec_type(), which assigns
the given types the attributes again.

However, when trying to find out if/when the Apache domain (httpd_t) should
be able to execute the httpd_user_script_exec_type-labeled files (and read
httpd_user_content_type-labeled files) I'm getting a bit lost and hopefully
you can give me some guidance...

Should I allow execute rights on httpd_user_script_exec_type if
httpd_enable_cgi (boolean) and httpd_enable_homedirs (boolean) is set? And
httpd_enable_homedirs (boolean) for reading httpd_user_content_type?

Wkr,
	Sven Vermeulen

diff --git a/apache.if b/apache.if
index 83e899c..aacf98e 100644
--- a/apache.if
+++ b/apache.if
@@ -124,6 +124,42 @@ template(`apache_content_template',`
 
 ########################################
 ## <summary>
+##	Mark the selected type as an apache user content type
+## </summary>
+## <param name="type">
+##	<summary>
+##	Type to mark as apache user content
+##	</summary>
+## </param>
+#
+interface(`apache_user_content_type',`
+	gen_require(`
+		attribute httpd_user_content_type;
+	')
+
+	typeattribute $1 httpd_user_content_type;
+')
+
+########################################
+## <summary>
+##	Mark the selected type as an apache user script exec type
+## </summary>
+## <param name="type">
+##	<summary>
+##	Type to mark as apache user script exec type
+##	</summary>
+## </param>
+#
+interface(`apache_user_script_exec_type',`
+	gen_require(`
+		attribute httpd_user_script_exec_type;
+	')
+
+	typeattribute $1 httpd_user_script_exec_type;
+')
+
+########################################
+## <summary>
 ##	Role access for apache.
 ## </summary>
 ## <param name="role">
@@ -1070,8 +1106,17 @@ interface(`apache_search_sys_scripts',`
 ## <rolecap/>
 #
 interface(`apache_manage_all_user_content',`
-	refpolicywarn(`$0($*) has been deprecated, use apache_manage_all_content() instead.')
-	apache_manage_all_content($1)
+	gen_require(`
+		attribute httpd_user_content_type, httpd_user_script_exec_type;
+	')
+
+	manage_dirs_pattern($1, httpd_user_content_type, httpd_user_content_type)
+	manage_files_pattern($1, httpd_user_content_type, httpd_user_content_type)
+	manage_lnk_files_pattern($1, httpd_user_content_type, httpd_user_content_type)
+
+	manage_dirs_pattern($1, httpd_user_script_exec_type, httpd_user_script_exec_type)
+	manage_files_pattern($1, httpd_user_script_exec_type, httpd_user_script_exec_type)
+	manage_lnk_files_pattern($1, httpd_user_script_exec_type, httpd_user_script_exec_type)
 ')
 
 ########################################
diff --git a/apache.te b/apache.te
index 1a82e29..9b95119 100644
--- a/apache.te
+++ b/apache.te
@@ -252,12 +252,14 @@ gen_tunable(httpd_use_gpg, false)
 gen_tunable(httpd_use_nfs, false)
 
 attribute httpdcontent;
+attribute httpd_user_content_type;
 attribute httpd_htaccess_type;
 
 # domains that can exec all scripts
 attribute httpd_exec_scripts;
 
 attribute httpd_script_exec_type;
+attribute httpd_user_script_exec_type;
 
 # all script domains
 attribute httpd_script_domains;
@@ -322,6 +324,8 @@ type httpd_tmpfs_t;
 files_tmpfs_file(httpd_tmpfs_t)
 
 apache_content_template(user)
+apache_user_content_type(httpd_user_content_t)
+apache_user_script_exec_type(httpd_user_script_exec_t)
 ubac_constrained(httpd_user_script_t)
 userdom_user_home_content(httpd_user_content_t)
 userdom_user_home_content(httpd_user_htaccess_t)

[refpolicy] [PATCH/RFC] Reintroduce httpd_user_content_type and httpd_user_script_exec_type attributes

[Dominick Grift]

On Mon, 2013-02-11 at 20:02 +0100, Sven Vermeulen wrote:
> Hi all,
> 
> The httpd_user_content_type and httpd_user_script_exec_type attributes were
> erroneously removed a while ago, but while trying to reintroduce them I did
> notice that they were removed because there was no way for users to actually
> use them (or I'm completely misreading the policy code).
> 
> Below a first attempt at the patch, which also introduces two interfaces:
> apache_user_content_type() and apache_user_script_exec_type(), which assigns
> the given types the attributes again.
> 
> However, when trying to find out if/when the Apache domain (httpd_t) should
> be able to execute the httpd_user_script_exec_type-labeled files (and read
> httpd_user_content_type-labeled files) I'm getting a bit lost and hopefully
> you can give me some guidance...
> 
> Should I allow execute rights on httpd_user_script_exec_type if
> httpd_enable_cgi (boolean) and httpd_enable_homedirs (boolean) is set? And
> httpd_enable_homedirs (boolean) for reading httpd_user_content_type?
> 
> Wkr,
> 	Sven Vermeulen
> 

I still do not understand the purpose of this. Is there some actual need
for this? I deprecated the interface because it was unused and i could
not see a convincing need for it to exist.

Can you enlighten me? What issue are you facing? Who, other than the
user needs to be able to manage user content/script dirs, files and
symlinks?

[refpolicy] [PATCH/RFC] Reintroduce httpd_user_content_type and httpd_user_script_exec_type attributes

[Sven Vermeulen]

On Mon, Feb 11, 2013 at 08:30:19PM +0100, Dominick Grift wrote:
> > The httpd_user_content_type and httpd_user_script_exec_type attributes were
> > erroneously removed a while ago, but while trying to reintroduce them I did
> > notice that they were removed because there was no way for users to actually
> > use them (or I'm completely misreading the policy code).
> 
> I still do not understand the purpose of this. Is there some actual need
> for this? I deprecated the interface because it was unused and i could
> not see a convincing need for it to exist.
> 
> Can you enlighten me? What issue are you facing? Who, other than the
> user needs to be able to manage user content/script dirs, files and
> symlinks?

I'll have to ask Christopher, I made this patch as a result of our previous
thread on this matter (where I initially changed a deprecated function to
reflect the removal of these types):

http://oss.tresys.com/pipermail/refpolicy/2013-January/006255.html

Wkr,
	Sven Vermeulen

[refpolicy] [PATCH/RFC] Reintroduce httpd_user_content_type and httpd_user_script_exec_type attributes

[Dominick Grift]

On Mon, 2013-02-11 at 20:33 +0100, Sven Vermeulen wrote:
> On Mon, Feb 11, 2013 at 08:30:19PM +0100, Dominick Grift wrote:
> > > The httpd_user_content_type and httpd_user_script_exec_type attributes were
> > > erroneously removed a while ago, but while trying to reintroduce them I did
> > > notice that they were removed because there was no way for users to actually
> > > use them (or I'm completely misreading the policy code).
> > 
> > I still do not understand the purpose of this. Is there some actual need
> > for this? I deprecated the interface because it was unused and i could
> > not see a convincing need for it to exist.
> > 
> > Can you enlighten me? What issue are you facing? Who, other than the
> > user needs to be able to manage user content/script dirs, files and
> > symlinks?
> 
> I'll have to ask Christopher, I made this patch as a result of our previous
> thread on this matter (where I initially changed a deprecated function to
> reflect the removal of these types):
> 
> http://oss.tresys.com/pipermail/refpolicy/2013-January/006255.html
> 
> Wkr,
> 	Sven Vermeulen


I read that thread and do you have a actual case where useradd creates
~/public_html?

I do not see a need for useradd to be able to create that

But even so then it still needs no access to httpd_user_content files
and symlinks or any httpd_user_script_exec_t content

Can you not just create a httpd_manage_user_content_dirs, with something
like the following:

userdom_rw_user_home_dirs($1)
allow $1 httpd_user_content_t:dir manage_dir_perms;
 

[refpolicy] [PATCH/RFC] Reintroduce httpd_user_content_type and httpd_user_script_exec_type attributes

[Dominick Grift]

On Mon, 2013-02-11 at 20:51 +0100, Dominick Grift wrote:
> On Mon, 2013-02-11 at 20:33 +0100, Sven Vermeulen wrote:
> > On Mon, Feb 11, 2013 at 08:30:19PM +0100, Dominick Grift wrote:
> > > > The httpd_user_content_type and httpd_user_script_exec_type attributes were
> > > > erroneously removed a while ago, but while trying to reintroduce them I did
> > > > notice that they were removed because there was no way for users to actually
> > > > use them (or I'm completely misreading the policy code).
> > > 
> > > I still do not understand the purpose of this. Is there some actual need
> > > for this? I deprecated the interface because it was unused and i could
> > > not see a convincing need for it to exist.
> > > 
> > > Can you enlighten me? What issue are you facing? Who, other than the
> > > user needs to be able to manage user content/script dirs, files and
> > > symlinks?
> > 
> > I'll have to ask Christopher, I made this patch as a result of our previous
> > thread on this matter (where I initially changed a deprecated function to
> > reflect the removal of these types):
> > 
> > http://oss.tresys.com/pipermail/refpolicy/2013-January/006255.html
> > 
> > Wkr,
> > 	Sven Vermeulen
> 
> 
> I read that thread and do you have a actual case where useradd creates
> ~/public_html?
> 
> I do not see a need for useradd to be able to create that
> 
> But even so then it still needs no access to httpd_user_content files
> and symlinks or any httpd_user_script_exec_t content
> 
> Can you not just create a httpd_manage_user_content_dirs, with something
> like the following:
> 
> userdom_rw_user_home_dirs($1)
> allow $1 httpd_user_content_t:dir manage_dir_perms;
>  
> 

There is no need for attributes here

user content is:

httpd_user_content_t
httpd_user_content_rw_t
httpd_user_content_ra_t
httpd_user_htaccess_t
httpd_user_script_exec_t

[refpolicy] [PATCH/RFC] Reintroduce httpd_user_content_type and httpd_user_script_exec_type attributes

[Dominick Grift]

On Mon, 2013-02-11 at 20:33 +0100, Sven Vermeulen wrote:
> On Mon, Feb 11, 2013 at 08:30:19PM +0100, Dominick Grift wrote:
> > > The httpd_user_content_type and httpd_user_script_exec_type attributes were
> > > erroneously removed a while ago, but while trying to reintroduce them I did
> > > notice that they were removed because there was no way for users to actually
> > > use them (or I'm completely misreading the policy code).
> > 
> > I still do not understand the purpose of this. Is there some actual need
> > for this? I deprecated the interface because it was unused and i could
> > not see a convincing need for it to exist.
> > 
> > Can you enlighten me? What issue are you facing? Who, other than the
> > user needs to be able to manage user content/script dirs, files and
> > symlinks?
> 
> I'll have to ask Christopher, I made this patch as a result of our previous
> thread on this matter (where I initially changed a deprecated function to
> reflect the removal of these types):
> 
> http://oss.tresys.com/pipermail/refpolicy/2013-January/006255.html
> 
> Wkr,
> 	Sven Vermeulen


Take a looks at why it did this:

> >> interface(`apache_manage_all_user_content',`
> >>         refpolicywarn(`$0($*) has been deprecated, use
apache_manage_all_content() instead.')
> >>         apache_manage_all_content($1)
> >> ')

any content was previously considered user content. This was wrong in my
view and so i did what i did i pointed it to apache_manage_all_content.

I know that is also not optimal:

so maybe change apache_manage_all_user_content() to:

manage_dirs_pattern($1, { httpd_user_content_t httpd_user_content_rw_t
httpd_user_content_ra_t httpd_user_script_exec_t },
{ httpd_user_content_t httpd_user_content_rw_t httpd_user_content_ra_t
httpd_user_script_exec_t })
manage_files_pattern($1, { httpd_user_content_t httpd_user_content_rw_t
httpd_user_content_ra_t httpd_user_script_exec_t
httpd_user_htaccess_t }, { httpd_user_content_t httpd_user_content_rw_t
httpd_user_content_ra_t httpd_user_script_exec_t
httpd_user_htaccess_t })
manage_lnk_files_pattern($1, { httpd_user_content_t
httpd_user_content_rw_t httpd_user_content_ra_t
httpd_user_script_exec_t }, { httpd_user_content_t
httpd_user_content_rw_t httpd_user_content_ra_t
httpd_user_script_exec_t })

[refpolicy] [PATCH/RFC] Reintroduce httpd_user_content_type and httpd_user_script_exec_type attributes

[Daniel J Walsh]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 02/11/2013 03:03 PM, Dominick Grift wrote:
> On Mon, 2013-02-11 at 20:33 +0100, Sven Vermeulen wrote:
>> On Mon, Feb 11, 2013 at 08:30:19PM +0100, Dominick Grift wrote:
>>>> The httpd_user_content_type and httpd_user_script_exec_type
>>>> attributes were erroneously removed a while ago, but while trying to
>>>> reintroduce them I did notice that they were removed because there
>>>> was no way for users to actually use them (or I'm completely
>>>> misreading the policy code).
>>> 
>>> I still do not understand the purpose of this. Is there some actual
>>> need for this? I deprecated the interface because it was unused and i
>>> could not see a convincing need for it to exist.
>>> 
>>> Can you enlighten me? What issue are you facing? Who, other than the 
>>> user needs to be able to manage user content/script dirs, files and 
>>> symlinks?
>> 
>> I'll have to ask Christopher, I made this patch as a result of our
>> previous thread on this matter (where I initially changed a deprecated
>> function to reflect the removal of these types):
>> 
>> http://oss.tresys.com/pipermail/refpolicy/2013-January/006255.html
>> 
>> Wkr, Sven Vermeulen
> 
> 
> Take a looks at why it did this:
> 
>>>> interface(`apache_manage_all_user_content',` refpolicywarn(`$0($*)
>>>> has been deprecated, use
> apache_manage_all_content() instead.')
>>>> apache_manage_all_content($1) ')
> 
> any content was previously considered user content. This was wrong in my 
> view and so i did what i did i pointed it to apache_manage_all_content.
> 
> I know that is also not optimal:
> 
> so maybe change apache_manage_all_user_content() to:
> 
> manage_dirs_pattern($1, { httpd_user_content_t httpd_user_content_rw_t 
> httpd_user_content_ra_t httpd_user_script_exec_t }, { httpd_user_content_t
> httpd_user_content_rw_t httpd_user_content_ra_t httpd_user_script_exec_t
> }) manage_files_pattern($1, { httpd_user_content_t httpd_user_content_rw_t 
> httpd_user_content_ra_t httpd_user_script_exec_t httpd_user_htaccess_t }, {
> httpd_user_content_t httpd_user_content_rw_t httpd_user_content_ra_t
> httpd_user_script_exec_t httpd_user_htaccess_t }) 
> manage_lnk_files_pattern($1, { httpd_user_content_t httpd_user_content_rw_t
> httpd_user_content_ra_t httpd_user_script_exec_t }, { httpd_user_content_t 
> httpd_user_content_rw_t httpd_user_content_ra_t httpd_user_script_exec_t
> })
> 
> 
> _______________________________________________ refpolicy mailing list 
> refpolicy at oss.tresys.com http://oss.tresys.com/mailman/listinfo/refpolicy
> 

mkdir /etc/skel/public_html

useradd dwalsh

Will create /home/dwalsh/public_html

I believe.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.13 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEARECAAYFAlEZcjEACgkQrlYvE4MpobMrCgCgxyl1S95Ge0Zca+Nosx9X04L3
R3kAoMO8arzP785N31vaSHiI2ub0p4rp
=2Sae
-----END PGP SIGNATURE-----