-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Brian Pontz wrote: >> Unfortunately, that would defeat the purpose behind >> my wanting to remotely log >> the activity. > > You can do this through syslog but it would require > you to modify the kernel code and recompile it. You > would basically printk() all exec's in the kernel. > Otherwise the honeynet project would probably be the > best people to ask about this. Isn't that what the audit subsystem is designed for? No need for custom kernels - just set some audit rules to monitor execs and parse the auditd output. This still won't be a perfect replacement for bash_history though as it will loose some detail of the arguments. That said, if this is purely for security monitoring and not to have a list of commands and their arguments for re-play purposes (that's the goal of a shell history), I think audit would be the most straightforward solution. You need to set up two files to configure auditing, auditd.conf and audit.rules. The first governs the daemon itself, the second tells it what to audit. There's currently no direct support for syslog-style @host remote logging, but there is a "dispatcher" directive in auditd.conf that will run an external command when audit starts and pipe each message to that program's stdin - a simple wrapper would then be able to squirt the messages to a remote server if needed. Alternately, make /var/log/audit a separate filesystem on GFS and write the logs here. That will probably need some twiddling as I think auditd normally starts before GFS filesystems are mounted but shouldn't be impossible. A simple audit rule to get started could look like this: - -a exit,always -S exec You can be more specific about what to log, filter by uid, pid and other attributes - see the auditctl man page for the details as well as the sample rule files under /usr/share/doc/audit-*/. One word of warning - it's possible to DoS yourself in a couple of ways with audit. The default behavior when audit cannot create its logs is to panic - this is for high security environments where no service is better than insecure service. Disable it by setting "-f 0" or "-f 1" in the rules file (silent/printk on error respectively). Also, the volume of messages can be huge with a very broad ruleset - be sure to allow enough space for the logs and to configure rotation if needed. More info here: http://people.redhat.com/sgrubb/audit/ Cheers, Bryn. > Brian > > -- > Linux-cluster mailing list > Linux-cluster@xxxxxxxxxx > https://www.redhat.com/mailman/listinfo/linux-cluster -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFFpRWH6YSQoMYUY94RAtxrAKCfBPDO2dcLLx8lWy/7gQbagM5KDACfYfX/ WOWcQ/oJTQ/JA8z7Uitx8lA= =Dey9 -----END PGP SIGNATURE----- -- Linux-cluster mailing list Linux-cluster@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/linux-cluster
