From: Richard Guy Briggs <rgb@redhat.com>
To: linux-security-module@vger.kernel.org, linux-audit@redhat.com
Cc: Richard Guy Briggs <rgb@redhat.com>,
Andy Lutomirski <luto@kernel.org>,
"Serge E. Hallyn" <serge.hallyn@ubuntu.com>,
Kees Cook <keescook@chromium.org>,
James Morris <james.l.morris@oracle.com>,
Eric Paris <eparis@redhat.com>, Paul Moore <pmoore@redhat.com>,
Steve Grubb <sgrubb@redhat.com>
Subject: [RFC PATCH V2 0/4] capabilities: do not audit log BPRM_FCAPS on set*id
Date: Thu, 11 May 2017 16:42:39 -0400 [thread overview]
Message-ID: <cover.1494527628.git.rgb@redhat.com> (raw)
The audit subsystem is adding a BPRM_FCAPS record when auditing setuid
application execution (SYSCALL execve). This is not expected as it was
supposed to be limited to when the file system actually had capabilities
in an extended attribute. It lists all capabilities making the event
really ugly to parse what is happening. The PATH record correctly
records the setuid bit and owner. Suppress the BPRM_FCAPS record on
set*id.
See: https://github.com/linux-audit/audit-kernel/issues/16
The patch that resolves this issue is the third. The first and second just
massage the logic to make it easier to understand.
It would be possible to address the original issue with a change of
"!uid_eq(new->euid, root_uid) || !uid_eq(new->uid, root_uid)"
to
"!(uid_eq(new->euid, root_uid) || uid_eq(new->uid, root_uid))"
but it took me long enough to understand this logic that I don't think I'd be
doing any favours by leaving it this difficult to understand.
The final patch attempts to address all the conditions that need logging based
on mailing list conversations, recoginizing there is probably some duplication
in the logic, which is why I'm posting this as an RFC for some feedback.
Richard Guy Briggs (4):
capabilities: use macros to make the logic easier to follow and
verify
capabilities: invert logic for clarity
capabilities: fix logic for effective root or real root
capabilities: auit log other surprising conditions
security/commoncap.c | 55 ++++++++++++++++++++++++++++++++-----------------
1 files changed, 36 insertions(+), 19 deletions(-)
WARNING: multiple messages have this Message-ID (diff)
From: rgb@redhat.com (Richard Guy Briggs)
To: linux-security-module@vger.kernel.org
Subject: [RFC PATCH V2 0/4] capabilities: do not audit log BPRM_FCAPS on set*id
Date: Thu, 11 May 2017 16:42:39 -0400 [thread overview]
Message-ID: <cover.1494527628.git.rgb@redhat.com> (raw)
The audit subsystem is adding a BPRM_FCAPS record when auditing setuid
application execution (SYSCALL execve). This is not expected as it was
supposed to be limited to when the file system actually had capabilities
in an extended attribute. It lists all capabilities making the event
really ugly to parse what is happening. The PATH record correctly
records the setuid bit and owner. Suppress the BPRM_FCAPS record on
set*id.
See: https://github.com/linux-audit/audit-kernel/issues/16
The patch that resolves this issue is the third. The first and second just
massage the logic to make it easier to understand.
It would be possible to address the original issue with a change of
"!uid_eq(new->euid, root_uid) || !uid_eq(new->uid, root_uid)"
to
"!(uid_eq(new->euid, root_uid) || uid_eq(new->uid, root_uid))"
but it took me long enough to understand this logic that I don't think I'd be
doing any favours by leaving it this difficult to understand.
The final patch attempts to address all the conditions that need logging based
on mailing list conversations, recoginizing there is probably some duplication
in the logic, which is why I'm posting this as an RFC for some feedback.
Richard Guy Briggs (4):
capabilities: use macros to make the logic easier to follow and
verify
capabilities: invert logic for clarity
capabilities: fix logic for effective root or real root
capabilities: auit log other surprising conditions
security/commoncap.c | 55 ++++++++++++++++++++++++++++++++-----------------
1 files changed, 36 insertions(+), 19 deletions(-)
--
To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
next reply other threads:[~2017-05-11 20:42 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-05-11 20:42 Richard Guy Briggs [this message]
2017-05-11 20:42 ` [RFC PATCH V2 0/4] capabilities: do not audit log BPRM_FCAPS on set*id Richard Guy Briggs
2017-05-11 20:42 ` [RFC PATCH V2 1/4] capabilities: use macros to make the logic easier to follow and verify Richard Guy Briggs
2017-05-11 20:42 ` Richard Guy Briggs
2017-05-12 5:35 ` Serge E. Hallyn
2017-05-12 5:35 ` Serge E. Hallyn
2017-05-12 11:37 ` Richard Guy Briggs
2017-05-12 11:37 ` Richard Guy Briggs
2017-05-12 13:50 ` Serge E. Hallyn
2017-05-12 13:50 ` Serge E. Hallyn
2017-05-11 20:42 ` [RFC PATCH V2 2/4] capabilities: invert logic for clarity Richard Guy Briggs
2017-05-11 20:42 ` Richard Guy Briggs
2017-05-11 20:42 ` [RFC PATCH V2 3/4] capabilities: fix logic for effective root or real root Richard Guy Briggs
2017-05-11 20:42 ` Richard Guy Briggs
2017-05-11 20:42 ` [RFC PATCH V2 4/4] capabilities: auit log other surprising conditions Richard Guy Briggs
2017-05-11 20:42 ` Richard Guy Briggs
2017-06-02 15:19 ` [RFC PATCH V2 0/4] capabilities: do not audit log BPRM_FCAPS on set*id Paul Moore
2017-06-02 15:19 ` Paul Moore
2017-06-02 18:03 ` Richard Guy Briggs
2017-06-02 18:03 ` Richard Guy Briggs
2017-06-02 19:30 ` Paul Moore
2017-06-02 19:30 ` Paul Moore
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=cover.1494527628.git.rgb@redhat.com \
--to=rgb@redhat.com \
--cc=eparis@redhat.com \
--cc=james.l.morris@oracle.com \
--cc=keescook@chromium.org \
--cc=linux-audit@redhat.com \
--cc=linux-security-module@vger.kernel.org \
--cc=luto@kernel.org \
--cc=pmoore@redhat.com \
--cc=serge.hallyn@ubuntu.com \
--cc=sgrubb@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.