Humpty Dumpty - some successes

[Stephen Smalley]

On Wed, 2004-05-05 at 14:02, Bob Gustafson wrote:
> 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?

The present policy configuration is more along the lines of your "list
of safe operations". It specifies allowed process-to-object and
inter-process operations based on the security types of the relevant
processes and objects.  The security types group processes and objects
into equivalence classes.  Process security types are called "domains"
by convention, but that is not important.

The current policy language is an "assembly language" for policies. 
Tools such as apol from setools and slat can perform information flow
analysis on these low level policies to check them against higher level
security goals.  The low level policies are often "discovered" for a
particular application by defining an initial stub domain for the
application, then exercising the application and seeing what additional
permissions it needs to operate, and incrementally refining the policy. 
The audit2allow script converts audit messages to policy allow rules,
but the resulting rules need careful review and are often not what you
want.  For example, you may want to introduce a new domain or type
rather than allow access to an existing one.  Not all denials are fatal
to the operation of an application, so in some cases you simply want to
silence the audit message and continue denying access (in particular,
this often occurs with library functions that probe for access that is
not necessarily required by the application).

> 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?

Hmm...well, an operating system that enforces your security goals, to
the extent that implementation is correct and underlying assumptions are
met ;)  It certainly raises the bar in security.

> 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

Possibly greater security awareness in filesystem hierarchy standards. 
But the root problem is that labeling based on pathname is _bad_; the
pathname doesn't tell you anything about the security properties, and a
single inode can be aliased via multiple hard links or bind mounts. 
setfiles was only designed to perform the initial labeling of the
filesystem; subsequent labeling of new files is handled by the policy
rules (or in the case where the application is security-aware, the
application may stipulate a particular label, but must still be
authorized by the policy rules, e.g. modified cp to preserve security
contexts on copied files given the -c option).

-- 
Stephen Smalley <sds at epoch.ncsc.mil>
National Security Agency