Editor With NO Shell Access?

C. P. Ghost cpghost at cordula.ws
Tue Mar 13 15:16:00 UTC 2012

On Mon, Mar 12, 2012 at 8:19 PM, Tim Daneliuk <tundra at tundraware.com> wrote:
> 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.

If the requirements are THAT hard, I think it would be
best to do it the good ole fashioned way: modify the
source code of their favorite editor, by patching out ALL
calls to system(2), exec*(2), popen() et al. This way,
you'll be sure that editor binary won't call out ANY external
process whatsoever.

A little bit less secure, but based on the same idea, would
be to provide replacements for those process-creating
functions in a custom library, say, libnofork.so where each
of these functions immediately return or signal an error like
EPERM instead of ultimately doing the syscall. Then link your
client's editor with -lnofork to mask the original libc definitions.

It is a little bit less secure than manually removing or commenting
out calls to system(), exec*(), popen*() etc, because the editor
could at least in theory call dlopen() on the original libc, where
the functions are still there, or it could even issue the kernel
syscalls directly, without going through libc... although that is
very unlikely with the usual editors.

It is also less secure, because from within this modified editor,
the user could read the contents of libc.so into libnofork.so, and
then restart the editor. But you get the basic idea.

Alternatively, you may want to look into ways to disable forking()
in general for a process. Some old Unices provided a way to
selectively disable certain syscalls based on some root-definable
administrative per-user or per-application policy, but I don't know
whether this is possible with FreeBSD. Perhaps the new Capsicum [1]
provides this, or will in the foreseeable future? I have not looked into
it yet.

[1]: http://www.cl.cam.ac.uk/research/security/capsicum/

> So ... are there editors without this feature?  Can I compile something like
> joe or vi to inhibit this feature?

Yes, see above: provide a replacement library and link against that.
Consider static linking for slightly increased security, and make sure
the user can't modify the editor binary, can't modify any dynamic
libraries it links against, and can't replace that binary with another
binary. Security is like an onion.

> Tim Daneliuk     tundra at tundraware.com
> PGP Key:         http://www.tundraware.com/PGP/


Cordula's Web. http://www.cordula.ws/

More information about the freebsd-questions mailing list