> From owner-freebsd-questi...@freebsd.org Mon Mar 12 14:22:29 2012 > Date: Mon, 12 Mar 2012 14:19:06 -0500 > From: Tim Daneliuk <tun...@tundraware.com> > To: FreeBSD Mailing List <freebsd-questions@freebsd.org> > 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>. (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'. _______________________________________________ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
