All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Serge E. Hallyn" <serue@us.ibm.com>
To: Eric Paris <eparis@redhat.com>
Cc: linux-kernel@vger.kernel.org, linux-audit@redhat.com,
	sgrubb@redhat.com, morgan@kernel.org, viro@ZenIV.linux.org.uk
Subject: Re: [PATCH -v2 3/4] AUDIT: collect info when execve results in caps in pE
Date: Thu, 6 Nov 2008 13:58:56 -0600	[thread overview]
Message-ID: <20081106195856.GA30017@us.ibm.com> (raw)
In-Reply-To: <1225999615.3300.177.camel@localhost.localdomain>

Quoting Eric Paris (eparis@redhat.com):
> So here's the problem....  I can't fail this syscall, it's too late.  I

Oh, right...

> can do a couple of things.
> 
> 1) waste lots of space in the execve record so we know memory has
> already been allocated
> 2) just ignore the memory failure and don't worry about it.  We are
> still going to get the fcaps info from the patch record and should be
> able to piece together the starting and finishing caps by looking at
> past audit records if you really need it.
> 3) I can call audit_log_lost().  I don't think we know are this time
> that we really needed this record, but this is the 'safest' approach.
> If people have their machines set to panic on lost records we would
> panic.   Honestly though, if we don't have enough memory to satisfy this
> request (we're talking about 72 bytes or something?) we are going to
> fail the next audit message, so doing it now would be just fine.
> 
> I vote #2 since I don't think we are really going to have any lose of
> info.  But if people want it I'll go #3 since I don't think it will hurt
> anything.

2 sounds reasonable to me.  Reckon sgrubb will speak up if it violates
some audit requirement.

thanks,
-serge

  reply	other threads:[~2008-11-06 19:58 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-11-03 20:17 [PATCH -v2 1/4] CAPABILITIES: add cpu endian vfs caps structure Eric Paris
2008-11-03 20:17 ` Eric Paris
2008-11-03 20:17 ` [PATCH -v2 2/4] AUDIT: output permitted and inheritable fcaps in PATH records Eric Paris
2008-11-03 20:17   ` Eric Paris
2008-11-03 20:17 ` [PATCH -v2 3/4] AUDIT: collect info when execve results in caps in pE Eric Paris
2008-11-03 20:17   ` Eric Paris
2008-11-04 16:35   ` Serge E. Hallyn
2008-11-04 16:35     ` Serge E. Hallyn
2008-11-04 19:07     ` Eric Paris
2008-11-04 19:07       ` Eric Paris
2008-11-04 19:28       ` Serge E. Hallyn
2008-11-06 19:26     ` Eric Paris
2008-11-06 19:26       ` Eric Paris
2008-11-06 19:58       ` Serge E. Hallyn [this message]
2008-11-03 20:17 ` [PATCH -v2 4/4] AUDIT: emit new record type showing all capset information Eric Paris
2008-11-03 20:17   ` Eric Paris
2008-11-04 16:55   ` Serge E. Hallyn
2008-11-06 19:03     ` Eric Paris
2008-11-06 19:03       ` Eric Paris
2008-11-04 16:45 ` [PATCH -v2 1/4] CAPABILITIES: add cpu endian vfs caps structure Serge E. Hallyn
2008-11-04 16:45   ` Serge E. Hallyn

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20081106195856.GA30017@us.ibm.com \
    --to=serue@us.ibm.com \
    --cc=eparis@redhat.com \
    --cc=linux-audit@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=morgan@kernel.org \
    --cc=sgrubb@redhat.com \
    --cc=viro@ZenIV.linux.org.uk \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.