* Query regarding the lib audit-userspace @ 2022-09-13 16:53 Manojkiran Eda 2022-09-13 17:25 ` Steve Grubb 0 siblings, 1 reply; 4+ messages in thread From: Manojkiran Eda @ 2022-09-13 16:53 UTC (permalink / raw) To: linux-audit@redhat.com [-- Attachment #1.1: Type: text/plain, Size: 652 bytes --] Hi team, I was working on leveraging the libaudit shared library to generate audit events from a user space daemon. I have been using the audit_open as well as audit_log_acct_message() API’s to send message to the kernel audit subsystem. From the man pages I understand that every message to the kernel audit subsystem would get an ACK back. Now my question is does the daemon[single threaded] consuming this libaudit for sending events using audit_log_acct_message() API be blocked until it gets an ACK back from the kernel ? If yes , is there a way to not have the application blocked during this period ? Thanks, Manoj [-- Attachment #1.2: Type: text/html, Size: 2503 bytes --] [-- Attachment #2: Type: text/plain, Size: 107 bytes --] -- Linux-audit mailing list Linux-audit@redhat.com https://listman.redhat.com/mailman/listinfo/linux-audit ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Query regarding the lib audit-userspace 2022-09-13 16:53 Query regarding the lib audit-userspace Manojkiran Eda @ 2022-09-13 17:25 ` Steve Grubb 2022-09-14 8:40 ` Manojkiran Eda 0 siblings, 1 reply; 4+ messages in thread From: Steve Grubb @ 2022-09-13 17:25 UTC (permalink / raw) To: linux-audit@redhat.com Hello, On Tuesday, September 13, 2022 12:53:32 PM EDT Manojkiran Eda wrote: > I was working on leveraging the libaudit shared library to generate audit > events from a user space daemon. I have been using the audit_open as well > as audit_log_acct_message() API’s to send message to the kernel audit > subsystem. audit_log_acct_message() is meant to send events related to a user's account. For example, pam and shadow-utils uses it. > From the man pages I understand that every message to the > kernel audit subsystem would get an ACK back. Yes. This is to let you know if there was a problem such as lack of permissions. > Now my question is does the daemon[single threaded] consuming this libaudit > for sending events using audit_log_acct_message() API be blocked until it > gets an ACK back from the kernel ? Yes. In general, sending audit events should be rare. > If yes , is there a way to not have the application blocked during this > period ? The requirements that we normally need to adhere to is that if the audit event fails, then whatever the user was going to do needs to be prevented. If you really need to keep moving, send the event on it's own thread so that your application is not waiting. For example, sshd forks the user session so that it can keep processing other logins. But on that fork, it waits for the responses to make it easier to tear down the session if sending an audit event fails. Or, another approach would be to write the whole thing down to calling sendto and then you can wait however you want. I think putting on it's own thread is simplest. But as I said in the beginning, should there be a problem logging the event, can you undo whatever the event was for if you keep going? -Steve -- Linux-audit mailing list Linux-audit@redhat.com https://listman.redhat.com/mailman/listinfo/linux-audit ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Query regarding the lib audit-userspace 2022-09-13 17:25 ` Steve Grubb @ 2022-09-14 8:40 ` Manojkiran Eda 2022-09-16 21:03 ` Burn Alting 0 siblings, 1 reply; 4+ messages in thread From: Manojkiran Eda @ 2022-09-14 8:40 UTC (permalink / raw) To: Steve Grubb, linux-audit@redhat.com [-- Attachment #1.1: Type: text/plain, Size: 3358 bytes --] Hi Steve, Thanks for the reply. I am actually trying to enable audit events support for an embedded webserver (bmcweb<https://github.com/openbmc/bmcweb>) which implements the DMTF Redfish specification. The idea is to use libaudit to generate server operations related audit events. For example * Authentication related events * Power on related events * Code update related events And the design principle is that all the apps in LF OpenBMC<https://github.com/openbmc/openbmc> are single threaded & use dbus as our communication model & we use event loops for processing events from dbus. I agree that probably it makes sense to disallow a particular operation If we fail to send an event. But can’t we do it without blocking using the event loops ? is there some example of doing that for sending audit events ? As it is a webserver we would want it to as much responsive as possible. And also , how much time does the daemon have to wait for a ACK reply ? does it have a time out of some sort ? I understand that the API that we discussed above does the send as well as receive part, are there specific API’s for just send & receive separately ? so that I could probably add the file descriptor to the event loop and invoke the receive API whenever we get a reply ACK from the kernel. Thank, Manoj From: Steve Grubb <sgrubb@redhat.com> Date: Tuesday, 13 September 2022 at 10:55 PM To: linux-audit@redhat.com <linux-audit@redhat.com> Cc: ManojKiran Eda <manojkiran.eda@gmail.com> Subject: Re: Query regarding the lib audit-userspace Hello, On Tuesday, September 13, 2022 12:53:32 PM EDT Manojkiran Eda wrote: > I was working on leveraging the libaudit shared library to generate audit > events from a user space daemon. I have been using the audit_open as well > as audit_log_acct_message() API’s to send message to the kernel audit > subsystem. audit_log_acct_message() is meant to send events related to a user's account. For example, pam and shadow-utils uses it. > From the man pages I understand that every message to the > kernel audit subsystem would get an ACK back. Yes. This is to let you know if there was a problem such as lack of permissions. > Now my question is does the daemon[single threaded] consuming this libaudit > for sending events using audit_log_acct_message() API be blocked until it > gets an ACK back from the kernel ? Yes. In general, sending audit events should be rare. > If yes , is there a way to not have the application blocked during this > period ? The requirements that we normally need to adhere to is that if the audit event fails, then whatever the user was going to do needs to be prevented. If you really need to keep moving, send the event on it's own thread so that your application is not waiting. For example, sshd forks the user session so that it can keep processing other logins. But on that fork, it waits for the responses to make it easier to tear down the session if sending an audit event fails. Or, another approach would be to write the whole thing down to calling sendto and then you can wait however you want. I think putting on it's own thread is simplest. But as I said in the beginning, should there be a problem logging the event, can you undo whatever the event was for if you keep going? -Steve [-- Attachment #1.2: Type: text/html, Size: 9570 bytes --] [-- Attachment #2: Type: text/plain, Size: 107 bytes --] -- Linux-audit mailing list Linux-audit@redhat.com https://listman.redhat.com/mailman/listinfo/linux-audit ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Query regarding the lib audit-userspace 2022-09-14 8:40 ` Manojkiran Eda @ 2022-09-16 21:03 ` Burn Alting 0 siblings, 0 replies; 4+ messages in thread From: Burn Alting @ 2022-09-16 21:03 UTC (permalink / raw) To: Manojkiran Eda, Steve Grubb, linux-audit@redhat.com [-- Attachment #1.1: Type: text/plain, Size: 5081 bytes --] Manoj, I would counsel against using auditd as your local logging repository in favour of say syslog or journald or managed local files. Where applications have used auditd for their log recording, I have seen - auditd is already busy with the kernel space messages (consider execve monitoring on a process execution heavy server) and the queueing of messages slows the application - should you implement a queuing thread and the application queues a message but for one reason or another the queue is lost you have failed to record the message by the additional delay of the message residing in a queue for a long time (i.e. auditd is busy with kernel events) - as Steve suggests, if your ICT security certification process requires accurate/guaranteed event logs, and you queue the log, if you can't write it out how do you prevent the user action. - applications do not use the appropriate message format (e.g. the main content of your message is not in <key>'='<value> format) resulting in the very erroneous processing of auditd message processing - you force any centralised logging capability to apply additional effort do extract the application related logs from the kernel/system related logs. Any or all of the above could prevent the use of your application in environments with stringent ICT Security certification processes. RegardsBurn Alting On Wed, 2022-09-14 at 08:40 +0000, Manojkiran Eda wrote: > Hi Steve, > > Thanks for the reply. > > I am actually trying to enable audit events support for an embedded webserver > (bmcweb) which implements the DMTF Redfish specification. > The idea is to use libaudit to generate server operations related audit events. > For example > > > Authentication related eventsPower on related eventsCode update related events > > > And the design principle is that all the apps in LF > OpenBMC are single threaded & use dbus as our communication model & we use event > loops for processing events from dbus. I agree that probably it makes sense to > disallow a particular operation If we fail to send > an event. But can’t we do it without blocking using the event loops ? is there > some example of doing that for sending audit events ? As it is a webserver we > would want it to as much responsive as possible. > > And also , how much time does the daemon have to wait for a ACK reply ? does it > have a time out of some sort ? I understand that the API that we discussed above > does the send as > well as receive part, are there specific API’s for just send & receive separately > ? so that I could probably add the file descriptor to the event loop and invoke > the receive API whenever we get a reply ACK from the kernel. > > > Thank, > Manoj > > > > From: > Steve Grubb <sgrubb@redhat.com> > > Date: Tuesday, 13 September 2022 at 10:55 PM > > To: linux-audit@redhat.com <linux-audit@redhat.com> > > Cc: ManojKiran Eda <manojkiran.eda@gmail.com> > > Subject: Re: Query regarding the lib audit-userspace > > > Hello, > > > > On Tuesday, September 13, 2022 12:53:32 PM EDT Manojkiran Eda wrote: > > > I was working on leveraging the libaudit shared library to generate audit > > > events from a user space daemon. I have been using the audit_open as well > > > as audit_log_acct_message() API’s to send message to the kernel audit > > > subsystem. > > > > audit_log_acct_message() is meant to send events related to a user's > > account. For example, pam and shadow-utils uses it. > > > > > From the man pages I understand that every message to the > > > kernel audit subsystem would get an ACK back. > > > > Yes. This is to let you know if there was a problem such as lack of > > permissions. > > > > > Now my question is does the daemon[single threaded] consuming this libaudit > > > for sending events using audit_log_acct_message() API be blocked until it > > > gets an ACK back from the kernel ? > > > > Yes. In general, sending audit events should be rare. > > > > > If yes , is there a way to not have the application blocked during this > > > period ? > > > > The requirements that we normally need to adhere to is that if the audit > > event fails, then whatever the user was going to do needs to be prevented. If > > you really need to keep moving, send the event on it's own thread so that > > your application is not waiting. For example, sshd forks the user session so > > that it can keep processing other logins. But on that fork, it waits for the > > responses to make it easier to tear down the session if sending an audit > > event fails. > > > > Or, another approach would be to write the whole thing down to calling sendto > > and then you can wait however you want. I think putting on it's own thread is > > simplest. But as I said in the beginning, should there be a problem logging > > the event, can you undo whatever the event was for if you keep going? > > > > -Steve > > > > > > > > > > --Linux-audit mailing listLinux-audit@redhat.com > https://listman.redhat.com/mailman/listinfo/linux-audit [-- Attachment #1.2: Type: text/html, Size: 11597 bytes --] [-- Attachment #2: Type: text/plain, Size: 107 bytes --] -- Linux-audit mailing list Linux-audit@redhat.com https://listman.redhat.com/mailman/listinfo/linux-audit ^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2022-09-16 21:06 UTC | newest] Thread overview: 4+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2022-09-13 16:53 Query regarding the lib audit-userspace Manojkiran Eda 2022-09-13 17:25 ` Steve Grubb 2022-09-14 8:40 ` Manojkiran Eda 2022-09-16 21:03 ` Burn Alting
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.