[devel] Q: capset after pthread_create (droproot patch for 3proxy)

[devel] Q: capset after pthread_create (droproot patch for 3proxy)

[Afanasov Dmitry]

[-- Attachment #1: Type: text/plain, Size: 272 bytes --]

как я понимаю, capset после pthread_create проставит capabilities только
для текущего треда, так?

вопрос: как постфактум проставить для всех порожденных тредов?

если никак, то придется drop_root вписывать в пяток лишних файлов.
-- 
С уважением
Афанасов Дмитрий

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [devel] Q: capset after pthread_create (droproot patch for 3proxy)

[Sergey Vlasov]

[-- Attachment #1: Type: text/plain, Size: 1693 bytes --]

On Mon, Jun 08, 2009 at 06:22:37PM +0400, Afanasov Dmitry wrote:
> как я понимаю, capset после pthread_create проставит capabilities только
> для текущего треда, так?

Да, именно так.  Упоминающийся в man capset параметр pid использовать
нельзя - в свежих версиях ядер он заблокирован окончательно;
допускается изменение только собственных параметров.

> вопрос: как постфактум проставить для всех порожденных тредов?

Только каким-то образом обеспечить вызов capset() во всех потоках, для
которых это необходимо (впрочем, при выполнении clone() при вызовах
pthread_create() результат capset() будет наследоваться; это не
работало в древней реализации Linuxthreads, где вызовы clone()
выполнялись в контексте отдельного потока "thread manager").

> если никак, то придется drop_root вписывать в пяток лишних файлов.

При вписывании следует учитывать, что функции set*id(), реализованные
в glibc, действуют на весь процесс (несмотря на то, что используемые
ими системные вызовы также меняют состояние только текущего потока).
Внутри glibc это реализовано передачей всем потокам зарезервированного
для этой цели сигнала, в обработчике которого выполняется запрошенный
системный вызов; функция __nptl_setxid() после рассылки сигналов всем
прочим потокам ожидает завершения их обработки, после чего выполняет
системный вызов set*id() для собственного потока.  Поэтому при наличии
в процедуре сброса привилегий вызовов set*id() следует аккуратно
синхронизировать инициализацию (иначе можно получить либо ложную
ошибку при повторном вызове set*id(), либо невозможность выполнения
других необходимых операций из-за слишком раннего выполнения set*id()
в другом потоке).

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: [devel] Q: capset after pthread_create (droproot patch for 3proxy)

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 718 bytes --]

On Mon, Jun 08, 2009 at 06:22:37PM +0400, Afanasov Dmitry wrote:
> как я понимаю, capset после pthread_create проставит capabilities только
> для текущего треда, так?

Да.

> вопрос: как постфактум проставить для всех порожденных тредов?
> 
> если никак, то придется drop_root вписывать в пяток лишних файлов.

Про технический аспект Сергей уже написал.  Что касается безопасности, то
лучше выполнить drop root до порождения тредов.  Поскольку потоки обладают
возможностью существенно влиять на поведение других родственных потоков,
может сложиться ситуация, когда, например, один поток ещё выполняется с
правами root, а другой -- уже непривилегированный и обрабатывает запросы
клиентов.


-- 
ldv

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: [devel] Q: capset after pthread_create (droproot patch for 3proxy)

[Afanasov Dmitry]

[-- Attachment #1: Type: text/plain, Size: 1837 bytes --]

On Mon, Jun 08, 2009 at 08:25:57PM +0400, Sergey Vlasov wrote:
> On Mon, Jun 08, 2009 at 06:22:37PM +0400, Afanasov Dmitry wrote:
> > вопрос: как постфактум проставить для всех порожденных тредов?
> 
> Только каким-то образом обеспечить вызов capset() во всех потоках, для
> которых это необходимо (впрочем, при выполнении clone() при вызовах
> pthread_create() результат capset() будет наследоваться).
> 
> > если никак, то придется drop_root вписывать в пяток лишних файлов.
> 
> При вписывании следует учитывать, что функции set*id(), реализованные
> в glibc, действуют на весь процесс.
[...]

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

On Mon, Jun 08, 2009 at 11:52:08PM +0400, Dmitry V. Levin wrote:
> On Mon, Jun 08, 2009 at 06:22:37PM +0400, Afanasov Dmitry wrote:
> > вопрос: как постфактум проставить для всех порожденных тредов?
> > если никак, то придется drop_root вписывать в пяток лишних файлов.
> 
> Про технический аспект Сергей уже написал.  Что касается безопасности, то
> лучше выполнить drop root до порождения тредов.
именно этот вариант и придется использовать.

сначала не хотелось, так как "drop_root() перед pthread_create()" означает
"setuid() до readconfig()". а так как конфиг "интерпретируемый", команды
выполняются сразу. в том числе команды setuid и pthread_create(subsystem).
а значит придется выкинуть из 3proxy.conf команды setuid, setgid, chrootи
и реализовать как параметры командной строки полностью, а не как
дополненение.

> может сложиться ситуация, когда, например, один поток ещё выполняется с
> правами root, а другой -- уже непривилегированный и обрабатывает запросы
> клиентов.
в данный момент именно так и получилось, почему и возник мой вопрос. буду
переделывать.

-- 
С уважением
Афанасов Дмитрий

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]