Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 12 Mar 2012 15:44:53 -0500 (CDT)
From:      Robert Bonomi <bonomi@mail.r-bonomi.com>
To:        freebsd-questions@freebsd.org, tundra@tundraware.com
Subject:   Re: Editor With NO Shell Access?
Message-ID:  <201203122044.q2CKirgv046912@mail.r-bonomi.com>
In-Reply-To: <4F5E4C2A.1020005@tundraware.com>

next in thread | previous in thread | raw e-mail | index | archive | help
> 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 <tundra@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'.





Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201203122044.q2CKirgv046912>