Позволить слушать порт конкретному юзеру

Не совсем то что вы хотите, но посмотрите man capabilities, особенно CAP_NET_BIND_SERVICE. Но тут привязка не UID а к конкретной программе.

Вроде еще iptables умеет матчить по uid и gid.

iptables -m owner --help
...
...
owner match options:
[!] --uid-owner userid[-userid]      Match local UID
[!] --gid-owner groupid[-groupid]    Match local GID
[!] --socket-exists                  Match if socket exists

Вот в случае с 80-ым портом, — его может слушать только root

Разве? Откуда инфа?

Разве? Откуда инфа?

оттуда. Все порты <1024 привилегированные. Уж две звезды набил, а азов не знает...

CAP_NET_BIND_SERVICE? Не, не слышал. Только рут может.

Ой, уже было в комментах выше.

угу. про --uid-owner для INPUT тоже было.

Уж две звезды набил

Ты так по своим двум соскучился? На тебе ★★, только не нервничай :)

iptables умеет матчить по uid и gid

На исходящий. Входящий не умеет.

точно. Я ошибся, ессно не INPUT, а OUTPUT.

Чтобы «слушать» (listen) порт — рут не нужен, чтобы «сесть» на порт (binding) — рут нужен. Так что делай как все приличные сервисы — биндишься на порт под рутом, потом сбрасываешь привилегии до юзера и слушаешь пока не надоест.

В общем случае bind() не требует доп. привилегий.

А вот bind() на девайс, на порт < 1024, не локальный ip - требует CAP_NET_RAW/CAP_NET_BIND_SERVICE/CAP_NET_ADMIN

Ну дык о портах < 1024 и идет речь, зачем зря умничать?

Это в смысле в отдельно взятом конкретном случае. На VPS стоит центось 5, там так настроено, кроме рута 80-ый слушать никто не может.

Изначально речь шла об абстрактном порте, но для примера привели 80-й порт, о чем я позабыл - тред длинный :)

Все равно хорошего способа запретить использовать порт для uid нет. IMHO только хак ядра. Причем его неоднократно обсуждали в netfilter-devel. Почему до сих пор -m owner для INPUT не запилили - непонятно. Технически проблем нет и накладные расходы не увеличиваются ( все равно это делается чуть позже, а при использоватнии tproxy - раньше).

ТС косноязычен, речь о bind to port < 1024 for unprivileged user

Подскажите, как-нибудь можно устроить так, чтобы конкретный порт мог слушать только определённый юзер?

iptables может блокировать порт для всех юзеров кроме явно указаных. Выше пример дали.

Но для Ъ тебе надо следующую технологию: https://en.wikibooks.org/wiki/Grsecurity/Appendix/Grsecurity_and_PaX_Configur...

В ванильном ядре её нет но патч можно скачать https://grsecurity.net/ Gentoo Hardened и Debian Hardened имеют поддержку сей фичи.

точно. Я ошибся, ессно не INPUT, а OUTPUT.

Ничего страшного, только OUTPUT вполне хватит! Да syn в INPUT пройдёт, но syn/asc уже OUTPUT даст только от указанного юзера!

В Hardened версиях Линукса обрезать сетевые возможности можно больше и на более низком уровне.

Ничего страшного, только OUTPUT вполне хватит! Да syn в INPUT пройдёт, но syn/asc уже OUTPUT даст только от указанного юзера!

сам-то понял, что написал? Вот откуда сервер ЛОРа знает, под каким uid запущен мой браузер?

В Hardened версиях Линукса обрезать сетевые возможности можно больше и на более низком уровне.

не сомневаюсь...

Ничего страшного, только OUTPUT вполне хватит! Да syn в INPUT пройдёт, но syn/asc уже OUTPUT даст только от указанного юзера!

сам-то понял, что написал? Вот откуда сервер ЛОРа знает, под каким uid запущен мой браузер?

iptables -t filter -P INPUT DROP
iptables -t filter -P FORWARD DROP
iptables -t filter -P OUTPUT DROP

iptables -t filter -A INPUT -m conntrack -p ALL -i lo --ctstate NEW,ESTABLISHED,RELATED -j ACCEPT

iptables -t filter -A INPUT -m conntrack -p ALL --ctstate ESTABLISHED,RELATED -j ACCEPT

iptables -t filter -A INPUT -m conntrack -p TCP -m tcp  --sport 1024:65530 -m multiport --dports http,https --ctstate NEW -j ACCEPT

iptables -t filter -A INPUT -p ALL -m limit --limit 5/m --limit-burst 3 -j LOG --log-prefix 'iptables INPUT ' --log-uid --log-ip-options --log-tcp-options #--log-level 4


iptables -t filter -A FORWARD -p ALL -m limit --limit 5/m --limit-burst 3 -j LOG --log-prefix 'iptables FORWARD ' --log-uid --log-ip-options --log-tcp-options #--log-level 4


iptables -t filter -A OUTPUT -m conntrack -p ALL -o lo --ctstate NEW,ESTABLISHED,RELATED -j ACCEPT

iptables -t filter -A OUTPUT -m conntrack -p TCP -m tcp -m owner --uid-owner apache  -m multiport --sports http,https --dport 1024:65530 --ctstate ESTABLISHED,RELATED -j ACCEPT

iptables -t filter -A OUTPUT -p ALL -m limit --limit 5/m --limit-burst 3 -j LOG --log-prefix 'iptables OUTPUT ' --log-uid --log-ip-options --log-tcp-options #--log-level 4

В данном сетевом экране только пользователь apache сможет пользоваться сетью, как сервер, и только на портах 80 и 443.

Все остальные пользователи заблокированы!

ВНИМАНИЕ!!! Следующие правило:

iptables -t filter -A OUTPUT -m conntrack -p TCP -m tcp --ctstate ESTABLISHED,RELATED -j ACCEPT

В данном сетевом экране только пользователь apache сможет пользоваться сетью, как сервер, и только на портах 80 и 443.

а... ну извини, я тебя неправильно понял. Да, конечно хватит.

Вот тут неудобно, не хочется давать левому приложению повышенные привилегии, даже только на биндинг порта с последующим понижением. Допустим, гипотетически, за код отвечаю не я, а за сервер — я. Вася, который отвечает за код, своих бекдоров напихал в свой код, и получил рута на моём сервере, сделал свои дела и тихо замёл следы бекдора.

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

Поконкретнее задачу можете поставить? Если не хочется давать Васиному приложению рута, то capabilities спасет отца русской демократии. Есть еще chroot и всякие подобные. Можно Васину поделку запустить от простого юзера на порту >1024 и проксировать к нему трафик с порта <1024.
Если вы боитесь что Вася получит привилегии рута, воспользовавшись уязвимостью в ядре - зачем вы ядро не залатали и Васе сказали его версию? Опять же тут вас спасет виртулизация.
Зачем нельзя Васин код почитать и за трафиком его приложения понаблюдать, коли паранойя одолела?

1. Некогда читать Васин код (а ещё Вася очень хитёр); 2. Если проксировать порт, — не хочу чтобы кроме Васи кто-то мог на него «сесть», выдав своё поделие, собирающие чужие пароли за Васин веб-сервер, за который отвечает Вася, просто он у Васи временно упал, а тут Петя решил сесть на порт и пособирать пароли;

Буду пожалуй копаться в capabilities.

А если задачу конкретнее — то просто хотел разграничивать доступ к портам по uid, всё. Но оказалось всё не так прозрачно, как полагал.

Есть такая страшная штука SeLinux, она по умолчанию RHEL'ах включена, хотя на VPS может и не быть.

Там можно для Васи создать такую политику, что он вобще ничего сделать не соможет, только бидиться на заданный порт :-) Только этот SeLinux очень долго изучать надо.

Как раз вот листаю маны и серфлю интернеты на эту тему.