From owner-freebsd-hackers Thu Apr 19 9:15:22 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from ringworld.nanolink.com (ringworld.nanolink.com [195.24.48.13]) by hub.freebsd.org (Postfix) with SMTP id DCF8237B71A for ; Thu, 19 Apr 2001 09:15:07 -0700 (PDT) (envelope-from roam@orbitel.bg) Received: (qmail 4319 invoked by uid 1000); 19 Apr 2001 16:13:32 -0000 Date: Thu, 19 Apr 2001 19:13:32 +0300 From: Peter Pentchev To: Paul Halliday Cc: hackers@freebsd.org Subject: Re: Dilemma. Message-ID: <20010419191332.E1527@ringworld.oblivion.bg> Mail-Followup-To: Paul Halliday , hackers@freebsd.org References: <3ADF04E8.55D0888E@penix.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3ADF04E8.55D0888E@penix.org>; from dp@penix.org on Thu, Apr 19, 2001 at 11:31:52AM -0400 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thu, Apr 19, 2001 at 11:31:52AM -0400, Paul Halliday wrote: > 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. "find / -ls" shall give you more relevant info, less redundant info, and less irrelevant info. > 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. No, I don't believe there is any aspect of the filesystem that cannot be modified/faked, given appropriate privileges :( I might be wrong, though. G'luck, Peter -- This inert sentence is my body, but my soul is alive, dancing in the sparks of your brain. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message