From mboxrd@z Thu Jan 1 00:00:00 1970 From: =?UTF-8?Q?Dav=c3=ad=c3=b0_Steinn_Geirsson?= Subject: Re: auditd on nonexistent files Date: Tue, 15 Sep 2015 09:25:01 +0000 Message-ID: <55F7E3ED.1090809@sensa.is> References: <55F6EF4D.7050203@sensa.is> <20150915101503.0dd9e4d4@ivy-bridge> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============4069226756762923009==" Return-path: In-Reply-To: <20150915101503.0dd9e4d4@ivy-bridge> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: linux-audit-bounces@redhat.com Errors-To: linux-audit-bounces@redhat.com To: Steve Grubb Cc: linux-audit@redhat.com List-Id: linux-audit@redhat.com --===============4069226756762923009== Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="lVOS3bsMuivTCXI0ML5m0O2KNHFH7nTHx" --lVOS3bsMuivTCXI0ML5m0O2KNHFH7nTHx Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi, On 09/15/2015 09:15 AM, Steve Grubb wrote: > On Mon, 14 Sep 2015 16:01:17 +0000 > Dav=C3=AD=C3=B0 Steinn Geirsson wrote: >=20 >> Hi all, >> >> What is the best practice for using auditd for file integrity >> monitoring? >> >> From the documentation, I have this, which works fine: >> -a always,exit -F dir=3D/bin -F perm=3Dwa >> >> However, it seems that if I have a rule on a nonexistent directory, >> auditd will fail to add the rule (I assume because it's adding a watch= >> on an inode or something like that?), but it will also just stop >> reading audit.rules and not add any subsequent rules. >> >> This is bad in an environment where we have to have FIM for critical >> application files, but where another team may be maintaining some of >> the apps and therefore might remove some watched directories, >> especially as their mishaps may impact auditing for other parts of >> the system. >> >> >> Can something be done to get better behaviour here? >> >> I see two ways it could be better >> 1) (the ideal case) auditd will add rules even for nonexistent >> directories, and when they are created will add a watch for them. If a= >> directory is removed and another created with the same name, auditd >> will add a watch on the new directory. >=20 > Which kernel are you using? I want to think this was fixed in kernels > around 2.6.36 or later. This original problem was that the audit > watches are based on inotify which needs an inode. If there's no inode,= > you can't place the watch. The machines I'm working with are RHEL6 with 2.6.32, but I just tried with a machine with a 3.18 kernel and got the same behaviour. >=20 >=20 >> 2) auditd still cannot add watches to nonexistent directories, but a >> failed rule add from audit.rules will become a warning rather than an >> error so subsequent watches still get added. >=20 > Check into adding -i or -c near the top of your rules. Thanks, that helps for a workaround. Not sure how I missed that in the manpage. >=20 > -Steve >=20 >=20 >> I suspect 1) is not possible, but can I get auditd to behave like in >> 2)? >> >> Best regards, >> Dav=C3=AD=C3=B0 >> >=20 --lVOS3bsMuivTCXI0ML5m0O2KNHFH7nTHx Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJV9+PtAAoJEJncUUVDk/7kY80P/1NTSdIjOE+QS66y9EpDE9af 33TwFuDQD3/F4cQUksq8I9tVMl0O1KrLygC6/MCMw/wTqOzQPSm7AYutuOCWvElu XOrs6k9cWvDd/C6CuqKZVYRIqm52VOvE3oojO72G9Qimu8joPn6iETaOukYsVI64 7iKO4X4Wgz4LC5x+uSB5udT5nzAISdoq3zOE2seOZyHCrHjjJR2QOVWzSR4bUqui 7mf4DI45ZRT8wu8fK8DFc+frl5C45bqijS6t3MOPHNKA0BUDtVA3Cfw8QPDlzA4T tyyvZoqc8CVxoi4fchfyegELfCt4pkZlDl6/Ky9cH/gleRD65VwEOUEONQPb2tKV FlUdrXcA4ekxQqezWx3ni19KYHG9iUIZwEcBQr4WEkHT3JMHnXX1zDsvWXtxL0EL 2/fUtkrykBhgenFxgKzCs2hins382A95CcK5ohsSJxJHDYyunIY4F6lJpIkWnCFB mG+3+n1hOyebZ4Sj0UdTTVCh5v4yZFo+l8PJhTgjhapgo9slDmXtQt4YnjPQGpKN IAGR0EE6aS4vcaPHLIOdyBFeDAAsAKrbY5eNil9N9skhMf12BzGRJIIJ/RbIXrtL MjxQnicN0WcrMD2WSXSMtTaasJmCVlESyQVO/d/GF43FlDLXs1KwEyGPE174i5k6 JUvGBh8DycsjZZPAhHLT =xvsP -----END PGP SIGNATURE----- --lVOS3bsMuivTCXI0ML5m0O2KNHFH7nTHx-- --===============4069226756762923009== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline --===============4069226756762923009==--