Re: [PATCH] LSPP audit enablement: storing selinux ocontext and scontext
On Monday 29 August 2005 16:28, Stephen Smalley wrote:
On Mon, 2005-08-29 at 16:18 -0500, Dustin Kirkland wrote:
> Ok, so the audit_panic() code seems to still be under discussion. One
> thing that's important to realize is that audit_panic() does not
> necessarily panic the kernel. Depending on the value of audit_failure,
> it can 1) fail silently, 2) fail with only a KERN_ERR printk, or 3) it
> can panic the kernel. Let's come to a consensus on how these failures
> should be handled...
As I understand it, Steve G was suggesting that when possible, it should
be propagating an error up the call chain, ultimately leading to an
error returned from the syscall, rather than doing any of the three
options listed above. That makes sense when collecting data for the
audit prior to the operation being performed, e.g.
audit_ipc_security_context. It doesn't make sense when attempting to
audit a completed syscall, e.g. audit_log_task_security_context, as the
operation has already completed.
It gets muddy when collecting information _during_ the operation, however.
Avoiding use of audit_panic in the file system, could get complicated. The
reason we'd want to avoid using audit_panic boils down to the potential
for lost records. If we fail silently on an -ENOMEM when trying to allocate
the audit aux data, the syscall continues on, the file system changes,
and we have no record of that change. If we fail with a panic, the file
system might have already changed before the panic, and when we
reboot and check the log, there'll be no record corresponding to that
change.
Now, what might be possible, is that we allocate the aux audit data before
the syscall can make any changes to the file system. This way, if the audit
subsystem is unable to allocate memory, it can fail without any inconsistent
behavior occurring (ie: failing out of a mkdir with -ENOMEM because of audit,
after the the directory has already been created) and prevent the loss of
an audit record by preventing the action itself.
In terms of audit, pre-allocation seems pretty darn good. If we can't audit,
we prevent the action from occuring. Seems right in line with the various
*PPs. But, I have to wonder if there's not a better solution out there? Any
suggestions?
If we went with audit panic, there's no guarantee that the change ever
makes it to disk before we panic, which means the auditable event is
effectively prevented. This is probably file system specific and an
unreliable assumption at best. But, I have to wonder what the state
of the system would be if we were getting these -ENOMEMs and how
effective pre-allocation would be. Let's say we're heavily loaded and
we're oscillating such that one second we have memory available
and the next we don't. We may get the pre-allocation, but then
what guarantee do we have that it'll get across the netlink into the
log?
Also, with the catch-all hooks in place, there could be multiple watches
collected in the same syscall, making it impossible to predict how much
memory to pre-allocate.
If we're allowed to lose some records under these conditions, then
it seems like panicing is the right solution. But if we're not, the
solution seems pretty muddy.
David and Klaus, I certainly would appreciate your inputs on the matter.
-tim