A related question:  On receipt of a AUDIT_USER message, we log the pid and uid, but not the loginuid.  

Is it ok to force the user-space code to search through previous log entries to determine the correct loginuid, or would we prefer to send the loginuid in the log entry?

> > A related question: ??On receipt of a AUDIT_USER message, we log the > > pid and uid, but not the loginuid. ?? > > You mean in af_netlink.c? That info comes from the netlink credentials. No, I meant in audit.c:audit_receive_msg().

It would come from find_task_by_pid(pid)->audit_context->loginuid. But only if we need it, which is what I'm asking :) (LSPP seems to require it)

If the kernel can't reliably access the needed information, the audit userspace message function must be modified to work synchronously, so that the trusted program doesn't proceed until the kernel had a chance to pick up the data.

It's definitely a CAPP and LSPP requirement to have the correct user identity contained reliably in the audit record. Having it glued together in userspace would be acceptable as long as it's transparent to the admin and doesn't have problems with log file rollover etc.

On Friday 07 January 2005 16:58, Serge Hallyn wrote: > A related question: ??On receipt of a AUDIT_USER message, we log the

> and uid, but not the loginuid. ?? You mean in af_netlink.c? That info comes from the netlink credentials.

Attached is a first stab at setting loginuid through /proc/$$/loginuid. Compiled and tested here.

This I was wondering about. loginuid is a uid_t, which is kernel_uid32_t, which is an unsigned int. So I have to ask again: do we really want to use -1 as a default?

I see places in the kernel setting -1 for uid on init, though. For example, look at security/keys/keyctl.c

Sounds good. On this topic, Stephen, were you going to send the loginuid inheritence patch to lkml?

Serge Hallyn wrote: > Attached is a first stab at setting loginuid through /proc/$$/loginuid. > Compiled and tested here. > I would recommend replacing the capable(CAP_AUDIT_CONTROL) call in proc_loginuid_write with a LSM hook - possibly security_audit_set_loginid(...). I do not think we even need the check in proc_loginuid_read. I previously stated that level of responsibility implied by setting the login id lies somewhere between writing an audit message and controlling the audit system. My intention was to further segregate the operations through SELinux. Since this is no longer a netlink message, SELinux can not distinguish the setting of a loginid from the other audit control operations. In fact, it would be nice to see all of the audit code not using capable at all, but rather using meaningful LSM hooks that result in capable() calls in the dummy and capabilities module (this would include the previous patch for audit.c and friends - sorry for not thinking of this earlier). This will allow LSMs to implement fine-grained control over the configuration of the audit subsystem that cannot be achieved though the use of capable() - without adding a few more capabilities that is, but there is only one left :)

On Thu, 2005-01-27 at 13:39, Serge Hallyn wrote: >Are you considering posting a patch to convert the CAP_AUDIT_* checks >with lsm hooks? The other audit actions can still be distinguished >(though not as nicely) through selinux_netlink_send, but as you say, not >setting and reading loginuid, which I think could only be done through >policy at the moment. ... I agree that distinguishing setting of the loginuid from complete control of the audit framework would be useful, but it should be easy to replace your capable call with a LSM hook in the future.