The sort algorithm is broken by the second rule, We need a way to pin these rules to the top.

The sort algorithm is broken by the second rule, We need a way to pin these rules to the top.

[Daniel J Walsh]

/usr(/.*)?/lib(64)?(/.*)?            gen_context(system_u:object_r:lib_t,s0)
/usr(/.*)?/lib(64)?/.*\.so(\.[^/]*)*    --    
gen_context(system_u:object_r:shlib_t,s0)

The following has to follow the one above.

/usr/lib(64)?/libglide3\.so.*         --    
gen_context(system_u:object_r:textrel_shlib_t,s0)


It did in FC4, now it does not.  This is the second bug I have seen 
caused by the sort algoritm.  We need a way to secify a primary File 
Context file that will not be sorted but will always be at the top.  
Then the rest can be sorted.

Maybe we do not sort files within a particular fc file.  I do not know. 
but this is broken.



Dan

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: The sort algorithm is broken by the second rule, We need a way to pin these rules to the top.

[Joshua Brindle]

Daniel J Walsh wrote:
> /usr(/.*)?/lib(64)?(/.*)?            
> gen_context(system_u:object_r:lib_t,s0)
> /usr(/.*)?/lib(64)?/.*\.so(\.[^/]*)*    --    
> gen_context(system_u:object_r:shlib_t,s0)
> 
> The following has to follow the one above.
> 
> /usr/lib(64)?/libglide3\.so.*         --    
> gen_context(system_u:object_r:textrel_shlib_t,s0)
> 
> 
> It did in FC4, now it does not.  This is the second bug I have seen 
> caused by the sort algoritm.  We need a way to secify a primary File 
> Context file that will not be sorted but will always be at the top.  
> Then the rest can be sorted.
> 
> Maybe we do not sort files within a particular fc file.  I do not know. 
> but this is broken.
> 

We are preparing to send up a patch that adds file context ordering to 
libsemanage ala the algorithm in fc_sort.c in refpolicy/support. The 
sort algorithm should put the 3rd entry below the top two because the 
stem length is greater. Are you seeing this with strict (and hightly 
modular policy?) the large base.pp from targeted will already have its 
file context entries sorted by fc_sort.c and should handle this case.

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: The sort algorithm is broken by the second rule, We need a way to pin these rules to the top.

[Daniel J Walsh]

Joshua Brindle wrote:
> Daniel J Walsh wrote:
>> /usr(/.*)?/lib(64)?(/.*)?            
>> gen_context(system_u:object_r:lib_t,s0)
>> /usr(/.*)?/lib(64)?/.*\.so(\.[^/]*)*    --    
>> gen_context(system_u:object_r:shlib_t,s0)
>>
>> The following has to follow the one above.
>>
>> /usr/lib(64)?/libglide3\.so.*         --    
>> gen_context(system_u:object_r:textrel_shlib_t,s0)
>>
>>
>> It did in FC4, now it does not.  This is the second bug I have seen 
>> caused by the sort algoritm.  We need a way to secify a primary File 
>> Context file that will not be sorted but will always be at the top.  
>> Then the rest can be sorted.
>>
>> Maybe we do not sort files within a particular fc file.  I do not 
>> know. but this is broken.
>>
>
> We are preparing to send up a patch that adds file context ordering to 
> libsemanage ala the algorithm in fc_sort.c in refpolicy/support. The 
> sort algorithm should put the 3rd entry below the top two because the 
> stem length is greater. Are you seeing this with strict (and hightly 
> modular policy?) the large base.pp from targeted will already have its 
> file context entries sorted by fc_sort.c and should handle this case.
I am only looking at targeted and MLS right now.   As soon as we get 
this fix we need to get it out.

Dan

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: The sort algorithm is broken by the second rule, We need a way to pin these rules to the top.

[Joshua Brindle]

Daniel J Walsh wrote:
> Joshua Brindle wrote:
>> Daniel J Walsh wrote:
>>> /usr(/.*)?/lib(64)?(/.*)?            
>>> gen_context(system_u:object_r:lib_t,s0)
>>> /usr(/.*)?/lib(64)?/.*\.so(\.[^/]*)*    --    
>>> gen_context(system_u:object_r:shlib_t,s0)
>>>
>>> The following has to follow the one above.
>>>
>>> /usr/lib(64)?/libglide3\.so.*         --    
>>> gen_context(system_u:object_r:textrel_shlib_t,s0)
>>>
>>>
>>> It did in FC4, now it does not.  This is the second bug I have seen 
>>> caused by the sort algoritm.  We need a way to secify a primary File 
>>> Context file that will not be sorted but will always be at the top.  
>>> Then the rest can be sorted.
>>>
>>> Maybe we do not sort files within a particular fc file.  I do not 
>>> know. but this is broken.
>>>
>>
>> We are preparing to send up a patch that adds file context ordering to 
>> libsemanage ala the algorithm in fc_sort.c in refpolicy/support. The 
>> sort algorithm should put the 3rd entry below the top two because the 
>> stem length is greater. Are you seeing this with strict (and hightly 
>> modular policy?) the large base.pp from targeted will already have its 
>> file context entries sorted by fc_sort.c and should handle this case.
> I am only looking at targeted and MLS right now.   As soon as we get 
> this fix we need to get it out.
> 
hrm, the libsemanage fix shouldn't affect targeted since it is merely 
replicating the algorithm already used when the base.pp is built by 
refpolicy. The longer stem (of the 3rd entry) should win.

Please note that the sorting algorithm is very much heuristic and not 
perfect. In the discussions we've had around here about this we 
determined that the correct solution is to make the regexes more 
specific where possible.

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: The sort algorithm is broken by the second rule, We need a way to pin these rules to the top.

[Christopher Ashworth]

On Friday 31 March 2006 10:17 am, Joshua Brindle wrote:
> Please note that the sorting algorithm is very much heuristic and not
> perfect. In the discussions we've had around here about this we
> determined that the correct solution is to make the regexes more
> specific where possible.

Indeed.  Strictly speaking, to properly order based on specificity we need to 
be able to solve the decision problem of whether one regular expression is a 
subset of another.  As such, until we have an implementation based on this 
method file contexts must be written with the limitations of our heuristics 
in mind.

In the following example:

> Running fc_sort from refpolicy on the following input:
> /usr(/.*)?/lib(64)?(/.*)?        gen_context(system_u:object_r:lib_t,s0)
> /usr(/.*)?/lib(64)?/.*\.so(\[^/]*)*    --  gen_context(system_u:object_r:shlib_t,s0)
> /usr(/.*)?/nvidia/.*\.so(\..*)?        --  gen_context(system_u:object_r:textrel_shlib_t,s0)
> /usr/lib(64)?/libglide3\.so.*      --    gen_context(system_u:object_r:textrel_shlib_t,s0)
> 
> yields the following output:
> /usr(/.*)?/lib(64)?(/.*)?       gen_context(system_u:object_r:lib_t,s0)
> /usr(/.*)?/nvidia/.*\.so(\..*)?        --      gen_context(system_u:object_r:textrel_shlib_t,s0)
> /usr(/.*)?/lib(64)?/.*\.so(\[^/]*)*   --    gen_context(system_u:object_r:shlib_t,s0)
> /usr/lib(64)?/libglide3\.so.*    --    gen_context(system_u:object_r:textrel_shlib_t,s0)

the nvidia entry "loses" because the stem matches the stem of the following 
line, and the overall length of the nvidia line is shorter.  With a 
subset-based approach we would be able to recognize that neither is a subset 
of the other, and so the original order could be preserved.  (The 
implementation of the sort is stable, but that doesn't really help us much 
seeing as our comparison operator is based on heuristics, so the definition 
of "stability" has become only as good as our heuristics.)

Christopher


Reference:  

http://www.cs.may.ie/~jpower/Courses/parsing/node14.html

-- 
Christopher Ashworth
Tresys Technology, LLC


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: The sort algorithm is broken by the second rule, We need a way to pin these rules to the top.

[Stephen Smalley]

On Fri, 2006-03-31 at 10:17 -0500, Joshua Brindle wrote:
> Please note that the sorting algorithm is very much heuristic and not 
> perfect. In the discussions we've had around here about this we 
> determined that the correct solution is to make the regexes more 
> specific where possible.

In the old scheme (example policy build), types.fc always went first,
followed by the program .fc files in arbitrary order, leaving the
ordering as specified within each file, and the goal was to put most
generic patterns only in types.fc (manually ordered by the policy writer
based on his goal for prioritization) and to minimize use of regexes
(particularly ones that were overly broad and lacked a reasonably
specific stem) in the individual program .fc files.  Not saying that we
achieved that goal, but that was the approach.

Recent file_contexts seem to have _very_ broad regexes in an attempt to
cover many variations, but I think that this isn't good for
understanding.

-- 
Stephen Smalley
National Security Agency


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: The sort algorithm is broken by the second rule, We need a way to pin these rules to the top.

[Stephen Smalley]

On Fri, 2006-03-31 at 10:01 -0500, Daniel J Walsh wrote:
> Joshua Brindle wrote:
> > We are preparing to send up a patch that adds file context ordering to 
> > libsemanage ala the algorithm in fc_sort.c in refpolicy/support. The 
> > sort algorithm should put the 3rd entry below the top two because the 
> > stem length is greater. Are you seeing this with strict (and hightly 
> > modular policy?) the large base.pp from targeted will already have its 
> > file context entries sorted by fc_sort.c and should handle this case.
> I am only looking at targeted and MLS right now.   As soon as we get 
> this fix we need to get it out.

If it isn't working in targeted presently (using the refpolicy's fc_sort
helper at build time), then putting the logic in libsemanage won't help
either.  The question is why doesn't it work now for the libglide entry?
fc_sort appears to do the right thing for it.

-- 
Stephen Smalley
National Security Agency


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: The sort algorithm is broken by the second rule, We need a way to pin these rules to the top.

[Stephen Smalley]

On Fri, 2006-03-31 at 10:17 -0500, Stephen Smalley wrote:
> If it isn't working in targeted presently (using the refpolicy's fc_sort
> helper at build time), then putting the logic in libsemanage won't help
> either.  The question is why doesn't it work now for the libglide entry?
> fc_sort appears to do the right thing for it.

On FC5:
$ matchpathcon /usr/lib/libglide3.so.3
/usr/lib/libglide3.so.3 system_u:object_r:textrel_shlib_t

Of course, I just made that path up, as I don't have it installed - what
is the actual path in question?

-- 
Stephen Smalley
National Security Agency


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: The sort algorithm is broken by the second rule, We need a way to pin these rules to the top.

[Stephen Smalley]

On Fri, 2006-03-31 at 09:57 -0500, Joshua Brindle wrote:
> Daniel J Walsh wrote:
> > /usr(/.*)?/lib(64)?(/.*)?            
> > gen_context(system_u:object_r:lib_t,s0)
> > /usr(/.*)?/lib(64)?/.*\.so(\.[^/]*)*    --    
> > gen_context(system_u:object_r:shlib_t,s0)
> > 
> > The following has to follow the one above.
> > 
> > /usr/lib(64)?/libglide3\.so.*         --    
> > gen_context(system_u:object_r:textrel_shlib_t,s0)
> > 
> > 
> > It did in FC4, now it does not.  This is the second bug I have seen 
> > caused by the sort algoritm.  We need a way to secify a primary File 
> > Context file that will not be sorted but will always be at the top.  
> > Then the rest can be sorted.
> > 
> > Maybe we do not sort files within a particular fc file.  I do not know. 
> > but this is broken.
> > 
> 
> We are preparing to send up a patch that adds file context ordering to 
> libsemanage ala the algorithm in fc_sort.c in refpolicy/support. The 
> sort algorithm should put the 3rd entry below the top two because the 
> stem length is greater. Are you seeing this with strict (and hightly 
> modular policy?) the large base.pp from targeted will already have its 
> file context entries sorted by fc_sort.c and should handle this case.

Running fc_sort from refpolicy on the following input:
/usr(/.*)?/lib(64)?(/.*)?            gen_context(system_u:object_r:lib_t,s0)
/usr(/.*)?/lib(64)?/.*\.so(\.[^/]*)*    --  gen_context(system_u:object_r:shlib_t,s0)
/usr(/.*)?/nvidia/.*\.so(\..*)?        --   gen_context(system_u:object_r:textrel_shlib_t,s0)
/usr/lib(64)?/libglide3\.so.*         --    gen_context(system_u:object_r:textrel_shlib_t,s0)

yields the following output:
/usr(/.*)?/lib(64)?(/.*)?               gen_context(system_u:object_r:lib_t,s0)
/usr(/.*)?/nvidia/.*\.so(\..*)?         --      gen_context(system_u:object_r:textrel_shlib_t,s0)
/usr(/.*)?/lib(64)?/.*\.so(\.[^/]*)*            --      gen_context(system_u:object_r:shlib_t,s0)
/usr/lib(64)?/libglide3\.so.*           --      gen_context(system_u:object_r:textrel_shlib_t,s0)

So the nvidia entry loses (this was separately reported), but the
libglide entry should be ok (last matching entry wins).  Yes?

At present, you can force the nvidia entry to win by adding it as a
local fcontext via semanage or file_contexts.local.  But if we add the
sort to libsemanage, we'll lose the ability to give precedence to local
fcontexts added by semanage unless we exclude the local ones from the
sort, right?

-- 
Stephen Smalley
National Security Agency


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: The sort algorithm is broken by the second rule, We need a way to pin these rules to the top.

[Ivan Gyurdiev]

>
> At present, you can force the nvidia entry to win by adding it as a
> local fcontext via semanage or file_contexts.local.  But if we add the
> sort to libsemanage, we'll lose the ability to give precedence to local
> fcontexts added by semanage unless we exclude the local ones from the
> sort, right?
>   
Hmm, I think we actually don't have this capability as of right now - my 
fault, as I didn't get around to addressing this issue, which would 
consist of either not merging the .local file into the other one (as we 
do now), or moving the sort algorithm into libsemanage, where it would 
sort the local things separately from the module things.


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: The sort algorithm is broken by the second rule, We need a way to pin these rules to the top.

[Ivan Gyurdiev]

[-- Attachment #1: Type: text/plain, Size: 384 bytes --]


> Hmm, I think we actually don't have this capability as of right now - 
> my fault, as I didn't get around to addressing this issue, which would 
> consist of either not merging the .local file into the other one (as 
> we do now), or moving the sort algorithm into libsemanage, where it 
> would sort the local things separately from the module things. 
...maybe this will help.



[-- Attachment #2: libsemanage.install_fc_local.diff --]
[-- Type: text/x-patch, Size: 2896 bytes --]

diff -Naurp --exclude-from excludes old/libsemanage/src/policy_components.c new/libsemanage/src/policy_components.c
--- old/libsemanage/src/policy_components.c	2006-03-15 12:21:56.000000000 -0500
+++ new/libsemanage/src/policy_components.c	2006-03-31 12:22:34.000000000 -0500
@@ -136,8 +136,11 @@ int semanage_base_merge_components(
 		{ semanage_bool_dbase_local(handle),
 		  semanage_bool_dbase_policy(handle), MODE_SET },
 
+#if 0
+		/* Sorting algorithm must be moved to libsemanage first */
 		{ semanage_fcontext_dbase_local(handle),
 		  semanage_fcontext_dbase_policy(handle), MODE_MODIFY },
+#endif
 
 		{ semanage_seuser_dbase_local(handle),
 		  semanage_seuser_dbase_policy(handle), MODE_MODIFY },
@@ -219,7 +222,10 @@ int semanage_commit_components(
 		semanage_user_extra_dbase_policy(handle),
 		semanage_port_dbase_local(handle),
 		semanage_fcontext_dbase_local(handle),
+#if 0
+		/* Sorting algorithm must be moved to libsemanage first */
 		semanage_fcontext_dbase_policy(handle),
+#endif
 		semanage_seuser_dbase_local(handle),
 		semanage_seuser_dbase_policy(handle),
 		semanage_bool_dbase_active(handle),
diff -Naurp --exclude-from excludes old/libsemanage/src/semanage_store.c new/libsemanage/src/semanage_store.c
--- old/libsemanage/src/semanage_store.c	2006-03-08 12:15:25.000000000 -0500
+++ new/libsemanage/src/semanage_store.c	2006-03-31 12:11:13.000000000 -0500
@@ -931,6 +931,7 @@ static int semanage_install_active(seman
 	struct stat astore, istore;
 	const char *active_kernel = semanage_path(SEMANAGE_ACTIVE,SEMANAGE_KERNEL);
 	const char *active_fc = semanage_path(SEMANAGE_ACTIVE, SEMANAGE_FC);
+	const char *active_fc_local = semanage_path(SEMANAGE_ACTIVE, SEMANAGE_FC_LOCAL);
 	const char *active_hd = semanage_path(SEMANAGE_ACTIVE, SEMANAGE_HOMEDIR_TMPL);
 	const char *active_seusers = semanage_path(SEMANAGE_ACTIVE, SEMANAGE_SEUSERS);
 
@@ -944,6 +945,7 @@ static int semanage_install_active(seman
 	 * building code in libselinux so that you can get paths for a given 
 	 * POLICYTYPE and should probably be done in the future. */
 	char store_fc[PATH_MAX];
+	char store_fc_local[PATH_MAX];
 	char store_hd[PATH_MAX];
 	char store_pol[PATH_MAX];
 	char store_seusers[PATH_MAX];
@@ -979,6 +981,13 @@ static int semanage_install_active(seman
 		goto cleanup;
 	}
 
+	/* Should not be necessary once sorting algorithm is moved into libsemanage */
+	snprintf(store_fc_local, PATH_MAX, "%s%s.local", storepath, running_fc);
+	if (semanage_copy_file(active_fc_local, store_fc_local, sh->conf->file_mode) == -1) {
+		ERR(sh, "Could not copy %s to %s.", active_fc_local, store_fc_local);
+		goto cleanup;
+	}
+
 	snprintf(store_seusers, PATH_MAX, "%s%s", storepath, running_seusers);
 	if (semanage_copy_file(active_seusers, store_seusers, sh->conf->file_mode) == -1) {
 		INFO(sh, "Non-fatal error:  Could not copy %s to %s.", active_seusers, store_seusers);

Re: The sort algorithm is broken by the second rule, We need a way to pin these rules to the top.

[Ivan Gyurdiev]

Ivan Gyurdiev wrote:
>
>> Hmm, I think we actually don't have this capability as of right now - 
>> my fault, as I didn't get around to addressing this issue, which 
>> would consist of either not merging the .local file into the other 
>> one (as we do now), or moving the sort algorithm into libsemanage, 
>> where it would sort the local things separately from the module things. 
> ...maybe this will help.
>
I assume this patch won't be used...but in case anyone decides to merge 
it, it's buggy - it needs to treat lack of file_contexts.local in the 
sandbox as non-fatal and fallthrough on install, just like it was done 
for the seusers file - simple 1-line change.


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: The sort algorithm is broken by the second rule, We need a way to pin these rules to the top.

[Stephen Smalley]

On Fri, 2006-03-31 at 11:35 -0500, Ivan Gyurdiev wrote:
> >
> > At present, you can force the nvidia entry to win by adding it as a
> > local fcontext via semanage or file_contexts.local.  But if we add the
> > sort to libsemanage, we'll lose the ability to give precedence to local
> > fcontexts added by semanage unless we exclude the local ones from the
> > sort, right?
> >   
> Hmm, I think we actually don't have this capability as of right now - my 
> fault, as I didn't get around to addressing this issue, which would 
> consist of either not merging the .local file into the other one (as we 
> do now), or moving the sort algorithm into libsemanage, where it would 
> sort the local things separately from the module things.

Not sure we are all on the same page here.  At present, one can add
fcontext entries via semanage fcontext -a (which are then merged to the
end of the generated file_contexts file that is installed) or by
manually adding
to /etc/selinux/$SELINUXTYPE/contexts/files/file_contexts.local, which
is not managed presently but is still read by libselinux
matchpathcon(3).  Either approach will ensure that the entry you added
takes precedence over any existing ones.  Sorting is presently only
happening in the policy build process via the
refpolicy/support/fc_sort.c helper program, so it is only applied to the
file_context file provided by the policy itself, not to any local
entries (whether created via semanage or not).

If/when the sort logic is moved into libsemanage, we can still ensure
that it is only applied to the policy file contexts.  Why do we need to
refrain from merging the local file contexts into the final file?

-- 
Stephen Smalley
National Security Agency


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: The sort algorithm is broken by the second rule, We need a way to pin these rules to the top.

[Ivan Gyurdiev]

>   Sorting is presently only
> happening in the policy build process via the
> refpolicy/support/fc_sort.c helper program, so it is only applied to the
> file_context file provided by the policy itself, not to any local
> entries (whether created via semanage or not).
>   
My mistake, I thought sorting was moved into matchpathcon at some point...
In that case the patch I sent shouldn't be necessary.


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: The sort algorithm is broken by the second rule, We need a way to pin these rules to the top.

[Stephen Smalley]

On Fri, 2006-03-31 at 14:03 -0500, Ivan Gyurdiev wrote:
> >   Sorting is presently only
> > happening in the policy build process via the
> > refpolicy/support/fc_sort.c helper program, so it is only applied to the
> > file_context file provided by the policy itself, not to any local
> > entries (whether created via semanage or not).
> >   
> My mistake, I thought sorting was moved into matchpathcon at some point...
> In that case the patch I sent shouldn't be necessary.

Yes, Joshua had sent a patch to add the sorting logic to matchpathcon
back in Oct '05, but I rejected it at the time because it needed to be
coordinated with a policy update to ensure no actual change in
filesystem labeling and because it sorted all of the file_contexts.*
files together rather than retaining a prioritization among them.  And
as we later agreed, it belongs in libsemanage at generation time rather
than in libselinux.

Current libselinux matchpathcon logic only moves exact specifications
(no regex in the pathname) to the end so that they are never overridden
by a pathname regex; otherwise, it just uses the provided ordering
within each file and it uses a fixed ordering among the files
(file_contexts.local takes precedence over file_contexts.homedirs which
takes precedence over file_contexts).

What is a little confusing right now is that there are potentially two
"file_contexts.local" files; the one managed via semanage that only
exists in the store and is merged to the end of the generated
file_contexts file for installation and the one that can be manually
created by the admin that is "merged" to the end of the in-memory table
by matchpathcon.  I suppose we should consider the latter to be
deprecated but libselinux will continue to look for it for legacy
support.

-- 
Stephen Smalley
National Security Agency


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: The sort algorithm is broken by the second rule, We need a way to pin these rules to the top.

[Joshua Brindle]

Stephen Smalley wrote:
> On Fri, 2006-03-31 at 14:03 -0500, Ivan Gyurdiev wrote:
>>>   Sorting is presently only
>>> happening in the policy build process via the
>>> refpolicy/support/fc_sort.c helper program, so it is only applied to the
>>> file_context file provided by the policy itself, not to any local
>>> entries (whether created via semanage or not).
>>>   
>> My mistake, I thought sorting was moved into matchpathcon at some point...
>> In that case the patch I sent shouldn't be necessary.
> 
> Yes, Joshua had sent a patch to add the sorting logic to matchpathcon
> back in Oct '05, but I rejected it at the time because it needed to be
> coordinated with a policy update to ensure no actual change in
> filesystem labeling and because it sorted all of the file_contexts.*
> files together rather than retaining a prioritization among them.  And
> as we later agreed, it belongs in libsemanage at generation time rather
> than in libselinux.
> 
> Current libselinux matchpathcon logic only moves exact specifications
> (no regex in the pathname) to the end so that they are never overridden
> by a pathname regex; otherwise, it just uses the provided ordering
> within each file and it uses a fixed ordering among the files
> (file_contexts.local takes precedence over file_contexts.homedirs which
> takes precedence over file_contexts).
> 
> What is a little confusing right now is that there are potentially two
> "file_contexts.local" files; the one managed via semanage that only
> exists in the store and is merged to the end of the generated
> file_contexts file for installation and the one that can be manually
> created by the admin that is "merged" to the end of the in-memory table
> by matchpathcon.  I suppose we should consider the latter to be
> deprecated but libselinux will continue to look for it for legacy
> support.
> 

I think libsemanage should just put the .local file out for libselinux 
to read. There is no guarantee that none of the entries on .local won't 
be preceded by something in the normal file context if it is merged in 
libsemanage. This is the same thing we do for file_contexts.homedirs so 
why not do it with .local? (Also, if we merge .local into the normal fc 
file then the .local can't override .homedirs)

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: The sort algorithm is broken by the second rule, We need a way to pin these rules to the top.

[Stephen Smalley]

On Fri, 2006-03-31 at 14:18 -0500, Joshua Brindle wrote:
> I think libsemanage should just put the .local file out for libselinux 
> to read. There is no guarantee that none of the entries on .local won't 
> be preceded by something in the normal file context if it is merged in 
> libsemanage.

Last matching entry takes precedence, so as long as they are merged to
the end of file_contexts (as they presently are), the local entries will
always take precedence over any earlier matching entry.

>  This is the same thing we do for file_contexts.homedirs so 
> why not do it with .local? (Also, if we merge .local into the normal fc 
> file then the .local can't override .homedirs)

.homedirs is a bit different in that it is generated via genhomedircon
from a policy-provided template.  The last point is true - that does
yield a difference between ordering of entries added via semanage
fcontext -a vs. manually put into file_contexts.local.

However, changing libsemanage to install file_contexts.local instead of
merging it now is a behavioral change that could clobber an existing
file_contexts.local, so we'd have to be very careful about the "upgrade"
situation and we'd likely want to push that to FC5 ASAP so that users
there don't get used to being able to manually tinker with
file_contexts.local separately.

-- 
Stephen Smalley
National Security Agency


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: The sort algorithm is broken by the second rule, We need a way to pin these rules to the top.

[Joshua Brindle]

Stephen Smalley wrote:
> On Fri, 2006-03-31 at 14:18 -0500, Joshua Brindle wrote:
>> I think libsemanage should just put the .local file out for libselinux 
>> to read. There is no guarantee that none of the entries on .local won't 
>> be preceded by something in the normal file context if it is merged in 
>> libsemanage.
> 
> Last matching entry takes precedence, so as long as they are merged to
> the end of file_contexts (as they presently are), the local entries will
> always take precedence over any earlier matching entry.
> 
If a user adds a file context entry with a regex operator to .local it 
will get overridden by a specific match in the policy, I think this 
would be unexpected to the end user.

>>  This is the same thing we do for file_contexts.homedirs so 
>> why not do it with .local? (Also, if we merge .local into the normal fc 
>> file then the .local can't override .homedirs)
> 
> .homedirs is a bit different in that it is generated via genhomedircon
> from a policy-provided template.  The last point is true - that does
> yield a difference between ordering of entries added via semanage
> fcontext -a vs. manually put into file_contexts.local.
> 
> However, changing libsemanage to install file_contexts.local instead of
> merging it now is a behavioral change that could clobber an existing
> file_contexts.local, so we'd have to be very careful about the "upgrade"
> situation and we'd likely want to push that to FC5 ASAP so that users
> there don't get used to being able to manually tinker with
> file_contexts.local separately.
> 

Right, it's too bad we didn't do this before the release.

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: The sort algorithm is broken by the second rule, We need a way to pin these rules to the top.

[Ivan Gyurdiev]

Joshua Brindle wrote:
> Stephen Smalley wrote:
>> On Fri, 2006-03-31 at 14:18 -0500, Joshua Brindle wrote:
>>> I think libsemanage should just put the .local file out for 
>>> libselinux to read. There is no guarantee that none of the entries 
>>> on .local won't be preceded by something in the normal file context 
>>> if it is merged in libsemanage.
>>
>> Last matching entry takes precedence, so as long as they are merged to
>> the end of file_contexts (as they presently are), the local entries will
>> always take precedence over any earlier matching entry.
>>
> If a user adds a file context entry with a regex operator to .local it 
> will get overridden by a specific match in the policy, I think this 
> would be unexpected to the end user.
So, why does sorting occur at build time, and then additional sorting of 
specific entries occurs at "runtime"?



--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

RE: The sort algorithm is broken by the second rule, We need a way to pin these rules to the top.

[Joshua Brindle]

Joshua Brindle wrote:
> Stephen Smalley wrote:
>> On Fri, 2006-03-31 at 14:18 -0500, Joshua Brindle wrote:
>>> I think libsemanage should just put the .local file out for 
>>> libselinux to read. There is no guarantee that none of the entries 
>>> on .local won't be preceded by something in the normal file context 
>>> if it is merged in libsemanage.
>>
>> Last matching entry takes precedence, so as long as they are merged to
>> the end of file_contexts (as they presently are), the local entries will
>> always take precedence over any earlier matching entry.
>>
> If a user adds a file context entry with a regex operator to .local it 
> will get overridden by a specific match in the policy, I think this 
> would be unexpected to the end user.
So, why does sorting occur at build time, and then additional sorting of 
specific entries occurs at "runtime"?

Sorting at build time is to fix the unordering that occurs when you break file contexts up into lots of modules. The runtime sorting has always been there and only puts specific entries toward the bottom so that they are matched first. We can't really get rid of the runtime sorting because of legacy and the build time sorting is necessary for modular policy to work.



--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: The sort algorithm is broken by the second rule, We need a way to pin these rules to the top.

[Ivan Gyurdiev]

> (Also, if we merge .local into the normal fc file then the .local 
> can't override .homedirs)
We also don't have the capability of expanding templates in the .local 
file, so I doubt this will be an issue.
Btw the .homedirs file can easily be merged into the big file_contexts.

I don't have a strong opinion of whether we should be merging things 
together or not. It's just that this separation in .local .homedirs 
.something_else has to do with processing work, which seems to belong at 
policy build time, not at "runtime" where matchpathcon just wants to 
look up a context.



--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.