New List Member: Intro & comments

Clif Flynt clif at cflynt.com
Mon Jul 31 17:14:37 UTC 2006


Hi,
  I'm primarily an applications developer, though I wear a
sys-admin/security-admin hat when necessary.  I've done kernel hacking
on V-7 and System-3 in the bad old days, but mostly stick in userland
now.

  My current goal is to get some OpenSuse 10.1 systems DSS certified.
I've been a RedHat user since about RH4 or 5, but this project decided
to standardize on SuSE.  My focus for using auditd isn't so much to
make a truly secure and well audited system, but to answer the specific
DSS/NISPOM Chapter 8 requirements.

  SuSE supports AppArmor and the auditd security products, but has
very little SELinux support.

  As I read things, AppArmor doesn't support the file audit 
requirements, but Auditd can meet the DSS requirements.

  I've updated the standard SuSE 10.1 kernel to 2.6.17.6 and brought in
the 3.0 glibc kernel headers.  With these hacks, I can get the 1.2.5
auditd package to compile and install.  It appears to be working.
  
  Auditd 1.2.5 doesn't quite do what I need, but I'm getting close.
It has the framework, but it seems to take a little work to get the
answers I really want, and to handle the requirements for record
maintenance.

  1) Auditing and reporting

  I've copied the SYSCALL rules from the capp.rules sample, and I
think that covers what DSS will need audited.  (Still checking and 
confirming that I haven't missed anything obvious.)

  To get the answers I wanted a bit more easily, I've made a GUI based
search tool that lets me specify reports with a bit more precision and
build customized reports.  It's functional code, but is not pretty, and
gets pretty ugly when the data is way outside what I expected.

  2) Maintaining records

  The traditional log-rotate with N logs makes it difficult to keep X
days of logs.  When the system is busy, I can rotate the logs every 10
minutes.

  I've put together a small cron job that looks for audit.log.1,
filters out some data I know I won't want, and zips it into a file with
a name based on the timestamp.

  My current report generator builds an SQLite database on the fly from
the flat ASCII logs.  I'm thinking that the next rev of the file
rotation code will move the data to an SQLite database instead of
gzipped flat files and save that step.

  I'm using SQLite instead of mySQL or Postgres because it it's fast,
mature and robust and doesn't  require any database server (or dbadmin)
to run it.

  I put together a small audisp test application to read from stdin and
save data in a timestamped file.  When I run this, I get nothing but
empty reads, and finally an EOF from auditd.  I'm expecting to see
plain ASCII input.

  Is this not what is sent to the audisp target?

  I just tried the sample.c application, compiled it to a.out and put
that into the auditd.conf file.  When I restart audispd, I see no
output in /var/log/messages, and a.out does not show in the process
stack.  If I just run /tmp/a.out and type something, output appears
in /var/log/messages.

  If any of this is of interest or use, let me know, and I'll make it
available to the community.


  Thanks, 
  Clif

-- 
.... Clif Flynt ... http://www.cflynt.com ... clif at cflynt.com ...
.. Tcl/Tk: A Developer's Guide (2nd edition) - Morgan Kauffman ..
..13th Annual Tcl/Tk Conference:  Oct 9-13, 2006,  Chicago, IL ..
.............  http://www.tcl.tk/community/tcl2006/  ............





More information about the Linux-audit mailing list