Я пишу приложение, которое поддерживает зашифрованную базу данных, содержащую чрезвычайно конфиденциальную информацию, включая криптографические ключи и пароли. Приложение параноидально относится к использованию memlock, блокировке ptrace, предотвращению coredumps и т. д., но имеет команду, позволяющую владельцу базы данных редактировать содержимое базы данных. Эта команда записывает всю базу данных во временный файл в удобном для восприятия формате ASCII и позволяет пользователю редактировать ее. В частности, она создает новый файл в недавно созданном каталоге /tmp/XXXXXXXX/
(где /tmp в идеале является файловой системой памяти), затем запускает предпочитаемый пользователем редактор для файла. Когда редактор завершает работу, приложение анализирует содержимое файла и уничтожает файл и все остальное в нем, /tmp/XXXXXXXX/
прежде чем окончательно удалить каталог.
К сожалению, эта стратегия не очень хорошо работает ни с одним из вариантов vi, потому что редактор в конечном итоге записывает копии файла в /var/tmp/vi.recover, где они, скорее всего, сохранятся на диске даже после того, как vi удалит их. (Данные содержат высокоценные закрытые ключи, для которых можно было бы легко выполнить поиск по всему необработанному разделу.) Я ищу универсальный способ подавления этих файлов восстановления или, по крайней мере, перемещения их в /tmp/XXXXXXXX/
.
Мое идеальное решение будет работать для большинства вариантов vi, но я также счастлив анализировать EDITOR
переменную окружения и делать что-то свое для каждого редактора. Таким образом, если у вас есть решение, которое работает для vim, но не для других, это по крайней мере хорошее начало. (Я уже специально отношу vim к повторному открытию редактора для точного номера столбца ошибки анализа, тогда как другие варианты vi можно открыть только для соответствующей строки.)
Поскольку это приложение, которое должно распространяться среди других людей, единственное, что я не могу сделать, это решить проблему, редактируя файлы .exrc или .vimrc других людей. В крайнем случае, я полагаю, я мог бы изменить переменную окружения HOME перед запуском редактора и создать временный .vimrc, который объединит реальную переменную пользователя с некоторыми командами восстановления-подавление. Однако я бы предпочел решение с помощью командной строки или комментариев.
Самое близкое, что я могу сделать к минимальному рабочему примеру, — это поделиться тем, что я делаю для emacs, а именно, добавляю следующий комментарий в конец файла:
# Local Variables:
# make-backup-files: nil
# auto-save-default: nil
# End:
Хотя проще всего использовать параметр командной строки, если какой-то эквивалентный комментарий может работать для vim или любого другого варианта vi, это тоже было бы здорово.
обновлять:
После некоторых экспериментов со strace, похоже, следующая командамощьделаю то, что хочу для vim:
vim -n -c 'set viminfo=' /tmp/XXX/secret.ini
Однако, это не работает с --cmd
, что было предложено, а только с -c
. Более того, я не совсем понимаю, что -n
работает, но только что заметил, что на странице руководства сказано, что это сломает восстановление. Поэтому я все равно хотел бы услышать ответ от кого-то, кто разбирается в vim, если это действительно работает. И, конечно, решения для других вариантов vi были бы приветствуются.
обновление 2:
Переменная среды EXINITмощьработает для vi и nvi, если я устанавливаю его в EXINIT=set dir=/tmp/XXX|set recdir=
. nvi выдает предупреждение об отсутствии восстановления при запуске, что обнадеживает, в то время как vi действительно сбрасывает файлы в файловую систему, но, по крайней мере, они находятся в /tmp, который часто является файловой системой памяти.
решение1
Для того, чтобы vim
вы могли переместить местоположение файла восстановления с помощьюdirectory
вариант.
set directory=/tmp/XXXXXXXX
Это можно добавить в командную строку для одного экземпляра, например:
mkdir -m700 /tmp/xyz
vim --cmd "set directory=/tmp/xyz" /path/to/secure.file
решение2
Я могу придумать несколько вариантов, как дать пользователям разумный редактор с максимально возможной степенью паранойи. Поскольку это чувствительное к безопасности приложение, пожалуйста, воспринимайте все здесь с долей скепсиса и, пожалуйста, исправьте любые ошибки.
Я бы предложил сделать одну из этих вещей по умолчанию, но при этом предоставить людям возможность использовать свои собственные файлы vim
в качестве четко документированной опции, чтобы они не пытались копировать данные из заблокированного файла vi
.
Кроме того, некоторые из этих предложений (в частности, вмешательство в LD_PRELOAD
) могут быть совершенно неприемлемы, неэффективны (насколько это возможно) или ограничены в вашей среде.
Вот несколько потенциально взаимоисключающих вариантов в произвольном порядке:
- запустите редактор как непривилегированный пользователь, как
sudoedit
это делает . - предоставьте свой собственный редактор с функциями, которые вы не хотите патчить или компилировать
- перехватывать вызовы проблемных
libc
функций с помощьюLD_PRELOAD
. - полностью пропустить пользователя
.vimrc
.
1) запустить редактор как непривилегированный пользователь
Если у вас есть возможность создавать дополнительных пользователей или требовать, чтобы люди, использующие программное обеспечение, создавали отдельного непривилегированного пользователя, то вы можете использовать тот же трюк, который sudoedit
используется: создание временного файла и предоставление пользователю возможности редактировать его как непривилегированного пользователя. Я не знаю, как гарантировать, что временный файл никогда не коснется диска.
Похоже, вы уже делаете что-то подобное, но без непривилегированного пользователя.
Вотответ суперпользователя, объясняющий, как sudoedit
работает.
Также я бы рекомендовал изучить, как работает sudoedit
функционал sudo
.вот некоторый соответствующий код.
2) соберите свой собственный vi
.
nvi
небольшой и лицензирован BSD, вы можете пропатчить его, чтобы он никогда не создавал файлы подкачки или скомпилировать его без поддержки файла подкачки. Я на самом деле не знаю, потому что в последний раз, когда я пытался собрать, nvi
я не мог понять, как заставить его древнюю версию autotools обнаружить OS X.
В рамках сборки вашего основного продукта вы можете взять хэш вашего nvi
исполняемого файла и включить его в качестве константы времени сборки.
Пользователи Emacs могут получить копию mg
. Вотссылка на форк mg. Вариант, который на самом деле находится в исходном дереве OpenBSD, лицензирован ISC. Возможно, вам придется его пропатчить, поскольку он иногда стоит денег (например, для взаимодействия с cscope
).
Я думаю, пользователям Nano не повезло.
3)LD_PRELOAD
используется LD_PRELOAD
для прямой ld.so
загрузки (в Linux) оболочки для перехвата вызовов libc
таких функций, как fwrite
, fork
, и т. д.
4) пропустите параметры конфигурации пользователя в vim
, вместо этого запустите свою собственную минимальную конфигурацию.
Это самая надежная командная строка, vim
которую я могу придумать, но я мог что-то упустить. Я понял это только прочитав man-страницу vim и посмотрев на свой .vimrc
.
-u NONE
-- нет инициализации-i NONE
-- нет.viminfo
-U NONE
-- без инициализации (gvim
но осторожность никогда не помешает)-Z
-- начните так, как будтоargv[0]
выrvim
.set nocompatible
-- не будьтеvi
-совместимы.set backspace=indent,eol,start
-- сделать клавишу Backspace более интуитивно понятнойset noexrc
-- вероятно, излишне, не читайте никакихrc
файлов.set secure
-- нетautocmd
, нетshell
, нетwrite
, дисплей - -map
команды.set nobackup
-- нет резервных вариантовset laststatus=2
-- показать файл, который вы редактируете
Итак, вот командная строка, объединяющая все это.
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" \
--