Gene Heskett wrote: > > So can anyone tell me what 'audispd' is and does? And how, if its not > doing anything usefull, can I reliably kill it so that its not restarted > at the next reboot? > apologies for a 2nd reply but hey...i'm just sad ;-) searching audispd returns stuff on audit and then actually found the following - brace yourself, it's long.... What is Audit? The 2.6 Audit system consists of two main components. The first component is an instrumented kernel, in which auditing of system call entry and exit can be optionally specified on a system call by system call basis. Audit includes tools to load audit rules into the kernel at runtime to specify what system calls are to be audited, and under what conditions. The kernel audit system can also support the injection of log events from other kernel systems and from user space into the kernel auditing stream. This is used to inject audit events when a user logs in or out from the system, for instance. The second component of Audit is a security-oriented audit daemon, which communicates with the kernel through a high speed NetLink Socket. The audit daemon is responsible for routing the log records to appropriate permanent storage, as well as for making reporting to the kernel as to the disposition of the logging. If the audit daemon reports a failure to log an event, the kernel may take various actions, up to and including a kernel panic, though this is obviously only appropriate if the system security policy demands it. The kernel audit sytem and the audit daemon together provide a number of features to manage practical issues with logging massive kernel data. The kernel can set upper bounds on the number of audit events to generate, and what to do if that rate is exceeded. The audit daemon can be instructed as to how often to flush log data to disk, how often to rotate logs, how large an audit file is allowed to get, and what to do if an audit file gets full. The audit daemon is also capable of sending log events across a network connection to third party audit collecting programs such as Snare 2.6. Performance While all audit systems intended for use in a secure system context must be designed for secure operation, the 2.6 Audit system is in addition optimized for performance. The decision as to whether or not to do audit processing on a system call is optimized to be 'free' in the case where auditing is never to be performed. In the case where auditing is to be done on an conditional basis, the auditing rules are actually encoded into the kernel, so the first level of audit filtering can be done within the kernel itself, rather than having to construct the audit record and send it to a user level process, as has traditionally be done with Snare. To keep the load on the kernel down, the audit rule system is designed to be extremely simple and fast to evaluate. That means that while audit rules are allowed to test system call parameters against simple integer values, no string comparisons can be expressed in the audit rules. This is less rich than a system like Snare, where complicated audit rules are evaluated in user space, but performance is far higher. That's not to say that Audit doesn't allow a good measure of control for auditing, though. Here are some of the data that can be considered when deciding whether to audit a system call: * Process ID * User ID * Effective User ID * Set User ID * Filesystem User ID * Group ID * Effective Group ID * Set Group ID * Filesystem Group ID * Audit ID - The original User ID that the user logged in with, before su, sudo, or setuid execution. * Device Major Number * Device Minor Number * Inode Number * Exit Value from a Syscall * The first, second, third, or fourth integral value of Syscall arguments This suggests that auditing of file system operations on specific files must be done by Inode number. This is true in general, however the Audit system also supports the notion of a filesystem watch, which is expressed with a fully qualified path. This is useful for circumstances like monitoring /etc/passwd, where a specific editing operation may cause the inode number for the file to change. Higher level auditing filters, such as regular expressions against file names, etc., must be carried out with a userspace tool like Snare 2.6. (Note: A recent patch to the Linux kernel seems to extend the notion of auditing by filesystem path so that a path can be used any place where an Inode rule can be specified in 2.6 Audit. This patch is obviously too recent to be in any distribution, but it looks that future versions of Audit will loosen this restriction somewhat.) Audit and SELinux The Linux 2.6 Audit system is designed to interoperate with SELinux, which has its own system of mandatory access control (for permissions and for logging) on system resources explicitly tagged with security descriptors. If Audit is enabled on a 2.6 system running SELinux, all SELinux logging operations will be done through the Audit system, taking advantage of Audit's operational support for log management, as described above. While SELinux and Audit make a great combination together, it is perfectly permitted and useful to run either separately. If you're using SELinux for the mandatory access control (MAC) on operating system resources, and you either don't care about auditing MAC failures, or you're willing to audit to syslog rather than using the more secure Audit system, you can use SELinux on its own quite well. And if you want to do auditing but don't want to have to go to the hassle of marking up all system resources with SELinux Tags, you can get along perfectly well with just Audit. [stolen from http://www.nabble.com/Snare-for-Linux-2.6-Audit---Snare-Linux-NG-t1813055.html] it's 1.40am; to bed...NOW! -- (o< Thierry Sayegh de Bellis, RHCE //\ http://glossolalie.com V_/_ Fingerprint: 9976 11FE D9C6 8C67 6242 7BB1 6466 3F1D 56ED 7D5A -- fedora-list mailing list fedora-list@xxxxxxxxxx To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
