Re: Q re daemons

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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
[Index of Archives]     [Older Fedora Users]     [Fedora Announce]     [Fedora Package Announce]     [EPEL Announce]     [Fedora Magazine]     [Fedora News]     [Fedora Summer Coding]     [Fedora Laptop]     [Fedora Cloud]     [Fedora Advisory Board]     [Fedora Education]     [Fedora Security]     [Fedora Scitech]     [Fedora Robotics]     [Fedora Maintainers]     [Fedora Infrastructure]     [Fedora Websites]     [Anaconda Devel]     [Fedora Devel Java]     [Fedora Legacy]     [Fedora Desktop]     [Fedora Fonts]     [ATA RAID]     [Fedora Marketing]     [Fedora Management Tools]     [Fedora Mentors]     [SSH]     [Fedora Package Review]     [Fedora R Devel]     [Fedora PHP Devel]     [Kickstart]     [Fedora Music]     [Fedora Packaging]     [Centos]     [Fedora SELinux]     [Fedora Legal]     [Fedora Kernel]     [Fedora OCaml]     [Coolkey]     [Virtualization Tools]     [ET Management Tools]     [Yum Users]     [Tux]     [Yosemite News]     [Gnome Users]     [KDE Users]     [Fedora Art]     [Fedora Docs]     [Asterisk PBX]     [Fedora Sparc]     [Fedora Universal Network Connector]     [Libvirt Users]     [Fedora ARM]

  Powered by Linux