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)
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?
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
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;
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
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 })
-----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-----