From owner-freebsd-questions@FreeBSD.ORG Mon Mar 12 20:47:33 2012 Return-Path: Delivered-To: freebsd-questions@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5B7EA106564A for ; Mon, 12 Mar 2012 20:47:33 +0000 (UTC) (envelope-from bonomi@mail.r-bonomi.com) Received: from mail.r-bonomi.com (mx-out.r-bonomi.com [204.87.227.120]) by mx1.freebsd.org (Postfix) with ESMTP id 0AB138FC0A for ; Mon, 12 Mar 2012 20:47:32 +0000 (UTC) Received: (from bonomi@localhost) by mail.r-bonomi.com (8.14.4/rdb1) id q2CKirgv046912; Mon, 12 Mar 2012 15:44:53 -0500 (CDT) Date: Mon, 12 Mar 2012 15:44:53 -0500 (CDT) From: Robert Bonomi Message-Id: <201203122044.q2CKirgv046912@mail.r-bonomi.com> To: freebsd-questions@freebsd.org, tundra@tundraware.com In-Reply-To: <4F5E4C2A.1020005@tundraware.com> Cc: Subject: Re: Editor With NO Shell Access? X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Mar 2012 20:47:33 -0000 > From owner-freebsd-questions@freebsd.org Mon Mar 12 14:22:29 2012 > Date: Mon, 12 Mar 2012 14:19:06 -0500 > From: Tim Daneliuk > To: FreeBSD Mailing List > Subject: Editor With NO Shell Access? > > I have a situation where I need to provide people with the ability to edit > files. However, under no circumstances do I want them to be able to exit > to the shell. The client in question has strong (and unyielding) InfoSec > requirements in this regard. > > So ... are there editors without this feature? Can I compile something like > joe or vi to inhibit this feature? If the need is for 'simple'/'minimal' editing -- as opposed to, say, regex- based global-search-and-replace, A more-or-less 'easy' way to do this could be to use a web browser. .htaccess to determine who can access what file, probably from a specific list. a cgi-bin that, on validate access, loads the file into a 'textarea' on a
. (form has a 'hidden' field that identifies the file being edited, User makes changes in the 'text' block, clicks 'update' (form 'submit' button) when finished. There's a .htaccess on the form-processing cgi-bin to re-validate the submission. (prevents somebody 'faking' a file update without actual permission.) The cgi-bin then re-writes the edited file. Depending on 'security' requirements, you may need a shared-memory cache -- used between the two cgi-bin invocations -- to provide 'session' locking, prevent 'overlapping' updates, and trap _all_ 'forged' file updates. This has some 'maintainablity' advantages over the 'hacked' editor approach. It's much clearer to a future person just _what_ is going on. It's also clear to the user what they can, and _cannot_ do. This has major beneficial effect on those who attempt to 'push the limits'. Hack the editor to disable functionality, and _somebody_ *will* complain that they =need= that functionality, for a 'superficially plausable' reason. Otherwise, hacking the source code for, say, 'vi', should -not- be very difficult. Look for the logic that processes '!!' or ":!" at the beginning of an input sequence, and disable the related functionality. You could probably make a dinky little library -- with 'fake' routines for 'fork', 'exec', and 'pipe'; routes that 'do nothing' other than raise a security alert, and include that in the compile/link for a customized 'vi', before 'libc'.