From: guido@trentalancia.com (Guido Trentalancia)
Date: Fri, 04 Mar 2011 20:01:09 +0100
Subject: [refpolicy] [patch 1/3] Implementation of system conf type
In-Reply-To: <4D70F55D.5000405@tresys.com>
References: <4D5E95C1.9080805@redhat.com>  <20110219095711.GA6270@siphos.be>
	<1298180267.3098.11.camel@tesla.lan>  <4D62875A.8060006@redhat.com>
	<1298319075.11119.3.camel@tesla.lan>  <4D63DA61.3050705@tresys.com>
	<1298391526.16004.8.camel@tesla.lan>  <4D6D4FBA.5040005@tresys.com>
	<1299012069.14035.36.camel@tesla.lan>  <4D6E5523.7040001@tresys.com>
	<1299163002.19257.15.camel@tesla.lan>  <4D70F55D.5000405@tresys.com>
Message-ID: <1299265269.9537.9.camel@tesla.lan>
To: refpolicy@oss.tresys.com
List-Id: refpolicy.oss.tresys.com

Hello Christopher !

Thanks for getting back on this.

On Fri, 04/03/2011 at 09.21 -0500, Christopher J. PeBenito wrote:
> On 03/03/11 09:36, Guido Trentalancia wrote:
> > On Wed, 02/03/2011 at 09.33 -0500, Christopher J. PeBenito wrote:
> >> On 03/01/11 15:41, Guido Trentalancia wrote:
> >>> On Tue, 01/03/2011 at 14.57 -0500, Christopher J. PeBenito wrote:
> >>>> On 02/22/11 11:18, Guido Trentalancia wrote:
> >>>>> On Tue, 22/02/2011 at 10.46 -0500, Christopher J. PeBenito wrote:
> >>>>>> On 02/21/11 15:11, Guido Trentalancia wrote:
> >>>>>>> On Mon, 21/02/2011 at 10.40 -0500, Daniel J Walsh wrote:
> >>>>>>>> On 02/20/2011 12:37 AM, Guido Trentalancia wrote:
> >>>>>> I don't understand why system-config-firewall would need to write to
> >>>>>> etc_t, the iptables rules have their own labeling:
> >>>>>>
> >>>>>> /etc/sysconfig/ip6?tables.*     --
> >>>>>> gen_context(system_u:object_r:iptables_conf_t,s0)
> >>>>>> /etc/sysconfig/system-config-firewall.* --
> >>>>>> gen_context(system_u:object_r:iptables_conf_t,s0)
> >>>>>>
> >>>>>>> Yes, this is very important. But isn't etc_runtime_t what is needed here
> >>>>>>> then ?
> >>>>>>
> >>>>>> No, the purpose of that type is for generated files such as /.autofsck
> >>>>>> and /etc/motd.
> >>>>>
> >>>>> Well then I think we need to check a few labels:
> >>>>>
> >>>>> /etc/smartd\.conf.*     --      system_u:object_r:etc_runtime_t:s0
> >>>>> /etc/reader\.conf       --      system_u:object_r:etc_runtime_t:s0
> >>>>
> >>>> Right, these need to be reevaluated.
> >>>
> >>> I suppose you are going to take care of that.
> >>
> >> Dan/Miroslav, do you have any thoughts on this?  I think these lines and
> >> the below four lines should be removed.
> >>
> >>>>> And there is also other stuff that is not automatically-generated (if
> >>>>> that is what you meant for "generated"):
> >>>>>
> >>>>> /etc/motd       --      system_u:object_r:etc_runtime_t:s0
> >>>>> /etc/issue      --      system_u:object_r:etc_runtime_t:s0
> >>>>> /etc/HOSTNAME   --      system_u:object_r:etc_runtime_t:s0
> >>>>> /etc/issue\.net --      system_u:object_r:etc_runtime_t:s0
> >>>>
> >>>> These can be generated out of init scripts.  For example, Fedora used to
> >>>> generate /etc/issue out of a init script.  It doesn't look like they do
> >>>> that anymore, so perhaps we should reconsider these too
> >>>>
> >>>>> All the above mentioned files are configuration files by all means. Not
> >>>>> that it's an urgent matter, but according to what you just said, then
> >>>>> etc_runtime_t is possibly misplaced there...
> >>>
> >>> Yes, some distributions generate very generic banners with the name of
> >>> the distribution and the version. But they are just meant to be examples
> >>> (similarly to generic configuration files installed by default in /etc
> >>> by most packages).
> >>>
> >>> They are static, so etc_t is what we need here.
> > 
> > I also take the opportunity to remind you of the issue with mtab lock
> > files that I had already mentioned a few days ago.
> > 
> > Basically, mount tries to create lock files named:
> > 
> > /etc/mtab~<pid>
> > 
> > where <pid> gets substituted with the process id of mount itself.
> > 
> > Unfortunately at the moment these files are currently falling back to
> > the etc_t label. It is very much desirable to have them labeled
> > etc_runtime_t to avoid problems (denials) with write operations.
> > 
> > Originally the name for those lock files was /etc/mtab~. To avoid race
> > conditions it was decided to append the <pid>. The source code is
> > designed so that the upper bound for the length of <pid> is 20.
> > 
> > Please note that contrary to what is stated in the source code for mount
> > (fstab.c) there is no dot between "/etc/mtab~" and "<pid>" (it's not
> > "/etc/mtab~.<pid>") !
> > 
> > Can somebody please take care of this ?
> 
> I don't see why this would be happening.  There are the following rules
> in mount:
> 
> files_manage_etc_runtime_files(mount_t)
> files_etc_filetrans_etc_runtime(mount_t, file)
> 
> So the file should be created with etc_runtime_t.  The only reasons I
> can think of this mtab~<pid> file having etc_t are
> 
> 1. it was there already and someone did a relabel

This is not the case. The test system has only one administrator, only
one user and that is me.

> 2. some new SELinux logic in it that does a matchpathcon on the filename
> and then does setfscreatecon() to that context.

In util-linux-2.19 matchpathcon() is only used by disk-utils/mkswap.c
and setfscreatecon() is only used by login-utils/selinux_utils.c (none
of them is used to build mount). The same is true for the previous
version of util-linux.

> So if either of those is the case, you could add a file context entry to
> try to fix it.

Any other idea ?

Regards,

Guido