From: "Serge E. Hallyn" <serue@us.ibm.com>
To: "Andrew G. Morgan" <morgan@kernel.org>
Cc: linux-audit@redhat.com, linux-kernel@vger.kernel.org,
viro@zeniv.linux.org.ok.redhat.com
Subject: Re: [PATCH 3/4] AUDIT: audit when fcaps increase the permitted or inheritable capabilities
Date: Tue, 21 Oct 2008 14:16:25 -0500 [thread overview]
Message-ID: <20081021191625.GA4657@us.ibm.com> (raw)
In-Reply-To: <48FD6E49.6060104@kernel.org>
Quoting Andrew G. Morgan (morgan@kernel.org):
> -----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.
True.
... except if (!issecure(SECURE_NOROOT) && uid==0) I guess?
And then it also might be interesting in the case where
(!issecure(SECURE_NOROOT) && uid==0) and pP is not full.
> > 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?
It might fail because fP contains bits not in pP', right? That's
probably interesting to auditors.
-serge
WARNING: multiple messages have this Message-ID (diff)
From: "Serge E. Hallyn" <serue@us.ibm.com>
To: "Andrew G. Morgan" <morgan@kernel.org>
Cc: Eric Paris <eparis@redhat.com>,
linux-kernel@vger.kernel.org, linux-audit@redhat.com,
viro@zeniv.linux.org.ok, sgrubb@redhat.com
Subject: Re: [PATCH 3/4] AUDIT: audit when fcaps increase the permitted or inheritable capabilities
Date: Tue, 21 Oct 2008 14:16:25 -0500 [thread overview]
Message-ID: <20081021191625.GA4657@us.ibm.com> (raw)
In-Reply-To: <48FD6E49.6060104@kernel.org>
Quoting Andrew G. Morgan (morgan@kernel.org):
> -----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.
True.
... except if (!issecure(SECURE_NOROOT) && uid==0) I guess?
And then it also might be interesting in the case where
(!issecure(SECURE_NOROOT) && uid==0) and pP is not full.
> > 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?
It might fail because fP contains bits not in pP', right? That's
probably interesting to auditors.
-serge
next prev parent reply other threads:[~2008-10-21 19:16 UTC|newest]
Thread overview: 24+ 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:25 ` Eric Paris
2008-10-20 22:26 ` [PATCH 1/4] CAPABILITIES: add cpu endian vfs caps structure Eric Paris
2008-10-20 22:26 ` Eric Paris
2008-10-21 5:50 ` Andrew G. Morgan
2008-10-21 13:22 ` Eric Paris
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 ` Eric Paris
2008-10-20 22:26 ` [PATCH 3/4] AUDIT: audit when fcaps increase the permitted or inheritable capabilities Eric Paris
2008-10-20 22:26 ` Eric Paris
2008-10-21 5:53 ` Andrew G. Morgan
2008-10-21 19:16 ` Serge E. Hallyn [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-22 14:14 ` Serge E. Hallyn
2008-10-23 4:13 ` Andrew G. Morgan
2008-10-29 21:58 ` Eric Paris
2008-10-29 21:58 ` Eric Paris
2008-10-30 13:35 ` Serge E. Hallyn
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
2008-10-20 22:26 ` 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=20081021191625.GA4657@us.ibm.com \
--to=serue@us.ibm.com \
--cc=linux-audit@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=morgan@kernel.org \
--cc=viro@zeniv.linux.org.ok.redhat.com \
/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.