Most audit control messages are sent over netlink. In order to properly log the identity of the sender of audit control messages, we would like to add the loginuid to the netlink_creds structure, as
On Fri, 4 Feb 2005, Serge E. Hallyn wrote: Most audit control messages are sent over netlink. In order to properly log the identity of the sender of audit control messages, we would like to add the l
Stephen Smalley wrote: On Tue, 2005-02-08 at 01:04, Patrick McHardy wrote: Reception of netlink messages in the kernel happens in the context of the sending process, so you can simply call audit_get_
I think it would be better to leave the loginuid in the payload of the audit packets, not put it into generic netlink structures. The only time it's possibly worth verifying it is for the case where
Yes, when kernel receives a message, it can be processed in context of another process. This happens with rtnetlink, which queues messages when someone holds netadmin semaphore and processing of bac
CAP_AUDIT_WRITE is needed, but not CAP_AUDIT_CONTROL, which is needed to set the loginuid. Of course, an LSM could check at security_netlink_send whether the login_uid in the payload is the same as t
If the audit subsystem truly needs to include the loginuid in audit messages generated upon processing netlink messages, then I think it belongs in the control buffer as per your patch. Alexey has co
This means sendmsg hook would set the SID? And in that case, you'd stomp on loginuid for audit messages unless they are special cased. The loginuid is special case to audit, it doesn't make sense to
I was referring to a separate field for use by security modules, not re-use of the same field being proposed for the loginuid. Yes, it would be set by the security_netlink_send hook. The principal pr
if (down_trylock(&audit_netlink_sem)) return; with plain down(&audit_netlink_sem); I am sorry, this is wrong. Dequeue may happen in another process context in any case. Could you explain how this ca
More packets may be queued by another sender while audit_receive() is still processing the original one, so it will process them too. -- Stephen Smalley <sds@xxxxxxxxxxxxxx> National Security Agency
This makes sense to me. Just an extension of existing eff_cap and would be used by security modules for each netlink packet. I just don't see it making sense to add another credential for a special c
I'm not entirely sure the check is needed anyway. This is a trusted application sending audit messages. Why shouldn't it be permitted to log auditable events which were triggered by someone _else_? I
Then it comes back to the question of how to protect loginuid. If it can be spoofed by someone with CAP_AUDIT_WRITE, then it shouldn't be write protected by CAP_AUDIT_CONTROL. thanks, -chris -- Linux
Here's an example of what I mean. It's quite rough, doesn't yet eliminate any of the code that it eventually could, and doesn't deal with broadcast. I gave it a quick test with audit netlink, and it
I'm not sure I agree with that. With CAP_AUDIT_WRITE you _can't_ modify the loginuid of the audit logs of your own actions. You can only modify the loginuid on the messages you pull out of thin air a
Why not just call the security handler from the security_netlink_send() function, which is already called by netlink_sendmsg()? Note that SELinux (thanks to work by James Morris a while back) does ap