[GIT PULL] Audit patches for 4.7
by Paul Moore
Hi Linus,
Four small audit patches for 4.7; two are simple cleanups around the audit
thread management code, one adds a tty field to AUDIT_LOGIN events, and the
final patch makes tty_name() usable regardless of CONFIG_TTY. Nothing
controversial, and it all passes our regression test. Please pull for 4.7.
Thanks,
-Paul
---
The following changes since commit b562e44f507e863c6792946e4e1b1449fbbac85d:
Linux 4.5 (2016-03-13 21:28:54 -0700)
are available in the git repository at:
git://git.infradead.org/users/pcmoore/audit stable-4.7
for you to fetch changes up to 188e3c5cd2b672620291e64a21f1598fe91e40b6:
tty: provide tty_name() even without CONFIG_TTY (2016-04-27 17:12:58 -0400)
----------------------------------------------------------------
Arnd Bergmann (1):
tty: provide tty_name() even without CONFIG_TTY
Jiri Slaby (1):
audit: cleanup prune_tree_thread
Paul Moore (1):
audit: we don't need to __set_current_state(TASK_RUNNING)
Richard Guy Briggs (1):
audit: add tty field to LOGIN event
include/linux/audit.h | 24 ++++++++++++++++++++++++
include/linux/tty.h | 4 +++-
kernel/audit.c | 30 ++++++++++--------------------
kernel/audit_tree.c | 12 +++++-------
kernel/auditsc.c | 8 ++++++--
5 files changed, 48 insertions(+), 30 deletions(-)
--
paul moore
security @ redhat
9 years
auditd hangs
by Andrey Kulikov
Hi everyone,
We have several thousands hosts running CentOS 7. Every day auditd stops
writing audit.log on 2-3 of them (different hosts every day). Here is
strace output:
# strace -p 17306
Process 17306 attached
epoll_wait(7, {}, 64, 59743) = 0
epoll_wait(7, {}, 64, 59743) = 0
epoll_wait(7, {}, 64, 59743) = 0
epoll_wait(7, {}, 64, 59743) = 0
epoll_wait(7, {}, 64, 59743) = 0
epoll_wait(7, {}, 64, 59743) = 0
epoll_wait(7, {}, 64, 59743) = 0
epoll_wait(7, 7fb4c3302be0, 64, 59743) = -1 EINTR (Interrupted system call)
--- SIGHUP {si_signo=SIGHUP, si_code=SI_USER, si_pid=2728, si_uid=0} ---
write(8, "\1\0\0\0\0\0\0\0", 8) = 8
rt_sigreturn() = -1 EINTR (Interrupted system call)
epoll_wait(7, {{EPOLLIN, {u32=8, u64=4294967304}}}, 64, 59743) = 1
read(8, "\1\0\0\0\0\0\0\0", 8) = 8
sendto(3, "\20\0\0\0\362\3\5\0\4\0\0\0\0\0\0\0", 16, 0,
{sa_family=AF_NETLINK,
pid=0, groups=00000000}, 12) = 16
poll([{fd=3, events=POLLIN}], 1, 500) = 1 ([{fd=3, revents=POLLIN}])
recvfrom(3,
"$\0\0\0\2\0\0\0\4\0\0\0\232C\0\0\0\0\0\0\20\0\0\0\362\3\5\0\4\0\0\0"...,
8988, MSG_PEEK|MSG_DONTWAIT, {sa_family=AF_NETLINK, pid=0, groups=00000000},
[12]) = 36
recvfrom(3,
"$\0\0\0\2\0\0\0\4\0\0\0\232C\0\0\0\0\0\0\20\0\0\0\362\3\5\0\4\0\0\0"...,
8988, MSG_DONTWAIT, {sa_family=AF_NETLINK, pid=0, groups=00000000},
[12]) = 36
epoll_wait(7, {{EPOLLIN, {u32=3, u64=4294967299}}}, 64, 59743) = 1
recvfrom(3,
"N\0\0\0\362\3\0\0\4\0\0\0\232C\0\0\363\3\0\0\217C\0\0unconfin"..., 8988,
MSG_DONTWAIT, {sa_family=AF_NETLINK, pid=0, groups=00000000}, [12]) = 80
mmap(NULL, 8392704, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_ANONYMOUS|MAP_STACK,
-1, 0) = 0x7fb4be5da000
mprotect(0x7fb4be5da000, 4096, PROT_NONE) = 0
clone(child_stack=0x7fb4bedd9eb0,
flags=CLONE_VM|CLONE_FS|CLONE_FILES|CLONE_SIGHAND|CLONE_THREAD|CLONE_SYSVSEM|CLONE_SETTLS|CLONE_PARENT_SETTID|CLONE_CHILD_CLEARTID,
parent_tidptr=0x7fb4bedda9d0, tls=0x7fb4bedda700,
child_tidptr=0x7fb4bedda9d0)
= 3014
epoll_wait(7,
... and line "epoll_wait(7," repeated infinitely.
auditd restart helps, but I thint this is a bug. What can be causes of
the problem?
Thanks for your help in advance!
--
Regards,
Andrey Kulikov.
9 years
exclude filter action ignored?
by Richard Guy Briggs
Hi Steve,
Can you confirm that the exclude filter action parameter is ignored? I
can't find any evidence in the kernel or in userspace that the action
value is actually honoured. In fact, looking at the manpage for
auditctl(8), the wording of the action contradicts the intuitive meaning
of that filter name. And as a matter of fact, I find discussion of it
here:
https://www.redhat.com/archives/linux-audit/2005-October/msg00020.html
In auditctl, setopt() calls audit_rule_setup() which calls lookup_filter() and
lookup_action(), then calls audit_rule_fieldpair_data() none of which
check when parsing the AUDIT_MSGTYPE field.
During rule addition, in kernel/auditfilter.c:audit_rule_change() and
callees AUDIT_FILTER_TYPE is never checked for either action but simply
copied.
When called from audit_log_start() in
kernel/auditfilter.c:audit_filter_type(), the state is never checked, so
either AUDIT_NEVER or AUDIT_ALWAYS actions gives the same result which
is to ignore that message type.
- RGB
--
Richard Guy Briggs <rgb(a)redhat.com>
Kernel Security Engineering, Base Operating Systems, Red Hat
Remote, Ottawa, Canada
Voice: +1.647.777.2635, Internal: (81) 32635
9 years
ausearch produces a Warning
by Warron S French
Hello all,
I have audit logging working exactly as I want it now (thanks to you all), but when running ausearch on various systems (not all, which tells me something isn't consistent) I get a warning:
Warning - freq is non-zero and incremental flushing not selected.
I saw on the internet a post that (involved you Steve Grubb) in reply to someone else from Date: Fri, 19 May 2006 15:01:37 -0400
Here is the part of the thread where you replied Steve:
* From: Steve Grubb <sgrubb redhat com>
* To: Linda Knippers <linda knippers hp com>
* Cc: linux-audit redhat com
* Subject: Re: Double addition of rule yields two log messages
* Date: Fri, 19 May 2006 15:01:37 -0400
________________________________
On Friday 19 May 2006 14:47, Linda Knippers wrote:
> But why does ausearch care?
Ausearch doesn't care about this particular setting. Its looking at the config
to find the log files. The parser is what cares and it is what emitted this
warning. As such, you can use ausearch to make sure your config is sane
before sending sighup to reconfigure the audit daemon.
> Seems like if anything cared it would be the auditd but I can't find an
> error or warning from it anywhere.
Should be in the syslog.
-Steve
The question I have is, even this says "Warning" does it mean there is something I really need to be intensely looking into to prevent issues to come?
I do not fully understand the impact of what the flush parameter. I am also trying to comply with a STIG as well; I think that's what has caused this message to be presented.
Thank you,
Warron French, MBA, SCSA
9 years, 1 month
Re: Why exclude unset auid in STIG rules
by Steve Grubb
On Wednesday, May 11, 2016 06:28:11 PM Wyatt, Curtis wrote:
> I don't understand why the STIG audit rules have -F auid!=4294967295 in it.
> If auid is unset, why wouldn't you still want to see the events in the
> logs?
When a user logs in, the auid gets set to the uid that they used to login
with. Daemons are not user sessions and have the loginuid set to -1. The auid
representation is an unsigned 32 bit integer. So, -1 becomes 4294967295. The
rules use a directive like this: -F auid>=1000 to trigger on user activity. It
turns out that would trigger on daemons doing something because 4294967295 is
greater than 1000. So, we exclude daemons because user activity is the prime
target.
-Steve
9 years, 1 month
Why exclude unset auid in STIG rules
by Wyatt, Curtis
I don't understand why the STIG audit rules have -F auid!=4294967295 in it. If auid is unset, why wouldn't you still want to see the events in the logs?
Curtis
9 years, 1 month
aureport style output for syslog?
by Jonathan Kelley
Heya guys,
I'm looking to get the same level of verbosity as `aureport --tty` to local
syslog, /var/log/audit/audit.log shows me more PID's and stuff but not args
to commands like aureport... audispd doesn't solve this does it? Not sure
which output method pulls the args verbosity.
- Jon
9 years, 1 month
Any problem with making auditd log readable by the adm group?
by intrigeri
Hi,
in Debian, the convention for many log files is to make them readable
by members of the adm group. We're considering doing the same for the
auditd logs, in order to make apparmor-notify work out-of-the-box.
The maintainer of auditd in Debian would like to know what's your take
on it. What kind of problem could be created if we did that?
Cheers,
--
intrigeri
9 years, 1 month
[PATCH] Add userspace support for session ID user filter.
by Richard Guy Briggs
Add support for the session ID user filter by adding the field name
"sessionid" using the kernel defined macro value AUDIT_SESSIONID.
https://github.com/linux-audit/audit-kernel/issues/4
RFE: add a session ID filter to the kernel's user filter
Signed-off-by: Richard Guy Briggs <rgb(a)redhat.com>
---
trunk/lib/fieldtab.h | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/trunk/lib/fieldtab.h b/trunk/lib/fieldtab.h
index bf48c95..88cf8ea 100644
--- a/trunk/lib/fieldtab.h
+++ b/trunk/lib/fieldtab.h
@@ -31,6 +31,7 @@ _S(AUDIT_SGID, "sgid" )
_S(AUDIT_FSGID, "fsgid" )
_S(AUDIT_LOGINUID, "auid" )
_S(AUDIT_LOGINUID, "loginuid" )
+_S(AUDIT_SESSIONID, "sessionid" )
_S(AUDIT_PERS, "pers" )
_S(AUDIT_ARCH, "arch" )
_S(AUDIT_MSGTYPE, "msgtype" )
--
1.7.1
9 years, 1 month
ANN: Linux Audit is now on GitHub
by Paul Moore
I'd like to announce that the Linux Audit project is now on GitHub:
-> https://github.com/linux-audit
We've already migrated much of the information on Steve Grubb's Red Hat people
page, and the remaining items will be migrated soon. The move to GitHub
allows us to consolidate audit development in one place while at the same time
supporting issue tracking and documentation/wikis.
The Linux Audit Project currently consists of four different repositories,
each is described below:
* audit-documentation
This repository holds various audit resources, but the majority of the
information is contained in the associated wiki. The information that used to
reside on Steve's Red Hat people page now resides here.
* audit-userspace
This is a mirror of the userspace subversion repository. Those who are
interested in submitting patches should continue to submit patches via the
mailing list.
* audit-kernel
This is a mirror of the kernel repository. This repository will be used to
track upstream bugs and feature requests (via GitHub issues), and the wiki
will be used to document and track kernel development efforts. Those are are
interested in submitting patches should continue to submit patches via the
mailing list.
* audit-testsuite
This is a relatively new project, designed to be similar to the selinux-
testsuite project, and intended to be a relatively simple regression test for
the kernel. If anyone is interested in contributing, patches are welcome via
the mailing list or GitHub pull requests!
If you have any questions about this transition, or any of the repositories
above, please send them to the mailing list.
--
paul moore
security @ redhat
9 years, 1 month
