From owner-freebsd-security Sun Aug 12 7:37:52 2001 Delivered-To: freebsd-security@freebsd.org Received: from kawoserv.kawo2.rwth-aachen.de (kawoserv.kawo2.RWTH-Aachen.DE [134.130.180.1]) by hub.freebsd.org (Postfix) with ESMTP id 47EC837B409 for ; Sun, 12 Aug 2001 07:37:47 -0700 (PDT) (envelope-from doegi@kawo2.rwth-aachen.de) Received: (from doegi@localhost) by kawoserv.kawo2.rwth-aachen.de (8.9.3/8.9.3) id QAA17420 for freebsd-security@FreeBSD.org; Sun, 12 Aug 2001 16:37:46 +0200 Date: Sun, 12 Aug 2001 16:37:46 +0200 From: Alexander Langer To: freebsd-security@FreeBSD.org Subject: providing security patches, patching live kernels Message-ID: <20010812163746.A17136@kawoserv.kawo2.rwth-aachen.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0pre3us X-PGP-Fingerprint: 44 28 CA 4C 46 5B D3 A8 A8 E3 BA F3 4E 60 7D 7F X-PGP-at: finger alex@big.endian.de X-Verwirrung: Dieser Header dient der allgemeinen Verwirrung. Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Hi! I've created a kernel module, which replaces the insecure nfs_mount() function (from nfs_vfsops.c) with the fixed version Peter Wemm committed on Friday in a running kernel. (it modifies the nfs_vfsops structure, for those that are interested; I also tried a different approach, that can be used with any arbitrary function in the kernel). Having such a thing, I had the idea to create some distribution channel (a ports category or signed packages from ftp [I prefer the latter]) for security fixes (similar to the fixes to the RELENG_4_3 branch!). Those packages could be applied to a running system w/o the need to rebuild/reboot a kernel or fix network daemones (in case of telnetd etc). The next security advisories could then describe either how to manually apply a patch, or just say "To fix, just do pkg_install ftp://ftp.freebsd.org/pub/FreeBSD/security-fixes/RELENG_4/foobar-fix-01.tgz". Could be quite handy. I strongly believe that even most kernel security flaws can be fixed by modules that provide their own function. However, this is only a temporary solution until the administrator was able to build a new kernel(!), but it's _really_ useful if you want the security fix but mustn't reboot a system. However, having such a service would be quite cool! As an example, see the nfspatch kernel mod at http://people.freebsd.org/~alex/nfspatch.tar.gz Just build and load the module. To verify that it actually replaces the function, you might want to add a printf() and mount_nfs some volume. A fix package could install some script that load the kernel modul only until a fixed kernel was built (however this is done) Comments? Alex To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message