I'd like feedback on an idea for a change in this design that has been brought to my attention...
Instead of introducing a new user space tunable to determine how to handle an audit failure, what if we used the kernel's audit_failure variable that already exists? The mapping of actions would be as follows: #define AUDIT_FAIL_SILENT 0 --> ignore #define AUDIT_FAIL_PRINTK 1 --> log #define AUDIT_FAIL_PANIC 2 --> terminate The kernel variable could be written to a file in /sys/fs and the library function would read that. This variable can be changed via auditctl -f or set in audit.rules. This would eliminate the need to have the admin remember and tune another audit-related variable. What value-add do people see in introducing a new audit failure tunable, or is using the kernel audit_failure variable sufficient? Feedback is appreciated. Thanks, Lisa Lisa Smith wrote: > I've updated the audit failure design proposal based on the discussion > during the 5/2/06 LSPP concall. Please review the updated proposal > attached below and reply with comments. > > Thanks, > Lisa > > > ------------------------------------------------------------------------ > > Discussions about the original design proposal during the LSPP concall > on 5/2/06 brought forth the following issues which are addressed in > this updated proposal: > > - Using wrapper functions would require updating too many > applications to use the functionality > - An application should have a limited set of allowed actions: > 1) stop the service, 2) ignore the error, or 3) log an > error message. > - Add a query function instead of a function that will take action > in the library space. > > Further investigation into the current applications calling > audit_open() and audit_send_user_message() provided some interesting > findings. The most important finding was that the shadow-utils apps > actually use two wrapper functions, audit_help_open() and > audit_logger(), to call audit_open() and audit_send_user_message(), > respectively. Therefore, any changes to the action that should be > taken after an audit failure can be instrumented in audit_help_open() > and audit_logger() and all shadow-utils will perform this action. This > alleviates the concern that over 300 calls would need to be modified > to enable the shadow-utils applications use the new functionality. > Further investigation is underway to ensure that all shadow-utils > applications use these wrappers in the same general manner. > > The investigation also showed that the applications varied widely in > how they handled an audit failure. For example, cups does not check > for an audit failure. passwd exits if an error is returned that > is outside of the allowable errors if audit is not compiled into the > kernel. amtu does not check for an audit failure. hwclock prints an > error message to stderr and then returns a no permission error. > shadow-utils' audit_help_open() function prints a message > to stderr and then exits if audit_open() returns an error other than > the acceptable error if audit is not built into the kernel; > audit_logger() does not check the return value from > audit_send_user_message(). > > Given the wide range of actions taken after an audit failure, an ideal > solution would allow any applications that want to use the new > functionality to easily use it, but not force functionality upon > applications that already perform appropriate audit error handling. > This propsoal provides such a solution. > > > Problem > ------- > Currently, each service and application is responsible for determining > the action to take when the audit subsystem is unavailable (stop the > action or service, continue on, log a message). It is not ideal to > require all application developers to determine the appropriate action > to take and to incorporate this into the application. Different > customers may want different actions taken, and this flexibility is > not possible if the action is hard-coded into the application. > > NOTE: This project does not extend the kernel space audit failure > functionality specified by the audit_failure global variable. This > is an audit failure configurable for user space, used when the > functions audit_open() or audit_send_user_message() return an error. > > Design Overview > --------------- > The solution to this problem would be most flexible and give > administrators the most control if the action were determined by > information in a configuration file that an administrator could > modify. The configuration file will be read by a new function > that can be optionally called after a call to audit_open() or > audit_send_user_message() returns failure, and appropriate action, > based on the information found in the configuration file, will be > returned as an enum value. The application can then use this enum > value to perform the appropriate action. > > A default configuration file is provided (/etc/auditfail.default). > However, any application that would like to have control over the > specific action performed after an audit failure can provide an > application-specific file named /etc/auditfail.<application>. > > The only information necessary in the configuration file is one > line stating if the application should 1) continue to > run normally and ignore the audit failure, 2) terminate the service or > action, or 3) log a message in an error file. > > The new function will live in libaudit and any services and > applications that would like to use this functionality would need > to call the new function after the call to audit_open() or > audit_send_user_message() returns failure. > > The following is a list of services that will be updated to use > this new functionality. Any additional audit records to new > services (ie, device allocator) should also be modified to use > the new query function. > > cups > hwclock > passwd > > NOTE: shadow-utils still under investigation > > Actions allowed: > Terminate the action or service > Ignore the error (continue on as normal) > Log an error message > > New function > ------------ > The new function will live in libaudit. > > enum auditFailType audit_failure_action(char *file) > This function will read the configuration file specified by the file > argument and return an enum value to the caller. If the file > argument is NULL, a default configuration file will be used. > > Sample config file > ------------------ > # Action to take when call to the audit subsystem fails. > # This file will be parsed by audit_failure_action() and > # the appropriate enum will be returned to the calling > # application. > # > # Options are: ignore, log, terminate > terminate > > Manpage updates > --------------- > The audit_open() man page will be updated to let application developers > know about the new query function that should be used when audit_open() > returns failure. The sample code listed in the man page will also be > updated to show how the query function should be used. > > > ------------------------------------------------------------------------ > > -- > redhat-lspp mailing list > [email protected] > https://www.redhat.com/mailman/listinfo/redhat-lspp > -- redhat-lspp mailing list [email protected] https://www.redhat.com/mailman/listinfo/redhat-lspp
