From owner-freebsd-security Tue Jun 25 09:26:46 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id JAA13935 for security-outgoing; Tue, 25 Jun 1996 09:26:46 -0700 (PDT) Received: from husky.cslab.vt.edu (jaitken@husky.cslab.vt.edu [198.82.184.10]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id JAA13925 for ; Tue, 25 Jun 1996 09:26:43 -0700 (PDT) Received: (jaitken@localhost) by husky.cslab.vt.edu (8.6.12/8.6.4) id MAA06583; Tue, 25 Jun 1996 12:26:17 -0400 From: Jeff Aitken Message-Id: <199606251626.MAA06583@husky.cslab.vt.edu> Subject: Re: Re(2): I need help on this one - please help me track this guy down! To: Andrew.Gordon@net-tel.co.uk Date: Tue, 25 Jun 1996 12:26:17 -0400 (EDT) Cc: security@freebsd.org In-Reply-To: <"811-960625150230-D047*/G=Andrew/S=Gordon/O=NET-TEL Computer from "Andrew.Gordon@net-tel.co.uk" at Jun 25, 96 03:02:08 pm X-Mailer: ELM [version 2.4 PL24] Content-Type: text Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > But what file transfer mechanism was used? NFS maybe? > > Personally, I like to mount all NFS filesystems "nosuid" - and likewise > for all local systems exported by NFS (I don't normally export / or > /usr). Most users have no business creating setuid programs in their > filespace, and such a policy would most likely have prevented this > breach even if the setuid binary was created by some other means. One thing you can do to help with this sort of problem is to map UID 0 to some other UID. In our lab, we've got an AlphaStation which exports several filesystems via NFS. On a few administrative-type machines, we map UID 0 to UID 0 (so that root on any of the administrative machines can alter files as needed) but on the client machines (i.e., those machines used primarily by lab patrons) UID 0 is mapped to 'nobody' or somesuch. Furthermore, only system administrators have accounts on the servers; thus, even if someone breaks root on a client machine in the lab, they can't install any sort of backdoor on the server. If/when such a compromise is detected, we simply reinstall the OS on the client machine. I've got my FreeBSD installs down to an hour or so by now :-) Under Digital Unix, the syntax in /etc/exports goes something like this: /exported/filesystem -root=admin.machine.1 -root=admin.machine.2 client.machine.1 client.machine.2 and so on. I haven't set up this sort of thing under FreeBSD, but I believe the -maproot option provides equivalent functionality. See exports(5) for more information. None of this addresses the potential problem of address/hostname spoofing (i.e., if someone can convince the NFS server that they are one of the administrative machines, you're in trouble), but it's better than nothing. -- Jeff Aitken jaitken@cs.vt.edu