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@xxxxxxxxxxxxxx> National Security Agency
