Editor With NO Shell Access?
Robert Bonomi
bonomi at mail.r-bonomi.com
Mon Mar 12 20:47:33 UTC 2012
> From owner-freebsd-questions at freebsd.org Mon Mar 12 14:22:29 2012
> Date: Mon, 12 Mar 2012 14:19:06 -0500
> From: Tim Daneliuk <tundra at tundraware.com>
> To: FreeBSD Mailing List <freebsd-questions at 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'.
More information about the freebsd-questions
mailing list