Date: Wed, 21 Nov 2012 08:33:58 +0000 (GMT) From: Robert Watson <rwatson@FreeBSD.org> To: freebsd-security@FreeBSD.org Subject: OpenBSM new addition: auditdistd. (fwd) Message-ID: <alpine.BSF.2.00.1211210833180.87477@fledge.watson.org>
next in thread | raw e-mail | index | archive | help
freebsd-security folk may also be interested in this forthcoming addition to
OpenBSM from Pawel. I plan to cut a new OpenBSM alpha rev with auditdistd in
the next couple of days.
Robert N M Watson
Computer Laboratory
University of Cambridge
---------- Forwarded message ----------
Date: Wed, 21 Nov 2012 00:42:45 +0100
From: Pawel Jakub Dawidek <pjd@FreeBSD.org>
To: trustedbsd-audit@FreeBSD.org
Subject: OpenBSM new addition: auditdistd.
Hi.
In the new release of OpenBSM one of the major additions would be the
auditdistd daemon. The work was sponsored by the FreeBSD Foundation.
Thank you!
Auditdistd is used to reliably and securely transfer local audit trail
files over the network to separate machine, so that in case of
successful attack on the local machine, an attack is unable to tamper
with already distributed audit records.
The auditdistd can operate in two modes: as a sender and as a receiver.
In the first mode (the sender), auditdistd is reponsible for sending
audit events gathered locally to remote auditdistd that operates in the
receiver mode. The auditdistd in the receiver mode is responsible for
receiving and storing audit trail files locally. On the receiver side
there is no need for audit subsystem to be turned on.
Auditdistd for speed, reliability and also security doesn't interpret
audit trail files. Any file could be send and receive. The receiver
places the files in a directory dedicated to the sending system. Sending
side has no control over the place where received trail files are
stored. The receiver also accepts only new audit events. It works in
append-only mode. Previously received trail files and audit records
stored in most recent trail file cannot be modified by the sender. These
restrictions allow to assume that even if sender side was compromised in
the given point in time, all previous audit records from this host can
be trusted.
Auditdistd uses sandboxing (including Capsicum's capability mode if
availble), which is especially important for the receiver mode.
In the current implementation after breaking through auditdistd protocol
into the receiver process, an attacker has no access to audit trail
files from other senders. This may be improved to use Capsicum's
capabilities and only provide append-only file descriptors to the
receiver process. Unfortunately with the current Capsicum implementation
it is not possible to limit file descriptor to append-only writes.
As part of another projected I changed that, so it should be available
in the future.
The auditdistd is as autonomous as possible, but sometimes auditd help
is needed. Audit trail files are created by auditd in response to a
request from the kernel audit subsystem. Auditd creates a file in
/var/audit/ directory and of <timestamp>.not_terminated format. It also
creates symlink 'current' to this file. Auditdistd needs hardlink to
audit trail file in /var/audit/dist/ directory. It could create the
hardlink by itself by monitoring changes to the /var/audit/ directory,
but it might not be reliable. It might be possible that new audit trail
file is created, terminated and removed before auditdistd had a chance
to notice the file. This way we would lose some audit events. That's
why more reliable option is to modify auditd to create hardlink in the
/var/audit/dist/ directory the same way it creates symlink to current
audit trail file. Similarly, auditd might be responsible for renaming
.not_terminated files in /var/audit/dist/ directory to final name after
termination for the same reason - auditdistd might not see the final
name before trail expires and is removed from /var/audit/.
Having a hardlink to trail file in /var/audit/dist/ eliminates the need
for communication between auditd and auditdistd daemons. Each of them
can remove their links whenever they want. If auditd decides that trail
file expired and removes it from /var/audit/ directory, it doesn't
affect link in /var/audit/dist/ directory that might not be sent yet by
the auditdistd to the receiver side. And vice-versa - if auditdistd
successfully sends trail file to the receiver side before it expires
locally, it will just remove its link from /var/audit/dist/ without
affecting /var/audit/ link.
Configuration is pretty trivial. On the sender side where we gather
audit records we have to add the following line to the
/etc/security/audit_control file:
dist:on
And create /etc/security/auditdistd.conf file, eg.:
sender {
host "bigbrother.freebsd.org" {
remote "tls://10.0.0.5"
fingerprint "SHA256=8F:0A:FC:8A:3D:09:80:AF:D9:AA:38:CC:8A:86:53:E6:8F:B6:1C:55:30:14:D7:F9:AA:8B:3E:73:CD:F5:76:2B"
password "YjwbK69H5cEBlhcT+eJpJgJTFn5B2SrG"
}
}
Fingerprint from receiver's public key can be obtained by running:
openssl x509 -in /etc/security/auditdistd.cert.pem -noout -fingerprint -sha256 | awk -F '[ =]' '{printf("%s=%s\n", $1, $3)}'
On the receiver side we need to put certificate and private key into the
following files:
/etc/security/auditdistd.cert.pem
/etc/security/auditdistd.key.pem
And create the following /etc/security/auditdistd.conf:
receiver {
host "freefall.freebsd.org" {
remote "tls://10.0.0.2"
password "YjwbK69H5cEBlhcT+eJpJgJTFn5B2SrG"
}
}
--
Pawel Jakub Dawidek http://www.wheelsystems.com
FreeBSD committer http://www.FreeBSD.org
Am I Evil? Yes, I Am! http://tupytaj.pl
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?alpine.BSF.2.00.1211210833180.87477>