From: sven.vermeulen@siphos.be (Sven Vermeulen)
Date: Fri, 10 Aug 2012 07:30:53 +0200
Subject: [refpolicy] [PATCH v2 1/2] Use substititions for /usr/local/lib
 and /etc/init.d
In-Reply-To: <50243CB9.8030306@trentalancia.com>
References: <20120809174351.GA32628@siphos.be>
	<20120809174458.GB32628@siphos.be>
	<5024016A.5060700@trentalancia.com>
	<20120809184406.GB2643@siphos.be>
	<50243CB9.8030306@trentalancia.com>
Message-ID: <20120810053053.GA6610@siphos.be>
To: refpolicy@oss.tresys.com
List-Id: refpolicy.oss.tresys.com

On Fri, Aug 10, 2012 at 12:42:01AM +0200, Guido Trentalancia wrote:
> >>> --- a/policy/modules/kernel/corecommands.fc
> >>> +++ b/policy/modules/kernel/corecommands.fc
> >>> @@ -66,8 +66,6 @@ ifdef(`distro_redhat',`
> >>>    /etc/hotplug/hotplug\.functions --	gen_context(system_u:object_r:bin_t,s0)
> >>>    /etc/hotplug\.d/default/default.*	gen_context(system_u:object_r:bin_t,s0)
> >>>
> >>> -/etc/init\.d/functions		--	gen_context(system_u:object_r:bin_t,s0)
> >>> -
> >>
> >> My advice is to leave this (and a couple more) for safety, as it would
> >> probably do more good than harm. The substitution file is a
> >> configuration file and it can be edited erroneously.
> >
> > I disagree. If we would leave in these file context definitions - which will
> > never be hit in the first place if the file context substitution file is
> > correct - it would give a false sense towards the policy administrators that
> > it is a "good" rule.
> 
> "Substitution of /etc/rc.d/init.d with /etc/init.d" should leave 
> /etc/init.d unmodified (thus producing only a duplicate entry in the 
> worst case). If a duplicate entry with the same context is detected as 
> an error by setfiles, perhaps the latter should be modified (so that it 
> produces at most a warning).

Setfiles doesn't see this as a duplicate entry as far as I can remember. It
looks at the file path and tries to match it against the file contexts
/after/ substitution. In other words, the file contexts that use a path that
is substituted away from (like /etc/init.d) are just dead code.

> > Say some policy editor wants to have /etc/init.d/functions labeled
> > shell_exec_t or so instead. If he would do
> >    /etc/init\.d/functions-- gen_context(system_u:object_r:shell_exec_t,s0)
> > he'll have a hard time figuring out why it still labels as bin_t.
> 
> Do you mean perhaps that if he or she only modifies the first one and 
> then leaves the second one as it is and also inadvertently modifies 
> file_contexts.sub_dist so that is substitutes /etc/rc.d/init.d with 
> /etc/init.d, the result is inconsistent ?

No, what I mean is the following.

Before my commit, you have both /etc/init.d/blabla and
/etc/rc.d/init.d/blabla rules in the file contexts. In the commit, a
substitution rule is added stating that every file path with /etc/init.d
should be looked at as if it was /etc/rc.d/init.d in the file contexts.

So what you now have is that each and every /etc/init.d line in the file
contexts is never going to be used anymore. It is also never really looked
at.

However, if I as a policy editor see both /etc/init.d and /etc/rc.d/init.d
used in the policy, I would *assume* that they are still both valid - which
isn't the case.

By only seeing /etc/rc.d/init.d in the entire code, it makes more sense to
me to not just quickly add in a /etc/init.d (because that would be the
first, even though "it works") and I will remember that a file context
substitution entry is in place.


> >> You have not replaced the above four entries with anything... Even if it
> >> was obsolete stuff, I would recommend not removing them completely
> >> unless, say, the obsolete source code is no longer available at the main
> >> distribution point.
> 
> ...and by all distributions actually.

The moment a distribution pulls in from refpolicy, the substitutions are in
place.

Don't forget that, what I did here in the patch (i.e. introduce the
substitution and update all file contexts to match it) is no different from
the substitution for /usr/lib64 and /usr/lib32 to /usr/lib a while ago.

There too, all contexts were updated to reflect the new, "substituted"
situation. I don't see why the substitutions for /etc/init.d would be any
different.

Wkr,
	Sven Vermeulen