Date: Sat, 10 Feb 2001 07:16:55 +1000 From: Greg Black <gjb@gbch.net> To: Nick Sayer <nsayer@quack.kfu.com> Cc: kris@freebsd.org, freebsd-hackers@freebsd.org Subject: Re: /etc/security: add md5 to suid change notification? Message-ID: <nospam-3a845e474312a95@maxim.gbch.net> In-Reply-To: <3A84582E.3000702@quack.kfu.com> of Fri, 09 Feb 2001 12:50:54 PST References: <200102082355.f18NtfF89134@medusa.kfu.com> <nospam-3a8342fd530fe03@maxim.gbch.net> <3A84582E.3000702@quack.kfu.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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. This is in fact my point. The automated checks are just an indicator of changes that have happened on a normally running system -- they do nothing to guarantee that nothing has been tampered with by black hats and adding the md5 checks won't change that. They add to the cost of the checks without proving anything. The existing stuff warns me when an authorised admin has replaced a setuid program so that I can take any appropriate steps if I want to. But I have to employ other strategies (with tools like tripwire and off-line or read-only storage) if I want to make serious checks on vulnerable systems. > 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. Unless things have changed, the use of elevated security levels (which are necessary if those flags are to have any force) has side effects that make them useless on lots of systems (e.g., inability to run X). Greg To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?nospam-3a845e474312a95>