On Friday 04 January 2008 06:32:27 Linus Walleij wrote:
So every Fedora user must have these (right?):
root 2219 0.0 0.0 12288 684 ? S<sl 10:14 0:00 auditd
root 2221 0.0 0.0 12200 708 ? S<sl 10:14 0:00
/sbin/audispd
You can turn it off if you want. :)
What else, besides selinux, is using auditd in Fedora right now or in
the
immediate future? (Since we're a distribution we don't count theoretical
use cases I hope...)
The audit logs are the collection point for all security relevant events from
failed logins, to avcs, to raw sockets being opened, to apps that segfault.
It collects everything that truly matters regarding security. It also has a
simple utility that gives you a quick overview of security events, aureport.
For an overview since Sunday, "aureport --start this-week"
Regarding the future, I have plans to add IDS/IPS plugin to audispd so that it
can spot and react to suspicious events. I also plan to create a prelude
plugin that can take events and send them to a prelude manager.
The security audit tool that was announced yesterday will send any security
issues it discovers to the audit system where it can be reported on. aide
also sends a summary description of what it finds to the audit system.
If auditd is not running, these events wind up in syslog. Some people do not
like all these events cluttering up syslog, so its simpler to just run the
audit daemon. Sooner or later people need to research something related to
security and the audit system has search and reporting tools.
bash-3.2$ repoquery --whatrequires `repoquery --provides audit`
setroubleshoot-server-0:2.0.0-3.fc9.noarch
audispd-plugins-0:1.6.4-3.fc9.i386
seedit-0:2.2.0-1.fc9.i386
amtu-0:1.0.6-1.fc9.i386
audit-0:1.6.4-3.fc9.i386
auditspd-plugins, seedit and amtu are not default-installed, so on a
Fedora default install, SELinux is really the only thing actually using
auditd, am I right?
No, *everything* security related goes into the audit logs.
If I read this correctly, we must have auditd running on any Fedora
box
everywhere, even without SELinux since:
* auditspd-plugins may be installed and can monitor remote machines and
wouldn't work without auditd, so the entire network comes into the
picture here and it's hard for the UI to know what the user wants.
* amtu may be installed, so then it is necessary to have.
Technically, amtu needs audit-libs. auditd just ensures amtu events windup in
audit logs rather than syslog. auditd should not be required by amtu.
As indeed if the user of system-config-services or anaconda
previously
disabled auditd, then installing the amtu or auditspd-plugins RPM will
or should turn the service on again by some %post script or similar,
right?
It should not. amtu is happy to send things to audit system which sees that
auditd is not running and then forwards events to syslog for disposition.
If this is NOT true, then the user should NOT be allowed to disable
auditd
under any circumstances, and shouldn't worry about it using a few KB of
memory, it should have "# hide: true" added to /etc/init.d/auditd
so it's not even shown in s-c-s right?
There must be one of these things needing to have a bug filed.
I could easily imagine things like AppArmour, TOMOYO or tripwire (not
even in-kernel!) to use it in theory, though I don't know if they do in
practice, and none of them are in Fedora, so please enlighten me if you
know further use cases.
AppArmour does use the audit system. But we do not ship it. We have aide, not
tripwire and it is modified. TOMOYO, I'm not familiar with, nor have they
contacted me about reserving events. If you search on audit-libs, you will
see the real breadth of what uses the audit system. auditdis just the
collector, which may or may not be running or installed. All the apps need
the audit-libs to send events to the kernel which ultimately sends events to
the audit daemon.
Okay!
https://bugzilla.redhat.com/show_bug.cgi?id=427506
(pending discussion as of whether auditd could actually be disabled too)
sigh...the services should exit if selinux is disabled. Its ok for them to
start up.
-Steve