Humpty Dumpty - some successes

[Bob Gustafson]

On Wed, 05 May 2004 08:02:41 -0400 Stephen Smalley wrote:
>On Wed, 2004-05-05 at 02:12, Bob Gustafson wrote:

On 'fixfiles relabel'
>
>> A typical bunch of diagnostics looked like this:
>>

snip

>>
>>   /usr/sbin/setfiles:  conflicting specifications for
>>   /usr/src/redhat/BUILD/ooo-build-1.1.53pre/build/OOO_1_1_1/
>>   setup2/unxlngi4.pro/bin/tplx64590.res and
>>   /var/tmp/openoffice.org-1.1.1-root/usr/lib/ooo-1.1/program/resource/
>>   tplx64590.res, using system_u:object_r:src_t.
>>
>> There is a pattern here, but I can't express it in fixable terms.
>
>A "conflicting specifications" warning means that setfiles thinks that
>the two pathnames are multiple hard links to the same inode, which can
>only have a single security context, but the two pathnames match entries
>in file_contexts that have different security contexts, so there is a
>conflict.  setfiles will still label the inode (based on the ordering in
>file_contexts, with later entries taking precedence, unless there is an
>explicit entry for the complete pathname), but it is warning that there
>is an ambiguity in the specification.  Repeatedly relabeling won't help,
>as the conflict will remain until:
>- the conflicting hard link is removed, or
>- the file_contexts configuration is altered to explicitly indicate that
>both pathnames should have the same context, typically by adding
>explicit entries for the conflicting files.
>

Guessing a bit here (still need to read some of those FAQs, etc.):

The idea of Security Enhancements is to come up with a way for the computer
to check the safety of an operation against a list of 'safe' operations
which have been created by humans.

This is a daunting task because the computer is very fast and is doing new
operations all the time. Necessarily, there is a performance hit (no free
lunch). Skillful design hopefully will minimize the performance hit without
throwing the baby away (enforcing secure policy on all operations).

It is daunting from another angle too: If the list of safe operations is
created by humans - there could (will) be an error somewhere in the list.
Thus the tools which have been created which (hopefully) will
programatically [any 'Formal Methods' here?] (prove) (check) that the list
is 'correct'.

This then requires some sort of 'correctness' criteria. Is this the policy
files? Or are the policy files somewhere between the list of safe
operations and the correctness criteria?

In any case, a diagnostic-free run of 'fixfiles relabel' using a
programmatically checked set of policy files should result in a pretty
secure system. Yes?

--

OK this is all prolog to your last sentence where the fixfiles confliction
errors can be fixed by "adding explicit entries for the conflicting files".
This seems a bit tedious - and never ending.

Can some 'security aware' guidelines be created for other developers so
that other components of Linux can be written without somebody having to
write (and check) potentially erroneous entries? Kind of a Surgeon General
poster.

In the meantime, maybe there is a way to solve the conflicts by just
whacking the unneeded files. [In my case, one of the conflicting pair seems
to be redundant - with a 'tmp' in the path] Maybe this can just be an
enhancement to the fixfiles algorithm

snip

>Make sure that you are working with the latest policy, i.e. yum update
>policy.
>

Yes. I did

  yum update policy
  yum update
  yum update \*

And all said that I was up to date.

BobG