From: pebenito@ieee.org (Chris PeBenito) Date: Tue, 12 Dec 2017 20:09:20 -0500 Subject: [refpolicy] [PATCH] Fix implementation of MLS file relabel attributes In-Reply-To: <20171212054907.GA117841@localhost.localdomain> References: <20171211040215.53324-1-dahchanson@gmail.com> <20171212054907.GA117841@localhost.localdomain> Message-ID: To: refpolicy@oss.tresys.com List-Id: refpolicy.oss.tresys.com On 12/12/2017 12:49 AM, Chad Hanson wrote: > On Mon, Dec 11, 2017 at 07:01:18PM -0500, Chris PeBenito wrote: >> On 12/10/2017 11:02 PM, Chad Hanson via refpolicy wrote: >>> This patch properly completes the implementation of the MLS file relabel attributes. In the previous patch [http://oss.tresys.com/pipermail/refpolicy/2016-July/008038.html], a new attribute, mlsfilerelabetoclr, was created. There should have been a second attribute, mlsfilerelabel, created instead of overloading mlsfilewrite for this privilege. I concur with creating new attributes for this situation. I have created the patch below. >>> >>> Signed-off-by: Chad Hanson >>> --- >>> policy/mls | 2 +- >>> policy/modules/kernel/mls.if | 28 ++++++++++++++++++++++++---- >>> policy/modules/kernel/mls.te | 3 ++- >>> 3 files changed, 27 insertions(+), 6 deletions(-) >>> >>> diff --git a/policy/mls b/policy/mls >>> index 2dadd205..73ff301b 100644 >>> --- a/policy/mls >>> +++ b/policy/mls >>> @@ -72,7 +72,7 @@ mlsconstrain { file lnk_file fifo_file } { create relabelto } >>> mlsconstrain { dir file lnk_file chr_file blk_file sock_file fifo_file } relabelto >>> (( h1 dom h2 ) or >>> (( t1 == mlsfilerelabeltoclr ) and ( h1 dom l2 )) or >>> - ( t1 == mlsfilewrite )); >>> + ( t1 == mlsfilerelabel )); >> >> It seems like both conditions should actually be included, not the >> mlsfilerelabel replacing the mlsfilewrite. That way, if you use the >> latter, it's still comprehensive. >> > > I would normally agree, I just don't think mlsfilewrite should ever been > allowed for "relabelto" operations. The combination of a new > mlsfilerelabeltoclr combined with mlsfilewrite doesn't make sense. It > should either have been mlsfilewrite[toclr] or mlsfilerelabel[toclr]. My > personal opinion is that relabel is much different than write. In MLS, a > process can write to a file without having read access. A relabel can > lead to new accesses since this is a file attribute change. This wasn't > bypassable originally, that is why a new attribute seems to make sense. That makes sense. Merged. -- Chris PeBenito