From: sven.vermeulen@siphos.be (Sven Vermeulen)
To: refpolicy@oss.tresys.com
Subject: [refpolicy] [PATCH/RFC 1/1] Supporting read/append/manage functions for the various httpd_*_(ra_|rw_|)content
Date: Thu, 5 Jan 2012 20:40:40 +0100 [thread overview]
Message-ID: <20120105194040.GA29153@siphos.be> (raw)
In-Reply-To: <4F044282.4000304@tresys.com>
On Wed, Jan 04, 2012 at 07:13:54AM -0500, Christopher J. PeBenito wrote:
> > +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)
> > +')
>
> Also seems to have excessive perms.
How's that? It is not different from what we grant to the
httpd_$1_script_t domain (towards its httpd_$1_rw_content_t type):
manage_dirs_pattern(httpd_$1_script_t, httpd_$1_rw_content_t, httpd_$1_rw_content_t)
manage_files_pattern(httpd_$1_script_t, httpd_$1_rw_content_t, httpd_$1_rw_content_t)
manage_lnk_files_pattern(httpd_$1_script_t, httpd_$1_rw_content_t, httpd_$1_rw_content_t)
manage_fifo_files_pattern(httpd_$1_script_t, httpd_$1_rw_content_t, httpd_$1_rw_content_t)
manage_sock_files_pattern(httpd_$1_script_t, httpd_$1_rw_content_t, httpd_$1_rw_content_t)
files_tmp_filetrans(httpd_$1_script_t, httpd_$1_rw_content_t, { dir file lnk_file sock_file fifo_file })
The httpd_*_rw_content_t types are generally used to host the content that a
webserver should be able to read, write and manage (including creating new
ones or deleting existing ones). Given that, I'd imagine that
manage_*_pattern for at least dirs and files is needed. I don't have
immediate need myself to manage symbolic links from a web application, but I
can imagine that is equally wanted?
> > +########################################
> > +## <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)
> > +')
> > +
>
> Doesn't seem appropriate to include the script type here.
Actually I based this one on the already existing apache_manage_all_content:
interface(`apache_manage_all_content',`
gen_require(`
attribute httpdcontent, httpd_script_exec_type;
')
manage_dirs_pattern($1, httpdcontent, httpdcontent)
manage_files_pattern($1, httpdcontent, httpdcontent)
manage_lnk_files_pattern($1, httpdcontent, httpdcontent)
manage_dirs_pattern($1, httpd_script_exec_type, httpd_script_exec_type)
manage_files_pattern($1, httpd_script_exec_type, httpd_script_exec_type)
manage_lnk_files_pattern($1, httpd_script_exec_type, httpd_script_exec_type)
')
I changed the manage_ with read_ and dropped the one on directories as the
necessary privileges are part of the other pattern definitions already
(well, at least search privileges, not sure if we need to list directories
here as well).
If we keep the script type out here, I think we might need to introduce an
apache_read_all_scripts then (just like there already is an
apache_read_user_scripts) since the other web servers (like phpfpm) might
need to read in the scripts in order to properly parse and execute them.
Wkr,
Sven Vermeulen
prev parent reply other threads:[~2012-01-05 19:40 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-12-31 12:29 [refpolicy] [PATCH/RFC 1/1] Supporting read/append/manage functions for the various httpd_*_(ra_|rw_|)content Sven Vermeulen
2012-01-04 12:13 ` Christopher J. PeBenito
2012-01-05 19:40 ` Sven Vermeulen [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20120105194040.GA29153@siphos.be \
--to=sven.vermeulen@siphos.be \
--cc=refpolicy@oss.tresys.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.