Рекомендации по элегантному шифрованию / дешифрованию скриптов? [Теперь на Sourceforge]

Question

Update2:

Спасибо за ввод. Я реализовал алгоритм, и он доступен для скачивания на SourceForge . Это мой первый проект с открытым исходным кодом, так что будьте милостивы.

Обновление:

Я не уверен, что был достаточно ясен, или все, кто откликнулся на это, понимают, как оболочки # потребляют #! тип ввода. Отличная книга - Advanced Unix Programming. Достаточно вызвать popen и передать его стандартный ввод, как показано здесь .

Оригинальный вопрос:

Наши скрипты работают в сильно распределенной среде со многими пользователями. Использование разрешений для их скрытия проблематично по многим причинам.

Поскольку первая строка может использоваться для обозначения «интерпретатора» для сценария, начальная строка может использоваться для определения расшифровщика

#!/bin/decryptandrun
*(&(*S&DF(*SD(F*SDJKFHSKJDFHLKJHASDJHALSKJD
SDASDJKAHSDUAS(DA(S*D&(ASDAKLSDHASD*(&A*SD&AS
ASD(*A&SD(*&AS(D*&AS(*D&A(SD&*(A*S&D(A*&DS

Учитывая, что я могу написать сценарий для шифрования и поместить соответствующий заголовок, я хочу расшифровать сценарий (который сам может иметь строку интерпретатора, такую ​​как #! / Bin / perl вверху), не делая ничего глупого, как записать его во временный файл. Я нашел несколько глупых коммерческих продуктов для этого. Я думаю, что это может быть достигнуто в течение нескольких часов. Есть ли хорошо известный способ сделать это с помощью каналов, а не кодировать системные вызовы? Я думал об использовании execvp , но лучше ли заменить текущий процесс или создать дочерний процесс?

Answer 1

Если ваши пользователи могут запускать программу decryptandrun, то они могут читать ее (и любые файлы, которые нужно прочитать, например ключи дешифрования). Таким образом, они могут просто извлечь код для расшифровки самих сценариев.

Вы можете обойти это, сделав decrtyptandrun suid. Но тогда любая ошибка в нем может привести к тому, что пользователь получит привилегии root (или, по крайней мере, привилегии для учетной записи, которая содержит ключи дешифрования). Так что это, вероятно, не очень хорошая идея. И, конечно же, если вы приложили все усилия, чтобы скрыть содержимое или ключи этих сценариев дешифрования, сделав их недоступными для чтения пользователю ... то почему вы не можете сделать то же самое с содержимым сценариев, которые вы пытаешься спрятаться?

Кроме того, вы не можете иметь интерпретируемый исполняемый файл #! в качестве интерпретатора для другого интерпретируемого исполняемого файла #!.

И одно из фундаментальных правил криптографии: не изобретайте свой собственный алгоритм шифрования (или инструменты), если вы не опытный криптоаналитик.

Что заставляет меня задуматься, почему вы чувствуете необходимость шифровать сценарии, которые будут запускать ваши пользователи. Что-то не так с ними, когда они видят содержание сценариев?

Answer 2

Ответ Брайана Кэмпбелла имеет правильную идею, я изложу это:

Вам нужно сделать ваш скрипт нечитаемым, но исполняемым пользователем (jbloggs), и сделать decodeandrun setuid. Вы можете сделать его setuid root, но было бы намного безопаснее вместо него установить setgid для некоторой группы decodegroup, а затем установить группу файла сценария на decodegroup. Необходимо убедиться, что decodegroup имеет разрешения на чтение и выполнение файла сценария и что jbloggs не является членом этой группы.

Обратите внимание, что decodegroup требуется разрешение на чтение, чтобы decodeandrun мог прочитать текст файла сценария.

При такой настройке возможно (по крайней мере, в Linux) для jbloggs выполнить скрипт, но не посмотреть на него. Но обратите внимание, что делает сам процесс дешифрования ненужным - файл сценария также может быть открытым текстом, поскольку jbloggs не может его прочитать.

[ОБНОВЛЕНИЕ: только что понял, что эта стратегия не обрабатывает случай, когда зашифрованное содержимое само по себе сценарий, который начинается с #!. Ну что ж.]

Answer 3

Вы решаете не ту проблему. Проблема в том, что у вас есть данные, к которым вы не хотите, чтобы пользователи обращались, и эти данные хранятся в месте, к которому у пользователей есть доступ. Начните с попытки решить проблему пользователей с большим доступом, чем им требуется ...

Если вы не можете защитить весь сценарий, возможно, вы захотите просто защитить данные. Переместите его в другое место и зашифруйте. Зашифруйте данные с помощью ключа, доступного только по определенному идентификатору (желательно не root), и напишите небольшую программу suid для доступа к данным. В вашей программе setuid выполните проверку того, кто должен запускать программу, и сравните имя / контрольную сумму вызывающей программы (вы можете проверить командную строку для процесса в сочетании с cwd вызывающего процесса, чтобы найти путь, используйте lsof или файловая система / proc) с ожидаемым значением перед расшифровкой.

Если для этого требуется больше, вам действительно необходимо пересмотреть состояние пользователей в системе - у них слишком много доступа или у вас слишком мало доверия. :)

Answer 4

Все функции семейства exec(), на которые вы ссылаетесь, принимают имя файла, а не адрес памяти. Я совсем не уверен, как бы вы поступили так, как хотите, то есть «подключили» процедуру расшифровки, а затем перенаправили на расшифрованный скрипт #! переводчик.

Это потребует от вас расшифровки сценария во временный файл и передачи этого имени файла вызову exec(), но вы (очень разумно) сказали, что не хотите раскрывать сценарий, помещая его во временный файл .

Если бы можно было сказать ядру заменить новый процесс существующим в памяти, у вас был бы путь, по которому я должен идти, но, насколько я знаю, это не так. Так что я не думаю, что это будет очень легко сделать "прикованным" #! следующее.