On Mon, 2005-08-29 at 17:57 -0400, Steve Grubb wrote:
On Monday 29 August 2005 17:18, Dustin Kirkland wrote:
> Hmmm... Steve: Can you point me to some places where you feel this
> might be necessary?
Any function that hooks the main part of the kernel and does auditing. For
example, audit_ipc_security_context. There's more...
Ok, I'll look around.
>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.
Which is inadequate - failing the syscall might also be appropriate and its
not an option in the 3 you mentioned. In the case of printk & ignore...the
syscall passes.
Ok, then anyone who disagrees with failing the syscall speak up now...
If this is the preferred operation, please say so. Klaus--I, too, am
calling for your input.
> I'd like to push this for inclusion in David's tree as
soon as possible.
I need to wait until I'm caught up to really review this patch.
I still think its too early for LSPP discussion since we haven't set out the
requirements
for what we are going to do in this round of development. Its likely to be
next week before I can look at this closely.
Ok, well I'm hoping to show some progress here on my side. I've been in
a holding pattern for a month since I originally sent this before OLS.
I still think it calls audit_panic too easy. How does SE Linux AVC
messages
get handled when it fails looking up something? Does it call audit_panic or
try to output the number? I think they should both match.
/me defers to Stephen's response...
BTW, does audit_set_macxattr need to NULL check after kstrdup?
I've looked at about a dozen calls to kstrdup() around the kernel, most
of which do not perform a NULL check, though some do. David offered the
suggestion of using kstrdup(), perhaps he has a recommendation?
:-Dustin