On Thu, 2004-10-07 at 12:07, Jeff Spaleta wrote: > I think there is a strong point about complexity of the settings > space. The fact that ownership permission and umask use a small finite > settings space makes the ui for changing those settings managable > across a number of tools. Security contexts are simply security equivalence classes, i.e. everything with the same security context is handled identically as far as the security policy is concerned. The permissions granted to a given security context (the parallel to your DAC mode bits) are defined centrally in the policy configuration, and you can analyze the entire policy there, including the maximum possible privilege escalation and information flows allowed. Contrast with DAC mode bits or ACLs, where the policy is effectively scattered throughout the filesystem and neither privilege escalation nor information flow are bounded in any way. > For example lftp client understands chmod. does it understand restorecon? Not yet, AFAIK. Nor will it likely ever if SELinux is disabled by default and it remains limited to a very small user community. > I think there is a point here too.. but let me rephrase it by asking a > question. Is there ever any value in having files in a path NOT be > the correct security context for that path? Yes, there is value in customizing your file contexts beyond the default settings. > Are there tools in userspace with 'reasonable' ui that would let a > user manually change context on a subset of files contrary to what > restorecon would do? If there is a lack of tools that let users > delibrately create out of sync security contexts, thats a major > difference between how ownership and permissions are handled. chcon(1) is the equivalent to chown/chmod. Mandatory access control is a (to steal a term) disruptive technology, but one that is fundamentally necessary if one is ever going to be able to effectively control or even reliably monitor what is truly happening on computing systems. With only DAC, the code that acts on our behalf operates without any restraint and with precious little protection against subversion. If you want to have a hope of confining the damage caused by flawed and/or malicious program, protecting your application security mechanisms against tampering and bypass, separating your sensitive information from your public information, protecting information on which your operations depend from corruption, or ensuring that your data is processed as required, then MAC is a necessary building block, not optional. As far as freedom is concerned, one always has the option of disabling SELinux at install time or post-install; I don't think anyone has any plans to change that. But disabling by default has a huge impact on uptake of this disruptive technology and on bringing sufficient resources to bear to fully integrate it into the entire system. -- Stephen Smalley <sds@xxxxxxxxxxxxxx> National Security Agency
