From owner-freebsd-security Tue May 2 10:10:47 1995 Return-Path: security-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id KAA10187 for security-outgoing; Tue, 2 May 1995 10:10:47 -0700 Received: from halloran-eldar.lcs.mit.edu (halloran-eldar.lcs.mit.edu [18.26.0.159]) by freefall.cdrom.com (8.6.10/8.6.6) with SMTP id KAA10181 for ; Tue, 2 May 1995 10:10:40 -0700 Received: by halloran-eldar.lcs.mit.edu; (5.65/1.1.3.6) id AA00462; Tue, 2 May 1995 13:10:20 -0400 Date: Tue, 2 May 1995 13:10:20 -0400 From: Garrett Wollman Message-Id: <9505021710.AA00462@halloran-eldar.lcs.mit.edu> To: Brant Katkansky Cc: security@FreeBSD.org Subject: Security options for NFS? In-Reply-To: <199505021046.DAA00960@dtr.com> References: <199505021046.DAA00960@dtr.com> Sender: security-owner@FreeBSD.org Precedence: bulk < said: > I'm looking to secure NFS and other services not covered by tcpd - > what's the conventional wisdom for FreeBSD 2.0? NFS has fairly strong access-control checks provided by the kernel code. However, these only operate on a per-mount-point basis. If you specify a host list in /etc/exports, then the NFS server will d oits best to ensure that only the hosts listed are able to access the data, even given a valid file handle. The portmapper is fairly harmless, provided you don't start any services that in themselves are security problems. The FreeBSD versions of `mountd' and YP are reasonable; some of the other RPC services you may want to restrict or just plain not run depending on your security policy (e.g., rusers, rstat). -GAWollman -- Garrett A. Wollman | Shashish is simple, it's discreet, it's brief. ... wollman@lcs.mit.edu | Shashish is the bonding of hearts in spite of distance. Opinions not those of| It is a bond more powerful than absence. We like people MIT, LCS, ANA, or NSA| who like Shashish. - Claude McKenzie + Florent Vollant