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 <[email protected]> > > Date: Tuesday, 13 September 2022 at 10:55 PM > > To: [email protected] <[email protected]> > > Cc: ManojKiran Eda <[email protected]> > > 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 [email protected] > https://listman.redhat.com/mailman/listinfo/linux-audit
-- Linux-audit mailing list [email protected] https://listman.redhat.com/mailman/listinfo/linux-audit
