From owner-freebsd-hackers Thu Apr 19 8:19:34 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from tango.entreri.com (tango.entreri.com [205.219.158.250]) by hub.freebsd.org (Postfix) with ESMTP id B154037B42C for ; Thu, 19 Apr 2001 08:19:31 -0700 (PDT) (envelope-from dp@penix.org) Received: from penix.org (Toronto-ppp221365.sympatico.ca [64.228.106.182]) by tango.entreri.com (8.10.2/8.9.1) with ESMTP id f3JFJX119304 for ; Thu, 19 Apr 2001 10:19:34 -0500 Message-ID: <3ADF04E8.55D0888E@penix.org> Date: Thu, 19 Apr 2001 11:31:52 -0400 From: Paul Halliday X-Mailer: Mozilla 4.76 [en] (X11; U; FreeBSD 4.3-RC i386) X-Accept-Language: en MIME-Version: 1.0 To: hackers@freebsd.org Subject: Dilemma. Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hi. I will try to make this quick. I am writting a little monitoring script in bash and I have run into a little stumbling block. Basically, one of the checks this program will perform is to take a fingerprint of the entire filesystem. For my needs this is only required every 24 hours as the other procedures that use this as a template will do so in little chunks. Now, I have a couple of concerns. 1) Is there a simpler and faster way to perform something equivalent to "ls -aliTR /"? This portion of output will be queried with checks on inode numbers, last modified, and sizes at random intervals and subsequently updated if valid. 2) The more I test the above, the more I realise that this is not without loopholes. Even if my checks are every 5 minutes there still exists the possibility and time for someone that has compromised the system to modify date / inodes to match what was existing. <- any input on this issue would be really great. ie: a field that cannot be modified even by root. I have had some silly ideas such as: changing kernel secure level and chflaging every file (probably not even possible),or maybe using pgp in some way to sign the most important files, /bin, /usr/bin, etc. I hope to build enough superfluity into this baby so that the above would just be another check not the backbone of this IDS idea. Any help, ideas, please send. -- Paul Halliday ============================================================================ Don't underestimate the power of stupid people in large groups. Web: http://dp.penix.org Current Project: http://www3.sympatico.ca/transmogrify/cl.html Public Key available here: http://dp.penix.org/dp.txt ============================================================================ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message