On Wed, Feb 23, 2005 at 09:07:31AM -0800, Chris Wright wrote:
* Klaus Weidner (klaus(a)atsec.com) wrote:
> Sorry to disagree once again, but auditing the reasons for access control
> decisions isn't required by CAPP anywhere, see section 5.1.1.2 and table
> 1 for the exhaustive list of audit record requirements. It just needs to
> record the success/failure result of the operation.
It's a matter of interpretation of 5.1.1.2 a) "... subject identity, ..."
Since "subjects" are defined to be processes (running on behalf of
users), I'd consider them to be identified by the PID, and the security
attributes would be properties of the process but not part of the
identity. (A privileged process may change its own security properties,
and I'd think it would be weird if that would correspond to a change of
identity for that process.)
> I agree that having this type of information in the audit
records would
> be useful, but doing it right would need many changes to the OS and goes
> beyond what CAPP/LSPP require.
It's simple to add the info without including which allowed you to access
the object. I agree, we aren't going to track which key let you in.
Agreed, including that information would be useful, even if CAPP doesn't
directly require it.
Already some userspace apps drop capabilities.
Okay, but it's only security relevant from the CC point of view if the
security target actually makes a distinction based on capabilities.
Voluntarily giving up rights isn't interesting if you don't make claims
that this increases security. Adding additional capabilities would be
security relevant, but currently this simply causes the application to be
considered a trusted process, same as a standard suid root process.
-Klaus