Date: Sat, 29 Aug 1998 15:38:14 -0500 From: "Jeffrey J. Mountin" <jeff-ml@mountin.net> To: Paul Hart <hart@iserver.com> Cc: freebsd-security@FreeBSD.ORG Subject: Re: Shell history Message-ID: <3.0.3.32.19980829153814.0076e548@207.227.119.2> In-Reply-To: <Pine.BSF.3.96.980829101329.3522B-100000@anchovy.orem.iserv er.com> References: <Pine.NEB.4.00.9808291000010.279-100000@phluffy.lm.com>
next in thread | previous in thread | raw e-mail | index | archive | help
At 10:19 AM 8/29/98 -0600, Paul Hart wrote: >On Sat, 29 Aug 1998, Mike Holling wrote: > >> A sufficiently skilled attacker will probably always be able to get root >> once they have shell access on a box. The key is to prevent them from >> getting to that point in the first place. > >That's a broad statement. I won't contest the fact that if users have >shell access you are now open to a much larger array of possible attacks >(like local SUID buffer overflow attacks and /tmp races), but saying that >they will always be able to get root is not an accurate statement. Much discussion has passed before on the lists concerning the issues brought up in this thread. The best bet for ISP's is not to give shell access unless really needed. Simple enough. Now there are legit users that will want shell and my thought is to give it. Add a surcharge (and live with the complaints) and work out how you want to allow the shell access. I'd say it should be a "sacrifice" machine that isn't running any essential services, has no special privileges to other machines, and should be on it's own segment of the network with remote logging to a secured server. (web servers would need to be handled a bit different, but there are more alternatives there) The tricky part is how to deal with the shell access itself. Creating a chroot environment would take some work, but once done simple to duplicate, but it has been pointed out in the past that chroot has weaknesses, as pointed out in several old threads. Has any work been done to make chroot more absolute? Or is it the implementation of chroot? The following is straightforward: At 05:07 PM 12/31/97 +1100, Daniel O'Callaghan wrote: >On Wed, 31 Dec 1997, Ernie Elu wrote: > >> I know it is not too hard to set up a virtual domain, website, and ftp site >> for a client, but is it possible to have a restricted login? >> >> By that I mean if you have a freebsd system hosting www.xyz.com and the >> client wants to be able to telnet in to hand edit files, is it possible to >> restrict their access to only their home directory and its subdirectories? >> >> Sort of an automated chroot thing you can't bypass I guess. > >Build a chrooted area with /etc, /bin, /usr/bin, /usr/lib, /usr/libexec >files which are necessary. >Change inetd to run telnetd.sh and have telnetd.sh do: > >----- >#!/bin/sh >cd /newroot >/usr/sbin/chroot . exec /usr/libexec/telnetd >----- > >Danny This means that there would be common area for all shell users and I'd wonder if root would be restricted to console and ssh perhaps. As long as there are no problems with someone escaping the chroot or affecting the system outside this environment. This would be the solution. It does add a bit of complexity and means that each user will take up quite a bit more space, but they don't need every binary in the default path. It would be easier to limit the impact than to try to fix every flaw. Jeff Mountin - Unix Systems TCP/IP networking jeff@mountin.net To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3.0.3.32.19980829153814.0076e548>