Move loginuid(accountability information) to the task_struct. Why are
you using "loginuid" for accountability ?
What if two different users login using the same "loginuid" ?
Also, what is the advantage of using NETLINK sockets? It looks like
the information is passed to user-space for no-reason. The same
information will be passed back to the kernel by the syslog routines.
What is the point in doing such processing. Why are you not writing
records directly from the kernel to the audit file?
Regards
Surinder
On Fri, 14 Jan 2005 18:58:42 -0600, Serge E. Hallyn <serue(a)us.ibm.com> wrote:
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
>
--
Linux-audit mailing list
Linux-audit(a)redhat.com
http://www.redhat.com/mailman/listinfo/linux-audit