Received-SPF: pass (google.com: domain of selinux-refpolicy-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
From:   Russell Coker <russell@coker.com.au>
To:     Chris PeBenito <pebenito@ieee.org>
Cc:     selinux-refpolicy@vger.kernel.org
Subject: Re: [PATCH] misc services patches with changes Dominick wanted
Date:   Wed, 27 Jan 2021 14:04:45 +1100
Message-ID: <53731370.JSHSjNzumS@liv>
In-Reply-To: <a1537f1d-fdf1-f05e-363a-c20ba77e6fa5@ieee.org>
References: <YAmFvVmpuYxNxmOC@xev> <a1537f1d-fdf1-f05e-363a-c20ba77e6fa5@ieee.org>
MIME-Version: 1.0
Content-Transfer-Encoding: 7Bit
Content-Type: text/plain; charset="us-ascii"
Precedence: bulk

On Tuesday, 26 January 2021 1:22:22 AM AEDT Chris PeBenito wrote:
> >   gs_exec_t,s0)
> >   /usr/sbin/suexec					--	
gen_context(system_u:object_r:httpd_suexec_exec
> >   _t,s0)
> >   /usr/sbin/wigwam					--	
gen_context(system_u:object_r:httpd_exec_t,s0)> 
> > +/usr/sbin/php.*-fpm					--	
gen_context(system_u:object_r:httpd_exec_t,s0)
> > +/usr/sbin/php-fpm[^/]+					--	
gen_context(system_u:object_r:httpd_exec_t,
> > s0)
> I can fix this when merging, but please keep the fc entries in order.

OK, I'll do that in the next version.

> > @@ -71,6 +71,7 @@ template(`apache_content_template',`
> > 
> >   	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)> 
> > +	allow httpd_$1_script_t httpd_$1_rw_content_t:file map;
> > 
> >   	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)
> There's a lot of mmapping being added.  Can you provide any additional
> context on this?  Is this induced by some config option? Is this apache
> only?

It's for Apache, it maps all files it sends with no special configuration.

> > @@ -63,3 +63,23 @@ interface(`aptcacher_stream_connect',`
> > 
> >   	files_search_runtime($1)
> >   	stream_connect_pattern($1, aptcacher_runtime_t, aptcacher_runtime_t,
> >   	aptcacher_t)>   
> >   ')
> > 
> > +
> > +######################################
> > +## <summary>
> > +##     read aptcacher config
> > +## </summary>
> > +## <param name="domain">
> > +##     <summary>
> > +##     Domain allowed to read it.
> > +##     </summary>
> > +## </param>
> > +#
> > +interface(`aptcacher_read_config',`
> > +	gen_require(`
> > +		type aptcacher_etc_t;
> > +	')
> > +
> > +	files_search_etc($1)
> > +	allow $1 aptcacher_etc_t:dir list_dir_perms;
> > +	allow $1 aptcacher_etc_t:file mmap_read_file_perms;
> > +')
> 
> Is this the only useful way to read these files?  There's no valid non-mmap
> access?  If regular read can be useful, then this should be
> aptcatch_mmap_read_config().

OK.

> > @@ -254,6 +255,7 @@ auth_use_nsswitch(cupsd_t)
> > 
> >   libs_read_lib_files(cupsd_t)
> >   libs_exec_lib_files(cupsd_t)
> > 
> > +libs_legacy_use_ld_so(cupsd_t)
> 
> This seems broken and should probably be in a debian distro block.

OK, I'll remove that and do more testing.

-- 
My Main Blog         http://etbe.coker.com.au/
My Documents Blog    http://doc.coker.com.au/