[PATCH] audit: always enable syscall auditing when supported and audit is enabled
by Paul Moore
To the best of our knowledge, everyone who enables audit at compile
time also enables syscall auditing; this patch simplifies the Kconfig
menus by removing the option to disable syscall auditing when audit
is selected and the target arch supports it.
Signed-off-by: Paul Moore <pmoore(a)redhat.com>
---
init/Kconfig | 11 +++--------
1 file changed, 3 insertions(+), 8 deletions(-)
diff --git a/init/Kconfig b/init/Kconfig
index c24b6f7..d4663b1 100644
--- a/init/Kconfig
+++ b/init/Kconfig
@@ -299,20 +299,15 @@ config AUDIT
help
Enable auditing infrastructure that can be used with another
kernel subsystem, such as SELinux (which requires this for
- logging of avc messages output). Does not do system-call
- auditing without CONFIG_AUDITSYSCALL.
+ logging of avc messages output). System call auditing is included
+ on architectures which support it.
config HAVE_ARCH_AUDITSYSCALL
bool
config AUDITSYSCALL
- bool "Enable system-call auditing support"
+ def_bool y
depends on AUDIT && HAVE_ARCH_AUDITSYSCALL
- default y if SECURITY_SELINUX
- help
- Enable low-overhead system-call auditing infrastructure that
- can be used independently or with another kernel subsystem,
- such as SELinux.
config AUDIT_WATCH
def_bool y
5 years, 9 months
[RFC PATCH 0/7] audit: clean up audit queue handling
by Richard Guy Briggs
This set of patches cleans up a number of corner cases in the management
of the audit queue.
Richard Guy Briggs (7):
audit: don't needlessly reset valid wait time
audit: include auditd's threads in audit_log_start() wait exception
audit: allow systemd to use queue reserves
audit: wake up threads if queue switched from limited to unlimited
audit: allow audit_cmd_mutex holders to use reserves
audit: wake up audit_backlog_wait queue when auditd goes away.
audit: wake up kauditd_thread after auditd registers
kernel/audit.c | 20 +++++++++++++++-----
1 files changed, 15 insertions(+), 5 deletions(-)
8 years, 4 months
Re: audit 2.5.1 released
by Manuel Scunthorpe
Dear Steve,thanks for your helpful observations. I was able to modify the PKGBUILD and successfully build the package, and then build e4rat-lite which was my ultimate aim. Sadly it didn't seem to work in Arch Linux due to the kernel config options, e4rat-lite-collect didn't collect anything, complained about being unable to log anything due to a bad file descriptor and there was a message at boot saying Cannot open audit socket, which was similar to what auditctl said in the terminal. Of course it might work and I've got something else wrong, it doesn't look encouraging though without CONFIG_AUDIT enabled. But I was just looking at my Void Linux kernel options:CONFIG_AUDIT=y
CONFIG_HAVE_ARCH_AUDITSYSCALL=y
CONFIG_AUDITSYSCALL=y
CONFIG_AUDIT_WATCH=y
CONFIG_AUDIT_TREE=y
This looks more promising so I will have to try it here instead sometime, although what I will have to build to fulfill the various builddeps I don't yet know. Would it be OK if I tried to make an 'audit' package for Void Linux if they want one? There isn't one in the repo at present, so if I get a working build then I might as well share it. It could take a while to get to that point though, and that's assuming I can get everything to work in Void and don't end up using some other readahead utility altogether or accidentally corrupting my filesystem. But I can be happy I'm building audit correctly now.I will try and pass on your comments about zos servers and openldap-devel to the Arch packagers as I can only take credit for the confusion over the systemd support option in my earlier PKGBUILD.
Here's my successful modified PKGBUILD with the correct checksum for 2.5.1, which downloads and builds cleanly:# Edit /etc/makepkg.conf: staticlibs not !staticlibs or they are deleted by makepkg.
# $Id: PKGBUILD 146469 2015-11-10 05:04:55Z thestinger $
# Maintainer: Daniel Micay <danielmicay(a)gmail.com>
# Contributor: <kang(a)insecure.ws>
# Contributor: Massimiliano Torromeo <massimiliano.torromeo(a)gmail.com>
# Contributor: Connor Behan <connor.behan(a)gmail.com>
# Contributor: henning mueller <henning(a)orgizm.net>
pkgname=audit
pkgver=2.5.1
pkgrel=1
pkgdesc='Userspace components of the audit framework'
url='https://people.redhat.com/sgrubb/audit'
arch=(i686 x86_64)
depends=(krb5 libcap-ng)
makedepends=(libldap swig linux-headers python)
license=(GPL)
options=(emptydirs)
groups=('modified')
backup=(
etc/libaudit.conf
etc/audit/auditd.conf
etc/audisp/audispd.conf
etc/audisp/audisp-remote.conf
etc/audisp/plugins.d/af_unix.conf
etc/audisp/plugins.d/au-remote.conf
etc/audisp/plugins.d/syslog.conf
)
source=("$url/$pkgname-$pkgver.tar.gz")
sha256sums=('3c6ec72d8c16d1e85cc2b9c260cc6440319eb294cb54ca41a7bbe9283cc9f421')
install=$pkgname.install
build() {
cd $pkgname-$pkgver
export PYTHON=/usr/bin/python3
./configure \
--prefix=/usr \
--sbindir=/usr/bin \
--sysconfdir=/etc \
--libexecdir=/usr/lib/audit \
--with-python=yes \
--enable-gssapi-krb5=yes \
--enable-systemd=no \
--with-libcap-ng=yes \
--disable-zos-remote \
--enable-static=yes
make
}
package() {
cd $pkgname-$pkgver
make DESTDIR="$pkgdir" install
cd "$pkgdir"
install -d var/log/audit
rm -rf etc/rc.d etc/sysconfig usr/lib/audit
sed -ri 's|/sbin|/usr/bin|' \
etc/audit/*.conf \
etc/audisp/plugins.d/*.conf
8 years, 5 months
audit review question
by Warron S French
Hello, I hope you all are well and meeting your own professional challenges very well.
I have a scenario that I need a little help understanding how to work through in an isolated environment of 1 server and 6 workstations (7 machines).
The 7 machines are all running CentOS-6.7 and selinux = disabled.
All 6 workstations are configured through rsyslog.conf to send audit data to the server, and I have (but apparently not successfully configured general system messages to also report back to the same server).
I am using the conventional filesystems for each, but the directory structure below is different.
For audit, I use, /var/log/audit/2016/04/27/wk{1..6}_audit.log the directory per day and per month and per year are auto created (miraculously).
For system messages, and I know this isn't the forum to get help on this so I will only list the directory is - /var/log/2016/04/27/wk{1..6}_syslog.log.
Now that I am doing this, and successfully, I want to test that the security auditors will be able to do their job properly, as well as I am trying to comply with some security constraint that requires me to centralize the logdata into a single server (hence the major driver for all of this).
I know that there is the aureport and ausearch command, but I am not sure that I am able to figure out the correct command-line structure to test that audit-data is getting into the appropriate file, on each day of the year, on a per serverName basis.
If a real-world situation occurred that the Security Auditors were asking to find out how many machines did userX attempt to log into, what would be the appropriate command for the example audit directory I listed above (/var/log/audit/2016/04/27/wk{1..6}_audit.log), because I am not sure I am running the command with the appropriate switches to scan the files properly?
I used:
* aureport -if /var/log/audit/2016/04/27/ and it didn't like the input,
* aureport -if /var/log/audit/2016/04/27/* and it didn't like the input,
am I using the command improperly?
Warron French, MBA, SCSA
8 years, 6 months
Centralized Logging question #2
by Warron S French
If I centralize audit logging through rsyslog, and I have each of the remote machines' /etc/rsyslog.conf to use the same generic audit.log file name instead of customizing the audit logs with something like; HOSTNAME-audit.log, because ausearch apparently only looks for a file specifically of the format audit.log...
Will the log-data submitted from the various hosts be consolidated into a single file? Will the ausearch command then be usable with the -if argument?
Warron French, MBA, SCSA
8 years, 6 months
Excluding stat syscall logging for specific path
by Vincas Dargis
Hi,
When playing/learning with auditd, I wanted to log events when apache fails to access file.
Here's the rules I used in Debian Wheezy (same on Jessie and and current latest Testing):
-a exit,never -F arch=b64 -S stat -F path=/var/www/server-status -k web
-a exit,always -F arch=b64 -S stat -F uid=www-data -F success=0 -k web
/var/www/server-status file is non-existant, it's just alias for accessing mod_status information (
http://.../server-status path is accessed by munin regularly) so I wanted to minimise noise by that exit,never rule.
But I can't get it work.
I have more in-depth post in Debian forums [1] if that helps, but in short, should this work in general?
Thanks!
[1] http://forums.debian.net/viewtopic.php?f=5&t=128092
8 years, 6 months
audit 2.5.2 released
by Steve Grubb
Hello,
I've just released a new version of the audit daemon. It can be downloaded
from http://people.redhat.com/sgrubb/audit. It will also be in rawhide
soon. The ChangeLog is:
- Fix memory leak caused by unneeded reference in auparse python bindings
- Revise function hiding technique to better protect audit ABI
- Interpret old-auid, exit syscall parameters
- Create local_events config option to auditd
- Create write_logs option for auditd and deprecate NOLOG log_format option
This release is mostly to get an updated auparse library in circulation that
does not have the memory leak in the get_timestamp function. Offhand I don't
know of any problems besides the one bug report. The bug has been there for
about 8 years with no other reports so it might not affect much. But, I'd
rather be safe than sorry.
The other things that people should be aware of is 2 new auditd configuration
options. In the last release there was an unannounced command line config
option to auditd, -a. This enabled an aggregate only mode. I decided long term
it might be better as a auditd.conf option. Its now the local_events option.
The default is "yes". If it's set to "no", then it only logs daemon and
network originating events. This allows the audit daemon to be put into a
container for the sole purpose of aggregating events from other systems.
The other new auditd.conf config option is write_logs. In working on the audit
event enrichment option, I found that we need to decouple an overused idiom in
the log_format option. There was a NOLOG option there that decides if we want
to write events to disk. But it turns out that we might not want to write
events to disk but we do want to enrich events for the plugins or remote
logging. That presents a conflict where we need to separate them. If you
currently have log_format = NOLOG, the you should now set write_logs = no. You
can then put log_format = raw and it won't do any harm. For the time being, a
NOLOG log_format setting will override write_logs to "no" so that its
backwards compatible.
Please let me know if you run across any problems with this release.
-Steve
8 years, 6 months
Re: PID's Mapping
by Deepika Sundar
Is there any way that can be suggested as to map PID's of namespace in
global?
On Mon, Apr 18, 2016 at 8:47 PM, Paul Moore <paul(a)paul-moore.com> wrote:
> Please ask your question on the mailing list so that everyone can benefit.
>
> On Mon, Apr 18, 2016 at 1:34 AM, Deepika Sundar
> <sundar.deepika18(a)gmail.com> wrote:
> > How it can be achieved ,Can I get any idea on this?
> >
> > On Fri, Apr 15, 2016 at 4:12 AM, Paul Moore <paul(a)paul-moore.com> wrote:
> >>
> >> On Wed, Apr 13, 2016 at 1:43 AM, sowndarya kumar
> >> <sowndarya.nadar(a)gmail.com> wrote:
> >> > Hi
> >> >
> >> > Is there any way to map the PID's seen in the namespace application
> with
> >> > the
> >> > PID's seen in global?
> >> > If it can be done please provide the documentation or idea on how it
> can
> >> > be
> >> > done.
> >>
> >> In general the audit subsystem doesn't pay attention to namespaces,
> >> all PIDs reported to userspace are reported with respect to the init
> >> namespace.
> >>
> >> --
> >> paul moore
> >> www.paul-moore.com
> >>
> >> --
> >> Linux-audit mailing list
> >> Linux-audit(a)redhat.com
> >> https://www.redhat.com/mailman/listinfo/linux-audit
> >
> >
>
>
>
> --
> paul moore
> www.paul-moore.com
>
8 years, 6 months
