[PATCH] capabilities: do not audit log BPRM_FCAPS on set*id
by Richard Guy Briggs
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
Signed-off-by: Richard Guy Briggs <rgb(a)redhat.com>
---
security/commoncap.c | 5 +++--
1 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/security/commoncap.c b/security/commoncap.c
index 14540bd..8f6bedf 100644
--- a/security/commoncap.c
+++ b/security/commoncap.c
@@ -594,16 +594,17 @@ skip:
/*
* Audit candidate if current->cap_effective is set
*
- * We do not bother to audit if 3 things are true:
+ * We do not bother to audit if 4 things are true:
* 1) cap_effective has all caps
* 2) we are root
* 3) root is supposed to have all caps (SECURE_NOROOT)
+ * 4) we are running a set*id binary
* Since this is just a normal root execing a process.
*
* Number 1 above might fail if you don't have a full bset, but I think
* that is interesting information to audit.
*/
- if (!cap_issubset(new->cap_effective, new->cap_ambient)) {
+ if (!is_setid && !cap_issubset(new->cap_effective, new->cap_ambient)) {
if (!cap_issubset(CAP_FULL_SET, new->cap_effective) ||
!uid_eq(new->euid, root_uid) || !uid_eq(new->uid, root_uid) ||
issecure(SECURE_NOROOT)) {
--
1.7.1
8 years
Re: audit.rules not fully loading into memory according to auditctl -l
by warron.french
Yes, certainly.
I had a 1.7GB messages file in /var/log; so I moved it manually out of the
way. Then I rebooted.
After doing that, I didn't see anything at all about auditd in the new
/var/log/messages.
I have finally gotten it down to 13 audit rules, all still Action Rules
only for some reason, that are not loading into memory from
/etc/audit/audit.rules.
Those action rules are using -F path= attributes.
What is really interesting is that I have other action rules using -F path=
that are getting into memory!
These are the files that are not:
/usr/libexec/kde4/kdesud
/usr/libexec/openssh/ssh-keysign
/usr/libexec/polkit-1/polkit-agent-helper-1
/usr/libexec/pt_chown
/usr/libexec/utempter/utempter
/usr/lib/vmware-tools/bin32/vmware-user-suid-wrapper
/usr/lib/vmware-tools/bin64/vmware-user-suid-wrapper
/usr/sbin/lockdev
/usr/sbin/postdrop
/usr/sbin/postqueue
/usr/sbin/suexec
/usr/sbin/userhelper
/usr/sbin/usernetctl
I did the following to evaluate---
for FIL in `cat audit_action_rules_File | grep -v "^#" | awk '{ print $4 }'
| cut -d= -f 2`; do
echo "Checking for ${FIL}."
if [ -f ${FIL} ]; then
echo "${FIL} is present."
else
echo "The file ${FIL} is not present."
fi
done
Checking for /usr/libexec/kde4/kdesud.
*The file /usr/libexec/kde4/kdesud is not present.*
Checking for /usr/libexec/openssh/ssh-keysign.
/usr/libexec/openssh/ssh-keysign is present.
Checking for /usr/libexec/polkit-1/polkit-agent-helper-1.
/usr/libexec/polkit-1/polkit-agent-helper-1 is present.
Checking for /usr/libexec/pt_chown.
/usr/libexec/pt_chown is present.
Checking for /usr/libexec/utempter/utempter.
/usr/libexec/utempter/utempter is present.
Checking for /usr/lib/vmware-tools/bin32/vmware-user-suid-wrapper.
*The file /usr/lib/vmware-tools/bin32/vmware-user-suid-wrapper is not
present.*
Checking for /usr/lib/vmware-tools/bin64/vmware-user-suid-wrapper.
*The file /usr/lib/vmware-tools/bin64/vmware-user-suid-wrapper is not
present.*
Checking for /usr/sbin/lockdev.
/usr/sbin/lockdev is present.
Checking for /usr/sbin/postdrop.
/usr/sbin/postdrop is present.
Checking for /usr/sbin/postqueue.
/usr/sbin/postqueue is present.
Checking for /usr/sbin/suexec.
/usr/sbin/suexec is present.
Checking for /usr/sbin/userhelper.
/usr/sbin/userhelper is present.
Checking for /usr/sbin/usernetctl.
/usr/sbin/usernetctl is present.
I am still missing all 15 Watch rules in memory.
--------------------------
Warron French
On Wed, Apr 12, 2017 at 2:05 PM, Steve Grubb <sgrubb(a)redhat.com> wrote:
> On Wednesday, April 12, 2017 1:40:51 PM EDT warron.french wrote:
> > Didn't know to check there.
>
> Shouldn't we keep the discussion on the mail list so others can learn from
> it?
>
> -Steve
>
> > Also, I noticed something interesting after tracing through rules I
> > captured from audit.rules (and sorting) and capturing rules from auditctl
> > (also sorting).
> >
> > Here are some things I observed:
> >
> > 1. -a -F path= <path/to/file> are not getting loaded at all.
> > 2. -a -S call1 -S call2 -S call3 -S callN are being altered into a
> > relative format of -a -S call1,call2,call3,callN (I was not
> > expecting this at all).
> >
> > I will look at the syslog output from auditctl in /var/log/messages
> > (correct?).
> >
> >
> >
> > --------------------------
> > Warron French
> >
> > On Wed, Apr 12, 2017 at 1:22 PM, Steve Grubb <sgrubb(a)redhat.com> wrote:
> > > On Wednesday, April 12, 2017 12:51:03 PM EDT warron.french wrote:
> > > > Hello, I am writing a Puppet Module to deliver updates of audit.rules
> > > > and
> > > > auditd.conf configurations to RHEL6 and RHEL7 machines.
> > > >
> > > > The files are laid down correctly for both RHEL6 and RHEL7 within the
> > > >
> > > > appropriate directories:
> > > > - RHEL6 = /etc/audit/audit.rules, for
> > > > - RHEL7 = /etc/audit/rules.d/audit.rules
> > > >
> > > > Anyway, the results for all RHEL7 machines (client versus Server) are
> > > > perfect. The audit.rules are all laid down as expected, and after a
> > >
> > > reboot
> > >
> > > > of the system the rules are all 100% in place - just as I need.
> > > >
> > > > The problem is when they are laid down on RHEL6 clients versus
> Servers,
> > >
> > > the
> > >
> > > > behaviors are very different.
> > > >
> > > > For RHEL6 clients I have the following intentions and loaded into
> > > > memory:
> > > >
> > > > 118 (-a) Action Rules in audit.rules file 118 Action Rules are
> > > > loaded into memory (YAY!)
> > > >
> > > > * 15 (-w) Watch Rules* in audit.rules file * 15 Watch Rules
> are
> > > > loaded into memory* (YAY!)
> > > >
> > > > 133 Total Rules in audit.rules files 133 Total Rules
> into
> > > > memory (YAY!)
> > > >
> > > >
> > > > For RHEL6 Server; however, I have the following results:
> > > >
> > > > 118 (-a) Action Rules in audit.rules file 105 Action Rules are
> loaded
> > > > into memory (FAIL)
> > > >
> > > > * 15 (-w) Watch Rules* in audit.rules file * 0 Watch Rules are
> > >
> > > loaded
> > >
> > > > into memory* (HUGE FAIL)
> > > >
> > > > 133 Total Rules in audit.rules files 105 Total Rules into
> > >
> > > memory
> > >
> > > > (YAY!)
> > > >
> > > >
> > > > This is really a big problem for me. Can someone help?
> > >
> > > Was there anything in syslog from auditctl?
> > >
> > > When auditctl runs across a rule with syntax errors, the default
> action is
> > > to
> > > log it and stop. This way it causes the most noticeable thing to
> happen.
> > > However, some people don't like this behavior so they pass a '-c'
> option
> > > near
> > > the beginning of the rules. This causes it to keep processing but
> > > ultimately
> > > return an error at exit. Some people didn't like that auditctl
> returned an
> > > error, so the '-i' option was created for people that can't be bothered
> > > with
> > > failure even in the face of failure.
> > >
> > > Check for a syntax error in the rules. It should be in syslog.
> > >
> > > -Steve
>
>
>
8 years
audit.rules not fully loading into memory according to auditctl -l
by warron.french
Hello, I am writing a Puppet Module to deliver updates of audit.rules and
auditd.conf configurations to RHEL6 and RHEL7 machines.
The files are laid down correctly for both RHEL6 and RHEL7 within the
appropriate directories:
- RHEL6 = /etc/audit/audit.rules, for
- RHEL7 = /etc/audit/rules.d/audit.rules
Anyway, the results for all RHEL7 machines (client versus Server) are
perfect. The audit.rules are all laid down as expected, and after a reboot
of the system the rules are all 100% in place - just as I need.
The problem is when they are laid down on RHEL6 clients versus Servers, the
behaviors are very different.
For RHEL6 clients I have the following intentions and loaded into memory:
118 (-a) Action Rules in audit.rules file 118 Action Rules are
loaded into memory (YAY!)
* 15 (-w) Watch Rules* in audit.rules file * 15 Watch Rules are
loaded into memory* (YAY!)
133 Total Rules in audit.rules files 133 Total Rules into
memory (YAY!)
For RHEL6 Server; however, I have the following results:
118 (-a) Action Rules in audit.rules file 105 Action Rules are loaded
into memory (FAIL)
* 15 (-w) Watch Rules* in audit.rules file * 0 Watch Rules are loaded
into memory* (HUGE FAIL)
133 Total Rules in audit.rules files 105 Total Rules into memory
(YAY!)
This is really a big problem for me. Can someone help?
--------------------------
Warron French
8 years
audit triggers sent email
by Maria Tsiolakki
Hello,
I have setup the audit log service (on red hat linux 7.3) and I have
placed rules such as when a user access a specif directory to log the
action in the audit log.I want to go a further step, and get an email
notification when this happens.
Can this be set up?
Thank you
Maria
**
8 years
rules.d on RHEL6
by warron.french
It appears that this directory is not used at all on RHEL6.
I know I have mentioned this before; but it's true. If I *move* my copy of
audit.rules from /etc/audit into the subdirectory rules.d and restart
audit; the audit.rules file is not recopied/regenerated or whatever by the
auditd.
This behavior is different from RHEL7; where if you delete the
/etc/audit/audit.rules file or move it to /etc/audit/rules.d/audit.rules;
the auditd functions as I expect.
Can someone please correct my understanding? Is the /etc/audit/rules.d
directory not supposed to be usable in RHEL6; but is in RHEL7?
--------------------------
Warron French
8 years
[RFC PATCH 0/4] Assorted audit fixes/improvements
by Paul Moore
Some miscellaneous audit patches that layer on top of the lock/queue
patch I posted earlier today. Unlike the lock/queue fix patch these
patches would go into the next branch and not the stable-4.11 branch.
I'll probably need to rebase the audit/next branch to merge these
patches, but that is something we'll worry about when the time comes.
---
Paul Moore (4):
audit: combine audit_receive() and audit_receive_skb()
audit: kernel generated netlink traffic should have a portid of 0
audit: store the auditd PID as a pid struct instead of pid_t
audit: use kmem_cache to manage the audit_buffer cache
include/linux/audit.h | 3 -
kernel/audit.c | 190 ++++++++++++++++++++++---------------------------
kernel/audit.h | 5 +
kernel/auditfilter.c | 14 ++--
4 files changed, 96 insertions(+), 116 deletions(-)
8 years
SECCOMP event results
by Steve Grubb
Hello,
When I run across a seccomp event, does it always mean that the syscall
failed? Is there any possibility that the syscall may have continued (such as
while being traced)?
-Steve
8 years
Rebasing the audit/next tree
by Paul Moore
Hello all,
This is notice that I'm going to be rebasing the audit/next tree. I
don't like doing this outside the normal process, but we've got a few
patches in the queue which require it, and we've already had to rebase
the audit/stable-4.11 tree to deal with some locking/namespace issues.
The plan is to rebase the current audit/next branch on top of
audit/stable-4.11 (which is currently based on v4.11-rc3), and once
v4.11 is released, do a final audit/next rebase on top of v4.11 before
sending the patches to Linus. I realize this will likely mess up the
linux-next commit tracking, but this is a rare event for the
linux-audit tree so I'll ask for some forgiveness here.
The normal weekly testing should be unaffected since I normally test
the audit/next and audit/stable branches on top of the latest -rcX
release. In some way, this rebasing actually brings the branches
closer to what we actually test.
For those of you who have submitted patches that are still in the
queue, there is no need to resubmit your patches, I'll take care of
any merge conflicts that may arise. If something proves to be
problematic, I may reach out to you for help in rebasing your patch,
but I don't think it will come to that.
Thanks for your understanding,
-Paul
--
paul moore
www.paul-moore.com
8 years
[GIT PULL] Audit fixes for v4.11 (#3)
by Paul Moore
Hi Linus,
One more small audit fix, this should be the last for v4.11. Seth
Forshee noticed a problem where the audit retry queue wasn't being
flushed properly when audit was enabled and the audit daemon wasn't
running; this patches fixes the problem (see the commit description
for more details on the change). Both Seth and I have tested this and
everything looks good. Please merge.
Thanks,
-Paul
---
The following changes since commit ab6434a1377a768a1e6d3e6cf819eb21724a99c2:
audit: move audit_signal_info() into kernel/auditsc.c
(2017-03-27 14:30:06 -0400)
are available in the git repository at:
git://git.infradead.org/users/pcmoore/audit stable-4.11
for you to fetch changes up to 264d509637d95f9404e52ced5003ad352e0f6a26:
audit: make sure we don't let the retry queue grow without bounds
(2017-04-10 11:16:59 -0400)
----------------------------------------------------------------
Paul Moore (1):
audit: make sure we don't let the retry queue grow without bounds
kernel/audit.c | 67 ++++++++++++++++++++++++++----------------------------
1 file changed, 32 insertions(+), 35 deletions(-)
--
paul moore
security @ redhat
8 years
