Как фильтровать опасные символы в сценарии bash?

Question

Я работаю над проектом, который использует огромное количество shellscripts для всех целей, а производительность и мобильность важны. Некоторые из этих сценариев используют файлы конфигурации, которые имеют следующий формат:

VARIABLE1="value" 
VARIABLE2="several words, several values" 
VARIABLE3="a,list,of,words" 

Затем, чтобы использовать эти переменные, которые мы просто должны TDO следующее:

#!/bin/sh 
. /path/to/the/configuration.file 

echo "Var 1 is: $VARIABLE1" 
echo "Var 2 is: $VARIABLE2" 
echo "Var 3 is: $VARIABLE3" 

Простой, правильно?

Не так много. Дело в том, что в то время как мы можем защитить скрипты против модификации с простым chown root file.sh; chmod 0711 file.sh, конфигурационные файлы должны быть доступны для записи, а затем выяснить, что неприятные вещи, как это может произойти:

VARIABLE1="value"; rm requiredfile.data 
VARIABLE2="you dont want to see this: `rm anotherimportantfile.data` 
rm thelastrequiredfile.bin 

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

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

Что я сделал до сих пор:

FILTER=' 
/^$/d        # Delete empty lines 
/^#/d        # Delete comments 
/^[A-Z0-9_]\+=.\+$/{     # Select assignments 
/`/p         # alert with ` 
/\$/p        # alert with $ 
/\\/p        # alert with \ 
/;/p         # alert with ; 
d         # Accept the rest 
} 
' 
C=`sed -e "$FILTER" $1 | wc -l` 2>/dev/null 
if test $C -gt 0; then 
    echo "#ERR Suspicious strings in configuration file" 
fi 

Что мне не хватает? Любые улучшения?

PS: Я знаю, что можно было бы безопасно читать каждую переменную с помощью комбинации grep/cut, но о проблемах с производительностью не может быть и речи.

Answer 1

Забудьте о фильтре. Мое понимание этого вопроса заключается в том, что вы не должны давать права на запись/чтение в файле конфигурации напрямую кому-либо. вы должны назначать только разрешение sudo для одной группы, добавлять связанных пользователей в эту группу.

Answer 2

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

Если ограничить себя переменные быть назначены значения, которые всегда одиночные кавычки строки, единственный шаблон, который вы должны позволить это

^[A-Za-z_][A-Za-z0-9_]*='[^']*'[\t ]*$ 

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

Одиночные кавычки подавляют все метасимволы оболочки; любая строка в одинарных кавычках берется дословно.

Разрешение двойных кавычек или неуказанных строк просто вызывает проблемы. Переход на одинарные кавычки может быть немного хлопот, но если вы пришли сюда для консультаций по безопасности, это то, что вы получите.

Кстати, вы можете просто использовать grep искать нарушения:

if grep -v "^[A-Za-z_][A-Za-z0-9_]*='[^']*'[\t ]*$" configfile /dev/null >&2; then 
    echo "$0: Invalid lines in configfile -- aborting" >&2 
    exit 2 
fi 

. configfile 
: 
: 

Как пользователь, я оценил бы диагностическое сообщение включать нарушения. Это также позволяет избежать громоздкого объезда через wc -l.