There is a bigger problem with the current loginuid assumptions. The
loginuid is stored on the audit_context. The audit_context is only
created when auditing has been enabled using auditctl, and an auditable
action has occurred.
Either we need to change the behavior to always create an audit_context
(with state=AUDIT_DISABLED) so long as AUDIT_SYSCALL is enabled, or we
need to move loginuid directly into the task_struct.
-serge
Quoting Stephen Smalley (sds(a)epoch.ncsc.mil):
On Fri, 2005-01-14 at 14:06, Serge Hallyn wrote:
> Changelog:
> 1/14/2005: Added several checks for error values which were missing.
> 1/07/2005: First version.
>
> Is this ready for lkml?
Why require CAP_AUDIT_CONTROL to read the loginuid? Programs like
newrole would like to have a more reliable user identity available than
the normal uid; we were having them extract the SELinux user identity
from the security context, but in Fedora, that is typically just user_u
due to the lack of integration of user management with policy.
--
Stephen Smalley <sds(a)epoch.ncsc.mil>
National Security Agency
--
Linux-audit mailing list
Linux-audit(a)redhat.com
http://www.redhat.com/mailman/listinfo/linux-audit