Подавлять файлы восстановления при редактировании конфиденциальных файлов в vi, nvi и vim

Подавлять файлы восстановления при редактировании конфиденциальных файлов в vi, nvi и vim

Я пишу приложение, которое поддерживает зашифрованную базу данных, содержащую чрезвычайно конфиденциальную информацию, включая криптографические ключи и пароли. Приложение параноидально относится к использованию 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) могут быть совершенно неприемлемы, неэффективны (насколько это возможно) или ограничены в вашей среде.

Вот несколько потенциально взаимоисключающих вариантов в произвольном порядке:

  1. запустите редактор как непривилегированный пользователь, как sudoeditэто делает .
  2. предоставьте свой собственный редактор с функциями, которые вы не хотите патчить или компилировать
  3. перехватывать вызовы проблемных libcфункций с помощью LD_PRELOAD.
  4. полностью пропустить пользователя .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" \
         --

Связанный контент