I can think of several options for giving users a reasonable editor with as much paranoia as possible. Since this is a security-sensitive application please take everything here with a grain of salt.

I'd suggest doing one of these things as the default, but making it possible in a clearly documented way for people to use their own vim as a clearly documented option so they don't try to copy data out of the locked-down vi.

Also some of these suggestions (in particular messing with LD_PRELOAD) might be totally unacceptable, disabled (as much as that's possible), or limited in your environment.

Here's some potentially mutually exclusive options in no particular order,

1. run the editor as an unprivileged user, like sudoedit does.
2. provide your own editor with features you don't want patched or compiled out
3. intercept calls to problematic libc functions with LD_PRELOAD.
4. skip the user's .vimrc completely.

1. run the editor as an unprivileged user

If you have the ability to create additional users or demand that people using the software create a dedicated unprivileged user, then you can use the same trick that sudoedit uses: creating a temporary file and having the user edit that as an unprivileged user. I don't know how to guarantee that the temporary file never touches the disk.

It sounds like you're already doing something similar to this, but without the unprivileged user.

Here's a superuser answer explaining how sudoedit works.

Also, I'd recommend studying how the sudoedit functionality of sudo works. here's some relevant code.

2. bundle your own vi.

nvi is small and BSD licensed, you might be able to patch it to never make swap files or compile it without swapfile support. I don't actually know because building the last time I tried building nvi I couldn't figure out how to get its ancient version of autotools to detect OS X.

As part of the build of your main product you can take the hash of your nvi executable and bake it in as a build-time constant.

Emacs users can get a copy of mg. Here's a link to a fork of mg. The variant that actually lives in OpenBSD's source tree is ISC licensed. You might need to patch it because it sometimes shells out (for instance, to interact with cscope).

Nano users are out of luck, I think.

3. LD_PRELOAD

use LD_PRELOAD to direct ld.so (on Linux) to load a shim to intercept calls to libc functions such as fwrite, fork, &c.

4. skip the user's config options in vim, run your own minimal config instead.

This is the most bulletproof command line for vim that I can think of, but I might have missed something. I only got it from reading the vim man page and looking at my .vimrc.

• -u NONE -- no initialization
• -i NONE -- no .viminfo
• -U NONE -- no initialization (gvim but hey you can never be too careful)
• -Z -- start as if your argv[0] was rvim.
• set nocompatible -- don't be vi-compatible.
• set backspace=indent,eol,start -- make backspace more intuitive
• set noexrc -- probably redunant, don't read any rc files.
• set secure -- no autocmd, no shell, no write, display - - map commands.
• set nobackup -- no backup options
• set laststatus=2 -- show the file you're editing

So, here's the command line putting it all together.

vim -n -u NONE -i NONE -U NONE -Z \ --cmd "set nocompatible | set backspace=indent,eol,start | set noexrc | set secure | set nomodeline | set nobackup | set laststatus=2" \ --