Re: Problems with auditd -- resolved
On Sat, 23 Sep 2006, Robert Watson wrote: Right now the id(1) command in -STABLE doesn't print audit properties of the process, but I've attached a patch that causes it to do so when id -a is run. If you could apply this patch and run id -a as root, that would be helpful. I've merged this patch to 6-STABLE, but we've renamed the flag -A so as not to conflict with a flag in Solaris. If you could let me know what the results of running id -A are, when running as root su'd from a number user that should be getting audited, that would be helpful. Thanks! Robert N M Watson Computer Laboratory University of Cambridge ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Problems with auditd -- resolved
On Fri, 22 Sep 2006, Joerg Pernfuss wrote:
On Sun, 17 Sep 2006 09:19:03 +0100 (BST)
Robert Watson [EMAIL PROTECTED] wrote:
I've just comitted a fix to syscalls.master and regenerated the remaining
system call files, which should correct the auditctl: Invalid Argument
error being returned by auditd. In short order, this fix should be on the
cvsup mirrors -- please let me know if it resolves the problem you were
experiencing.
Thank you for that quick fix Robert, but sadly I am still somewhat at a
loss. The auditd does run now, but does not write back any audit data at
all. I have run at least three full buildworlds during the time you see
below, set flags, deleted things, logged in, logged out, logged in via ssh
to the external interface, ssh'ed to localhost. No gain. /var/log/audit
looks like this:
snip
My audit_control file:
dir:/var/audit
flags:all
minfree:20
naflags:lo
My audit_user file:
root:all:no
elessar:all:no
This is somewhat troubling -- I have RELENG_6 audit running on a number of
boxes without problems. Your configuration looks reasonable, though. There
are a few things we can try. The first thing to look at is whether the audit
library and commands are having trouble parsing your configuration files for
some reason -- maybe there is extra white space, and we need to increase
tolerance of unexpected white space, for example. There's a tool in
src/contrib/openbsm/tools called audump, which parses the configuration files
and then spits out what it thinks it found to stdout. It's not built by
default, but it can be quite useful when debugging. You can build it by doing
the following in the tools directory:
-Wall -g -o /tmp/audump audump.c -lbsm
Then, as root, run:
/tmp/audump control
I believe there's a bug in audump's user database support currently, but at
the very least that will tell us if the control file is being properly parsed.
Ideally, the output will very much resemble your configuration file -- if
there's a significant difference, that could be the source of this problem.
Right now the id(1) command in -STABLE doesn't print audit properties of the
process, but I've attached a patch that causes it to do so when id -a is
run. If you could apply this patch and run id -a as root, that would be
helpful.
Robert N M Watson
Computer Laboratory
University of Cambridge
Index: Makefile
===
RCS file: /home/ncvs/src/usr.bin/id/Makefile,v
retrieving revision 1.11
diff -u -r1.11 Makefile
--- Makefile19 May 2004 21:06:36 - 1.11
+++ Makefile23 Sep 2006 12:23:40 -
@@ -1,10 +1,18 @@
# @(#)Makefile8.1 (Berkeley) 6/6/93
# $FreeBSD: src/usr.bin/id/Makefile,v 1.11 2004/05/19 21:06:36 dwmalone Exp $
+.include bsd.own.mk
+
PROG= id
WARNS?=6
LINKS= ${BINDIR}/id ${BINDIR}/groups
LINKS+=${BINDIR}/id ${BINDIR}/whoami
MAN= id.1 groups.1 whoami.1
+.if ${MK_AUDIT} != no
+CFLAGS+= -DUSE_BSM_AUDIT
+DPADD+=${LIBBSM}
+LDADD+=-lbsm
+.endif
+
.include bsd.prog.mk
Index: id.1
===
RCS file: /home/ncvs/src/usr.bin/id/id.1,v
retrieving revision 1.15
diff -u -r1.15 id.1
--- id.129 Apr 2005 08:37:52 - 1.15
+++ id.123 Sep 2006 12:30:46 -
@@ -53,6 +53,8 @@
.Fl P
.Op Ar user
.Nm
+.Fl a
+.Nm
.Fl g Op Fl nr
.Op Ar user
.Nm
@@ -84,6 +86,9 @@
Display the MAC label of the current process.
.It Fl P
Display the id as a password file entry.
+.It Fl a
+Display the process audit user ID and other process audit properties, which
+requires privilege.
.It Fl g
Display the effective group ID as a number.
.It Fl n
Index: id.c
===
RCS file: /home/ncvs/src/usr.bin/id/id.c,v
retrieving revision 1.27
diff -u -r1.27 id.c
--- id.c28 May 2006 12:32:30 - 1.27
+++ id.c23 Sep 2006 12:30:16 -
@@ -48,6 +48,10 @@
#include sys/param.h
#include sys/mac.h
+#ifdef USE_BSM_AUDIT
+#include bsm/audit.h
+#endif
+
#include err.h
#include errno.h
#include grp.h
@@ -60,6 +64,7 @@
void id_print(struct passwd *, int, int, int);
void pline(struct passwd *);
void pretty(struct passwd *);
+void auditid(void);
void group(struct passwd *, int);
void maclabel(void);
void usage(void);
@@ -73,9 +78,11 @@
struct group *gr;
struct passwd *pw;
int Gflag, Mflag, Pflag, ch, gflag, id, nflag, pflag, rflag, uflag;
+ int aflag;
const char *myname;
Gflag = Mflag = Pflag = gflag = nflag = pflag = rflag = uflag = 0;
+ aflag = 0;
myname = strrchr(argv[0], '/');
myname = (myname != NULL) ? myname + 1 : argv[0];
@@ -89,7 +96,7 @@
}
while ((ch = getopt(argc, argv,
- (isgroups || iswhoami) ? : PGMgnpru)) != -1)
+ (isgroups
Re: Problems with auditd -- resolved
On Sun, 17 Sep 2006 09:19:03 +0100 (BST) Robert Watson [EMAIL PROTECTED] wrote: Dear all, I've just comitted a fix to syscalls.master and regenerated the remaining system call files, which should correct the auditctl: Invalid Argument error being returned by auditd. In short order, this fix should be on the cvsup mirrors -- please let me know if it resolves the problem you were experiencing. Thanks, Thank you for that quick fix Robert, but sadly I am still somewhat at a loss. The auditd does run now, but does not write back any audit data at all. I have run at least three full buildworlds during the time you see below, set flags, deleted things, logged in, logged out, logged in via ssh to the external interface, ssh'ed to localhost. No gain. /var/log/audit looks like this: [EMAIL PROTECTED]: /home/elessar# ll /var/audit/ total 26 -r--r- 1 root audit 0 20 Sep 18:05 20060920160547.20060920160856 -r--r- 1 root audit 0 20 Sep 18:08 20060920160856.20060920161050 -r--r- 1 root audit 0 20 Sep 18:10 20060920161050.20060920161154 -r--r- 1 root audit 0 20 Sep 18:13 20060920161347.20060920161507 -r--r- 1 root audit 0 20 Sep 18:19 20060920161903.20060920161936 -r--r- 1 root audit 0 20 Sep 18:28 20060920162856.20060920162909 -r--r- 1 root audit 0 20 Sep 18:33 20060920163322.20060920163817 -r--r- 1 root audit 0 20 Sep 18:38 20060920163817.20060920164146 -r--r- 1 root audit 0 20 Sep 18:41 20060920164146.20060920164920 -r--r- 1 root audit 0 20 Sep 18:49 20060920164920.not_terminated -r--r- 1 root audit 0 20 Sep 18:51 20060920165153.20060920165243 -r--r- 1 root audit 0 20 Sep 18:52 20060920165243.20060920165330 -r--r- 1 root audit 0 20 Sep 18:53 20060920165330.20060920171512 -r--r- 1 root audit 0 20 Sep 19:16 20060920171650.20060920175312 -r--r- 1 root audit 0 20 Sep 19:55 20060920175539.20060921215850 -r--r- 1 root audit 0 22 Sep 00:00 20060921220046.not_terminated The old .not_terminated file is from me fiddling with the system. That is the output from /var/log/security - first system startup, then two `audit -n` -- everything seems to work fine. Sep 22 00:00:46 forseti auditd[604]: starting... Sep 22 00:00:46 forseti auditd[605]: dir = /var/audit Sep 22 00:00:46 forseti auditd[605]: New audit file is /var/audit/\ 20060921220046.not_terminated Sep 22 00:00:46 forseti auditd[605]: min free = 20 Sep 22 00:00:46 forseti auditd[605]: Registered 434 event to class mappings. Sep 22 00:00:46 forseti auditd[605]: Registered non-attributable event mask. Sep 22 00:00:46 forseti auditd[605]: Audit controls init successful Sep 22 00:04:05 forseti auditd[605]: wait_for_events: read 2 Sep 22 00:04:05 forseti auditd[605]: Got open new trigger Sep 22 00:04:05 forseti auditd[605]: dir = /var/audit Sep 22 00:04:05 forseti auditd[605]: New audit file is /var/audit/\ 20060921220405.not_terminated Sep 22 00:04:05 forseti auditd[605]: renamed /var/audit/20060921220046\ .not_terminated to /var/audit/ 20060921220046.20060921220405 Sep 22 00:05:26 forseti auditd[605]: wait_for_events: read 2 Sep 22 00:05:26 forseti auditd[605]: Got open new trigger Sep 22 00:05:26 forseti auditd[605]: dir = /var/audit Sep 22 00:05:26 forseti auditd[605]: New audit file is /var/audit/\ 20060921220526.not_terminated Sep 22 00:05:26 forseti auditd[605]: renamed /var/audit/20060921220405\ .not_terminated to /var/audit/ 20060921220405.20060921220526 Sep 22 00:06:16 forseti auditd[605]: wait_for_events: read 2 Sep 22 00:06:16 forseti auditd[605]: Got open new trigger Sep 22 00:06:16 forseti auditd[605]: dir = /var/audit Sep 22 00:06:16 forseti auditd[605]: New audit file is /var/audit/20060921220616\ .not_terminated Sep 22 00:06:16 forseti auditd[605]: renamed /var/audit/20060921220526\ .not_terminated to /var/audit/ 20060921220526.20060921220616 My audit_control file: dir:/var/audit flags:all minfree:20 naflags:lo My audit_user file: root:all:no elessar:all:no From my understanding, this configuration should generate a ridiculous amount of data and probably fill Filesystem 1K-blocks Used Avail Capacity Mounted on /dev/ufs/var253678 63308 17007627%/var up to the configured limit during a buildworld. uname -a: FreeBSD forseti.starkstrom.lan 6.2-PRERELEASE FreeBSD 6.2-PRERELEASE #3: Thu Sep 21 23:32:20 CEST 2006 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/FORSETI alpha audit sourcefile versions: $FreeBSD: src/sys/security/audit/audit.c,v 1.18.2.3 2006/09/20 17:07:11 csjp Exp $ $FreeBSD: src/sys/security/audit/audit.h,v 1.8.2.2 2006/09/04 06:07:51 rwatson Exp $ $FreeBSD: src/sys/security/audit/audit_arg.c,v 1.6.2.1 2006/09/02 11:50:50 rwatson Exp $ $FreeBSD: src/sys/security/audit/audit_bsm.c,v 1.10.2.3 2006/09/20 17:04:04 csjp Exp $ $FreeBSD:
Re: Problems with auditd -- resolved
Robert Watson wrote: Dear all, I've just comitted a fix to syscalls.master and regenerated the remaining system call files, which should correct the auditctl: Invalid Argument error being returned by auditd. In short order, this fix should be on the cvsup mirrors -- please let me know if it resolves the problem you were experiencing. Hi, After installing and running auditd I don't see any log files for auditd: daemon# ls -l /var/audit/ total 0 -r--r- 1 root audit 0 Sep 18 14:23 20060918052316.20060918060339 -r--r- 1 root audit 0 Sep 18 15:03 20060918060339.not_terminated I have custom /etc/security/audit_control and audit_user files. daemon# more /etc/security/audit_control # # $P4: //depot/projects/trustedbsd/openbsm/etc/audit_control#3 $ # $FreeBSD: src/contrib/openbsm/etc/audit_control,v 1.2.2.1 2006/09/02 10:46:00 rwatson Exp $ # dir:/var/audit flags:all minfree:20 naflags:lo # # $P4: //depot/projects/trustedbsd/openbsm/etc/audit_user#3 $ # $FreeBSD: src/contrib/openbsm/etc/audit_user,v 1.2.2.1 2006/09/02 10:46:00 rwatson Exp $ # #root:lo:no root:all:no I'm bit confused here I thought auditd should log all activities, but I don't see any log files. Am I doing something wrong here or my understanding regarding auditd is wrong? thanks in advance, Ganbold Thanks, Robert N M Watson Computer Laboratory University of Cambridge ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Problems with auditd -- resolved
On Mon, 18 Sep 2006, Ganbold wrote: # # $P4: //depot/projects/trustedbsd/openbsm/etc/audit_user#3 $ # $FreeBSD: src/contrib/openbsm/etc/audit_user,v 1.2.2.1 2006/09/02 10:46:00 rwatson Exp $ # #root:lo:no root:all:no I'm bit confused here I thought auditd should log all activities, but I don't see any log files. Am I doing something wrong here or my understanding regarding auditd is wrong? Your configuration looks right to me, and should be generating a ridiculous number of audit records. Could you try rebooting and logging in again? audit_user entries take effect only as of login, similar to /etc/group settings, etc. How are you logging into the system? On my local RELENG_6 system, with the recent auditctl(2) fix, I'm using the following global settings to audit programs run by authenticated users: dir:/var/audit flags:lo,+ex minfree:20 naflags:lo It seems to be working properly. User space login/logout auditing won't work in RELENG_6 until the MFC of Christian's recent tweaks to pipe preselection, which will occurr in a few days (and hence should appear in BETA2). Robert N M Watson Computer Laboratory University of Cambridge ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Problems with auditd -- resolved
Robert Watson wrote: On Mon, 18 Sep 2006, Ganbold wrote: # # $P4: //depot/projects/trustedbsd/openbsm/etc/audit_user#3 $ # $FreeBSD: src/contrib/openbsm/etc/audit_user,v 1.2.2.1 2006/09/02 10:46:00 rwatson Exp $ # #root:lo:no root:all:no I'm bit confused here I thought auditd should log all activities, but I don't see any log files. Am I doing something wrong here or my understanding regarding auditd is wrong? Your configuration looks right to me, and should be generating a ridiculous number of audit records. Could you try rebooting and logging in again? audit_user entries take effect only as of login, similar to /etc/group settings, etc. How are you logging into the system? This is my desktop system and I updated today to latest RELENG_6. daemon# uname -an FreeBSD daemon.micom.mng.net 6.2-PRERELEASE FreeBSD 6.2-PRERELEASE #6: Mon Sep 18 12:56:04 ULAST 2006 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/GDAEMON i386 I tried to restart several times auditd using /etc/rc.d/auditd script. daemon# /etc/rc.d/auditd restart Trigger sent. Starting auditd. daemon# /etc/rc.d/auditd restart Trigger sent. auditd already running? (pid=2065). daemon# /etc/rc.d/auditd restart Error sending trigger: Operation not supported by device Starting auditd. daemon# /etc/rc.d/auditd restart Trigger sent. auditd already running? (pid=2095). daemon# /etc/rc.d/auditd restart Error sending trigger: Operation not supported by device Starting auditd. daemon# /etc/rc.d/auditd restart Trigger sent. Starting auditd. daemon# ps ax | grep audit 10 ?? DL 0:00.00 [audit_worker] 2141 ?? Ss 0:00.01 /usr/sbin/auditd 2143 p3 RV 0:00.00 grep audit (csh) daemon# ps ax | grep audit 10 ?? DL 0:00.00 [audit_worker] 2141 ?? Ss 0:00.01 /usr/sbin/auditd Strange, there are still no logs in /var/audit dir :( Even tried to use your config, no success. However when I logged on to my desktop from console to itself (ssh -l tsgan localhost) it starts logging. But why it is not logging when I'm on console? On my local RELENG_6 system, with the recent auditctl(2) fix, I'm using the following global settings to audit programs run by authenticated users: dir:/var/audit flags:lo,+ex minfree:20 naflags:lo It seems to be working properly. User space login/logout auditing won't work in RELENG_6 until the MFC of Christian's recent tweaks to pipe preselection, which will occurr in a few days (and hence should appear in BETA2). I see. thanks, Ganbold Robert N M Watson Computer Laboratory University of Cambridge ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Problems with auditd -- resolved
On Mon, 18 Sep 2006, Ganbold wrote: Strange, there are still no logs in /var/audit dir :( Even tried to use your config, no success. However when I logged on to my desktop from console to itself (ssh -l tsgan localhost) it starts logging. But why it is not logging when I'm on console? Are you using xdm/kdm/gdm/etc or /usr/bin/login? I'm not sure that the various GUI login managers associated with X11 ship with BSM support compiled in by default, although given that they also run on Solaris, it is likely they support it. Robert N M Watson Computer Laboratory University of Cambridge ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Problems with auditd -- resolved
Robert Watson wrote: On Mon, 18 Sep 2006, Ganbold wrote: Strange, there are still no logs in /var/audit dir :( Even tried to use your config, no success. However when I logged on to my desktop from console to itself (ssh -l tsgan localhost) it starts logging. But why it is not logging when I'm on console? Are you using xdm/kdm/gdm/etc or /usr/bin/login? I'm not sure that the various GUI login managers associated with X11 ship with BSM support compiled in by default, although given that they also run on Solaris, it is likely they support it. Ok, I'm using gnome and gnome-terminal, and it is not logging. Probably gnome-terminal is not compiled with BSM support. Auditd logs when I go to console using ctrl+alt+f2 combination from X. Thanks for clarifying this. Ganbold Robert N M Watson Computer Laboratory University of Cambridge ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Problems with auditd -- resolved
On Mon, 18 Sep 2006, Ganbold wrote: Robert Watson wrote: On Mon, 18 Sep 2006, Ganbold wrote: Strange, there are still no logs in /var/audit dir :( Even tried to use your config, no success. However when I logged on to my desktop from console to itself (ssh -l tsgan localhost) it starts logging. But why it is not logging when I'm on console? Are you using xdm/kdm/gdm/etc or /usr/bin/login? I'm not sure that the various GUI login managers associated with X11 ship with BSM support compiled in by default, although given that they also run on Solaris, it is likely they support it. Ok, I'm using gnome and gnome-terminal, and it is not logging. Probably gnome-terminal is not compiled with BSM support. Auditd logs when I go to console using ctrl+alt+f2 combination from X. Thanks for clarifying this. Basically, at login, the audit subsystem determins what new audit properties are required for the login session and assigns them to the process, which consists of both the audit identifier associated with the user, and the preselection mask. Events associated with non-authenticated sessions (which is what gdm logins will count as) should still get audited using the properties for the global naflags setting, so if you want to audit events associated with gdm you can set naflags to include more events. This will also be what audits things like web server activity, so it may result in significant numbers of events being audited as part of that also. We will need to add audit extensions to new login mechanisms, such as xdm/kdm/gdm, or enable them if already present but not enabled on FreeBSD by default. OpenSSH, for example, already included BSM support due to Solaris and Mac OS X BSM, so we just enabled it by switching a flag in the compile (and also fixed a bug in it!). We should probably talk to the maintainers of these ports about investigating creating or enabling BSM support. Robert N M Watson Computer Laboratory University of Cambridge ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Problems with auditd -- resolved
2006/9/18, Robert Watson [EMAIL PROTECTED]: I'm bit confused here I thought auditd should log all activities, but I don't see any log files. Am I doing something wrong here or my understanding regarding auditd is wrong? Your configuration looks right to me, and should be generating a ridiculous number of audit records. just try few minutes with fw. works for me. tnx Robert Co. -- Cris, member of G.U.F.I Italian FreeBSD User Group http://www.gufi.org/ ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Problems with auditd -- resolved
2006/9/17, Robert Watson [EMAIL PROTECTED]: I've just comitted a fix to syscalls.master and regenerated the remaining system call files, which should correct the auditctl: Invalid Argument error being returned by auditd. In short order, this fix should be on the cvsup mirrors -- please let me know if it resolves the problem you were experiencing. auditd up and running, tnx Robert. I will submit more information. -- Cris, member of G.U.F.I Italian FreeBSD User Group http://www.gufi.org/ ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
