Как развернуть https-приложение Twistd (.tac) с systemd в качестве непривилегированного пользователя? - PullRequest
Новая
       44

Как развернуть https-приложение Twistd (.tac) с systemd в качестве непривилегированного пользователя?

1 голос
/ 21 марта 2019

My https (порт 443) приложение twistd (.tac) отлично работает, развернуто как служба systemd, но для файла модуля требуется user: root, чтобы прослушивать / связывать порты ниже 1000. Проблема в том, что twistd работает также как пользователь: root.

Как прослушать / связать порт 443, а затем передать его в Твиттере .tac как непривилегированному пользователю?

Я хотел бы следовать рекомендациям «Разделение привилегий» и избегать обходных путей, таких как setcap'cap_net_bind_service = + ep' или переадресация портов, как подробно описано здесь .

Я попытался systemd, используя Socket Activation с файлом модуля .service.Мой .socket работает для прослушивания / привязки на привилегированном порту 443. И файл .service запускает приложение twistd .tac от имени непривилегированного пользователя, но передача обслуживания сокета не работает, и twistd завершает работу с ошибкой «разрешение запрещено».После поиска я обнаружил «Известная проблема: Twisted не поддерживает прослушивание SSL-соединений на сокетах, унаследованных от systemd» в последней строке этого Twisted doc .Я использую Twisted 18.9.0 Ubuntu 18.04.

Частичный успех со следующими файлами .service и .socket:

Файл моего служебного блока Systemd: 

[Unit]
Description=twistd https application
#Requires=testtls.socket

[Service]
ExecStart=/usr/bin/twistd --nodaemon --pidfile= --python=/ws/twistdhttps.tac
WorkingDirectory=/srv/web/https
#User=nobody   #twistd .tac permission denied
#Group=nogroup #twistd .tac permission denied
User=root   #twistd .tac works but no separation of privileges
Group=root  #twistd .tac works but no separation of privileges

Restart=always
#NonBlocking=true

[Install]
WantedBy=multi-user.target

сокет Systemdфайл testtls.socket: 

[Socket]
ListenStream=0.0.0.0:443

[Install]
WantedBy=sockets.target

1 Ответ

0 голосов
/ 27 марта 2019

Я разработал решение обратного прокси-типа с двумя файлами systemd, которое, как я понимаю, является не элегантным способом по сравнению с передачей сокета из одного файла systemd.Один из моих файлов .service имеет пользователя root, а другой - непривилегированного пользователя.Файл перенаправления .service использовал twisted.web.util.redirect (последний документ здесь ) можно перенаправить с 443 на 8443. Другой файл .service прослушивает порт 8443 и, что наиболее важно, как непривилегированный пользователь.

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

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

В настоящее время яЯ принимаю это как лучший ответ, так как он поможет всем, кто сталкивается с той же проблемой, но я надеюсь, что кто-то опубликует лучшее, более элегантное решение.

...