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 -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
