LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: "Andrew G. Morgan" <morgan@kernel.org>
To: Eric Paris <eparis@redhat.com>
Cc: linux-kernel@vger.kernel.org, linux-audit@redhat.com,
	viro@zeniv.linux.org.ok, sgrubb@redhat.com, serue@us.ibm.com
Subject: Re: [PATCH 3/4] AUDIT: audit when fcaps increase the permitted or inheritable capabilities
Date: Mon, 20 Oct 2008 22:53:13 -0700	[thread overview]
Message-ID: <48FD6E49.6060104@kernel.org> (raw)
In-Reply-To: <20081020222612.3895.6710.stgit@paris.rdu.redhat.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Eric Paris wrote:
> Any time fcaps are used to increase a processes pP or pE we will crate a new
> audit record which contains the entire set of known information about the 
> executable in question, fP, fI, fE, version and includes the parent processes
> pE, pI, pP.  This record type will only be emitted from execve syscalls.

I'm confused by the choice of when to log this event.

File capabilities are required to give a process 'any' active
capabilities. That is they don't affect pI -> pI', but without fI or fP,
the post-execve() process is guaranteed to have no pP or pE capabilities.

Logging execve()s where there is only an increase in capabilities seems
wrong to me. To me it seems equally important to log any event where an
execve() yields pP != 0.

> diff --git a/security/commoncap.c b/security/commoncap.c
> index 888b292..9bb285d 100644
> --- a/security/commoncap.c
> +++ b/security/commoncap.c
> @@ -8,6 +8,7 @@
>   */
>  
>  #include <linux/capability.h>
> +#include <linux/audit.h>
>  #include <linux/module.h>
>  #include <linux/init.h>
>  #include <linux/kernel.h>
> @@ -320,6 +321,8 @@ static int get_file_caps(struct linux_binprm *bprm)
>  
>  	rc = bprm_caps_from_vfs_caps(&vcaps, bprm);
>  
> +	audit_log_bprm_fcaps(bprm, &vcaps);
> +

When rc != 0, the execve() will fail. Is it appropriate to log in this case?

Cheers

Andrew
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFI/W5F+bHCR3gb8jsRAhM9AJ9oJL4PmdtMwHEkN0Xh0ZTHBlJPzgCfVT/8
1Rq4wgGWftqpaVXBmeAsEi8=
=W8R9
-----END PGP SIGNATURE-----

  reply	other threads:[~2008-10-21  5:54 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-10-20 22:25 [PATCH 0/4] Audit support for file capabilities Eric Paris
2008-10-20 22:26 ` [PATCH 1/4] CAPABILITIES: add cpu endian vfs caps structure Eric Paris
2008-10-21  5:50   ` Andrew G. Morgan
2008-10-21 13:22     ` Eric Paris
2008-10-20 22:26 ` [PATCH 2/4] AUDIT: output permitted and inheritable fcaps in PATH records Eric Paris
2008-10-20 22:26 ` [PATCH 3/4] AUDIT: audit when fcaps increase the permitted or inheritable capabilities Eric Paris
2008-10-21  5:53   ` Andrew G. Morgan [this message]
2008-10-21 19:16     ` Serge E. Hallyn
2008-10-22 12:51       ` Andrew G. Morgan
2008-10-22 14:14         ` Serge E. Hallyn
2008-10-23  4:13           ` Andrew G. Morgan
2008-10-29 21:58             ` Eric Paris
2008-10-30 13:35               ` Serge E. Hallyn
2008-10-20 22:26 ` [PATCH 4/4] AUDIT: emit new record type showing all capset information Eric Paris

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=48FD6E49.6060104@kernel.org \
    --to=morgan@kernel.org \
    --cc=eparis@redhat.com \
    --cc=linux-audit@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=serue@us.ibm.com \
    --cc=sgrubb@redhat.com \
    --cc=viro@zeniv.linux.org.ok \
    --subject='Re: [PATCH 3/4] AUDIT: audit when fcaps increase the permitted or inheritable capabilities' \
    /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

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).