Существует ли путь к некорневым процессам для привязки с “привилегированными” портами на Linux?

Использование PDO и MYSQLi является хорошей практикой для предотвращения инъекций SQL, но если вы действительно хотите работать с функциями и запросами MySQL, было бы лучше использовать

mysql_real_escape_string

$unsafe_variable = mysql_real_escape_string($_POST['user_input']);

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

is_string

$unsafe_variable = (is_string($_POST['user_input']) ? $_POST['user_input'] : '');

is_numeric

$unsafe_variable = (is_numeric($_POST['user_input']) ? $_POST['user_input'] : '');

И гораздо лучше использовать эти функции для проверки входных данных с помощью mysql_real_escape_string.

362
задан tomix86 2 January 2018 в 15:33
поделиться

7 ответов

Хорошо, благодаря людям, которые указали на систему возможностей и CAP_NET_BIND_SERVICE возможность. Если у Вас есть недавнее ядро, действительно возможно использовать это, чтобы запустить сервис как некорневой, но связать низкие порты. Короткий ответ - то, что Вы делаете:

setcap 'cap_net_bind_service=+ep' /path/to/program

И затем в любое время program выполняется после этого, это будет иметь CAP_NET_BIND_SERVICE возможность. setcap находится в debian пакете libcap2-bin.

Теперь для протестов:

  1. Вам будут нужны, по крайней мере, 2.6.24 ядер
  2. , Это не будет работать, если Ваш файл будет сценарием. (т.е., использует #! строка для запуска интерпретатора). В этом случае, настолько далеко я, как понимают, необходимо было бы применить возможность к самому исполняемому файлу интерпретатора, который, конечно, является кошмаром безопасности, так как любая программа с помощью того интерпретатора будет иметь возможность. Я не смог найти любой чистый, простой способ работать вокруг этой проблемы.
  3. Linux отключит LD_LIBRARY_PATH на любом program, который поднял полномочия как setcap или suid. Таким образом, если Ваш program использование его собственное .../lib/, Вам, возможно, придется изучить другую опцию как перенаправление портов.

Ресурсы:

Примечание: RHEL сначала добавил это в v6.

373
ответ дан Cristian Ciupitu 23 November 2019 в 00:11
поделиться

Поддержки Linux возможности для поддержки более мелкомодульных полномочий, чем просто "это приложение выполняются как корень". Одна из тех возможностей CAP_NET_BIND_SERVICE, который является о привязке к привилегированному порту (< 1024).

, К сожалению, я не знаю, как использовать это для запуска приложения как некорневого, все еще давая его CAP_NET_BIND_SERVICE (вероятно, использование setcap , но там обязан быть существующим решением для этого).

13
ответ дан Cristian Ciupitu 23 November 2019 в 00:11
поделиться

Две других простых возможности:

существует старое (немодное) решение "демон, который привязывает низкий порт и вручает управление Вашему демону". Это назвало inetd (или xinetd). Недостатки:

  • Ваш демон должен говорить на stdin/stdout (если Вы не управляете демоном - если у Вас нет источника - тогда это - возможно, showstopper, хотя некоторые сервисы могут иметь флаг inetd-совместимости)
  • , новый процесс демона разветвлен для каждого соединения
  • , это - одно дополнительное звено цепи

Профессионалы:

  • доступный на каком-либо старом UNIX
  • , как только Ваш системный администратор настроил конфигурацию, Вы хороши для движения о разработке (когда Вы восстанавливаете своего демона, Вы могли бы потерять setcap возможности? И затем необходимо будет вернуться к администратору "сэр...")
  • , демон не должен волноваться о том сетевом материале, просто должен говорить на stdin/stdout
  • , может настроить для казни демона как некорневого пользователя, как требуется

Другая альтернатива: взломанный прокси (netcat или даже что-то [еще 110] устойчивый ) от привилегированного порта до некоторого произвольного порта с высоким номером, куда можно выполнить целевого демона. (Netcat является, очевидно, не производственным решением, но "просто моим dev полем", право?). Таким образом, Вы могли продолжить использовать способную к сети версию своего сервера, будет только нуждаться в root/sudo для запуска прокси (при начальной загрузке), не полагался бы на сложные/потенциально хрупкие возможности.

15
ответ дан Martin Carpenter 23 November 2019 в 00:11
поделиться

Или исправьте свое ядро и удалите проверку.

(Опция последней инстанции, не рекомендуемая).

В net/ipv4/af_inet.c, удалите две строки, которые читают

      if (snum && snum < PROT_SOCK && !capable(CAP_NET_BIND_SERVICE))
              goto out;

, и ядро не будет больше проверять привилегированные порты.

23
ответ дан Joshua 23 November 2019 в 00:11
поделиться

Стандартный путь состоит в том, чтобы сделать их "setuid" так, чтобы они запустили как корень, и затем они выбрасывают то полномочие пользователя root, как только они связали с портом, но прежде чем они начнут принимать соединения с ним. Вы видите хорошие примеры этого в исходном коде для Apache и INN. Мне говорят, что Lighttpd является другим хорошим примером.

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

31
ответ дан Kev 23 November 2019 в 00:11
поделиться

В моем «стандартном обходном пути» в качестве перенаправителя пользовательского пространства используется socat:

socat tcp6-listen:80,fork tcp6:8080

Остерегайтесь, что это не будет масштабирование, разветвление стоит дорого, но так работает socat.

14
ответ дан 23 November 2019 в 00:11
поделиться

Вы можете перенаправить порт. Это то, что я делаю для сервера политик Silverlight, работающего на Linux

iptables -A PREROUTING -t nat -i eth0 -p tcp --dport 943 -j REDIRECT --to-port 1300
32
ответ дан 23 November 2019 в 00:11
поделиться
Другие вопросы по тегам:

Похожие вопросы: