From owner-freebsd-hackers Fri Feb 9 21:30:29 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from homer.softweyr.com (bsdconspiracy.net [208.187.122.220]) by hub.freebsd.org (Postfix) with ESMTP id BBDAA37B4EC; Fri, 9 Feb 2001 21:30:11 -0800 (PST) Received: from [127.0.0.1] (helo=softweyr.com ident=Fools trust ident!) by homer.softweyr.com with esmtp (Exim 3.16 #1) id 14RSkR-0000c9-00; Fri, 09 Feb 2001 22:39:03 -0700 Message-ID: <3A84D3F7.1CCE62A3@softweyr.com> Date: Fri, 09 Feb 2001 22:39:03 -0700 From: Wes Peters Organization: Softweyr LLC X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.12 i386) X-Accept-Language: en MIME-Version: 1.0 To: Nick Sayer Cc: Greg Black , kris@freebsd.org, freebsd-hackers@freebsd.org Subject: Re: /etc/security: add md5 to suid change notification? References: <200102082355.f18NtfF89134@medusa.kfu.com> <3A84582E.3000702@quack.kfu.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Nick Sayer wrote: > > Greg Black wrote: > > > Nick Sayer wrote: > > > >> Would it generally be viewed as helpful to add the option of reporting > >> the md5 for the files listed in /var/log/setuid.*? > > > > > > I don't see the benefit in this if either the md5 binary or the > > comparison file are on writable storage (which is almost always > > going to be true). > > Then why bother checking at all? Someone can trojan ls, or even easier, > arrange to trojan suid binaries without changing the things that show up > in that listing. > > Besides, security conscious folks could set the immutable flag for md5 > and/or the comparison file (and probably sh and ls while they're at it) > if they like. > > For the point kris made, I'm not sure he understood what I was > suggesting -- I'm not suggesting just printing the md5 of the files when > you notice they've changed, but adding the md5 as another trigger for > deciding which files have changed. Adding it as a field in > /var/log/setuid.* would achieve this end. Add a list of executables and their MD5's to the kernel, to be loaded at boot time via the loader. Modify the kernel loader to refuse to exec any executable whose MD5 is known but doesn't match. Ditto for shared libraries and ld.so. There you have it, a system that cannot be upgraded except in single-user mode. -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC wes@softweyr.com http://softweyr.com/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message