Could this possibly be a result of the above being a fundamentally
flawed security model? Not to mention it being primarily an auditing
model rather than a real access control model. It also seems a bit
problematic regardless of your kernel security framework; what does
"logging cannot continue" truly mean? Do you have to verify that the
log record made it to disk before you can proceed with the operation?
<insane ranting about evil conspiracies ignored>
> Also unsupported: The "no-security" model -- where all security
> is thrown out (to save memory space and cycles) that was desired for embedded
work.
The capabilities logic was moved into a module, and you have the option
of building a kernel with traditional superuser logic (dummy security
module) rather than capabilities. It is true that the capability bits
haven't yet been moved into the opaque security field, as explained in
the documentation, but this can be changed if desired (but there are
consequences to such a change; see the discussion in lsm.tmpl) . It is
also true that the capable() calls haven't been moved, but there is
little to be gained by it except possibly where there is a
corresponding LSM hook, and that is a straightforward refinement of the
existing LSM patch.
> LSM also doesn't support standard LSPP-B1 style graded security
> where mandatory access checks are logged as security violations before
> DAC checks are even looked at for an object.
An auditing issue, not an access control issue. As previously
discussed, there is no channel as long as both checks return the
same error (and doing otherwise is a compatibility problem).
> At one point a plan was proposed (by Casey Schaufler, SGI) and
> _\implemented\_ (team members & prjct lead Linda Walsh) to move all
> security checks out of the kernel into a 'default policy' module.
> The code to implement this was submitted to the LSM list in June 1991.
1991? I don't think so. But feel free to point people to your patch if
you like. Moving all of the DAC logic into a module is _not_ necessary
to add support for strong access controls. And modularizing that logic
has interesting implications; what happens to your applications when
you turn off the kernel DAC logic and replace it with something
arbitrary?
-- Stephen Smalley, NSA sds@epoch.ncsc.mil
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/