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
