LINUX.ORG.RU

можно ли защитить межпроцессную коммуникацию от перехвата?


0

2

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

Рутовый процесс запускается процессом обычного юзера через su, sudo, kdesu, gksu или чем-то похожим, с вводом пароля

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


★★★★★

Ответ на: комментарий от Harald

Асимметричная криптография

Это если есть возможность отличить «правильный» юзерский процесс от подставного

Kuzz ★★★ ()
Ответ на: комментарий от Kuzz

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

Harald ★★★★★ ()
Ответ на: комментарий от Harald

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

Kuzz ★★★ ()
Ответ на: комментарий от Kuzz

для генерации ключей нужны случайные числа из /dev/random, чтение из этого файла перехватывается strace-ом

Harald ★★★★★ ()
Ответ на: комментарий от Kuzz

Диффи-Хеллман не защищает от man-in-the-middle, а он в этой схеме кажется возможен (хотя может и нет, надо подумать)

Harald ★★★★★ ()
Ответ на: комментарий от Kuzz

и откуда он рандом брать будет, так чтобы другой процесс не мог перехватить? :)

Harald ★★★★★ ()
Ответ на: комментарий от Harald

Диффи-Хеллман дает возможность сгенерить секретный ключ даже в случае прослушки канала. Но да, если третий процесс станет в «разрыв» пайпа и будет знать, что сейчас будет генерироваться ключ, и как он будет генерироваться, то сможет перехватить обмен.

и откуда он рандом брать будет, так чтобы другой процесс не мог перехватить? :)

Сам генерировать. На основе хорошего генератора псевдослучайных чисел и каких-то данных из системы (время часто берут для инициализации ГПСЧ, в микро/наносекундах или тики процессора)

Kuzz ★★★ ()

Рутовый процесс слушает UNIX сокет, в этот сокет другой процесс пишет код на скриптовом языке, код интерпретируется и исполняется от рута.

Это именно так, как не нужно делать

Совет: из рутового процесса можно сделать дочерний с пониженными привелегиями

derlafff ★★★★★ ()

Создать отдельного юзера и запускать в нем только один процесс.

Deleted ()

только один разрешенный процесс

кем и как разрешенный?
М.б. стоит под это дело создать псевдопользователя и программу с setuid?

ABW ★★★★★ ()

1) раздать соотв. права на unix-сокет

2) воспользоваться apparmor/selinux

3) ввести авторизацию клиентов

пароль можно перехватить при помощи strace

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

true_admin ★★★★★ ()

А почему, если один процесс запускает другой, то они обмениваются через UNIX-сокет, а не через pipe?

mky ★★★★★ ()
Ответ на: комментарий от mky

процесс запускается не напрямую, а через kdesu или аналогичные программы, они не перенаправляют вывод со своего stdin на вход запущенной программы

Harald ★★★★★ ()
Ответ на: комментарий от Harald

процесс запускается не напрямую, а через kdesu или аналогичные программы

Сделать так, чтобы через kdesu подавался сигнал на форк. Форкнутый процесс спокойно понижает привилегии.

x3al ★★★★★ ()
Ответ на: комментарий от mky

А почему, если один процесс запускает другой, то они обмениваются через UNIX-сокет, а не через pipe?

А разве пайпы - не дело шелла? Дескрипторы стандратных потоков никак нельзя пошарить вроде же.

melkor217 ★★★★★ ()

А не проще ли использовать разделяемую память?

melkor217 ★★★★★ ()
Ответ на: комментарий от beastie

Ну, в том что можно делать пайпы я не сомневался :)

Просто не знал, как заиметь десктиптор STDIN-OUT-ERR одного процесса в другом процессе.

melkor217 ★★★★★ ()

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

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

что можно сделать?

вариант рас:

в-нулевых, тебе надо снять CAP_SYS_PTRACE и CAP_SETPCAP со всех процессов одного пользователя (http://linux.die.net/man/7/capabilities : см. cap_set_proc) во-первых, unix socket поддерживает такую штуку как credentials-pid, uid, gid. при коннекте получишь pid, uid, gid позвонившего тебе процесса.

во-вторых, пойдешь в /proc/{pid} посмотришь, а что за бинарь тебе позвонил. если все чисто, то ура.

вариант два щас допишу

ckotinko ☆☆☆ ()
Ответ на: комментарий от ckotinko

к варианту рас: тебе надо чотко отрубить CAP_SYS_PTRACE и CAP_SETPCAP сразу после логона. то есть то, что выполнится после ввода пароля - все должно быть без этих абилок.

а тут зависит от обстоятельств. ну там гном у тебя, кеды, консоль голая или еще какая-нибудь няша.

ckotinko ☆☆☆ ()
Ответ на: комментарий от ckotinko

процесс от юзера А, который сможет читать-писать данные юзера Б, но юзер Б не сможет читать-писать данные юзера А

Тов. ckotinko! Речь в ТЗ шла про root'а.

drSchur ★★★ ()
Ответ на: комментарий от drSchur

пофиг на рута. рут уже горожен. речь про процесс «от пользователя». т.е. задача стоит - отгородить один процесс одного пользователя от остальных процессов(кроме рутовых)

ckotinko ☆☆☆ ()

Есть ли в принципе какой-либо способ сделать так, чтобы передавать данные рутовому процессу мог только один разрешенный процесс?

В принципе это невозможно </thread>

no-such-file ★★★★★ ()
Ответ на: комментарий от beastie

а я бы просто выставил euid+egid на один из двух рутовых процессов. афтару вообще может быть даже рут не нужен а нужен отдельный узер + capabilitiesами играться

ckotinko ☆☆☆ ()
Ответ на: комментарий от Harald

Да, про kdesu я не подумал, хотя пайпы это плохая идея, в них можно писать через /proc/PID/fd/

А ещё есть проблема трассировки/отладки, там ведь не просто можно прехватывать системные вызовы и менять память процесса.

Может вам поискать другое решение, не запускать процесс от обычного пользователя, а сразу от root. В чём задача?

mky ★★★★★ ()

Есть ли в принципе какой-либо способ сделать так, чтобы передавать данные рутовому процессу мог только один разрешенный процесс?

man unix на предмет SO_PASSCRED и SCM_CREDENTIALS. Правда, это linux-специфично. Если же

Рутовый процесс запускается процессом обычного юзера

и при этом «серверный» процесс порождается при запуске клиентского, то можно использовать pipe, который точно идёт от процесса к процессу.

no-dashi ★★★★★ ()
Ответ на: комментарий от no-dashi

Я вот не уверен насчёт pipe, вот у меня так:

while : ; do echo A ; sleep 2 ; done | sudo /usr/bin/tee /root-file > /tmp/tee-out &

Если при этом посмотреть pid пишущего процесса (bash):

mky      29515  0.0  0.3   5344  1868 pts/5    Ss   22:28   0:00          \_ -bash
mky      29670  0.0  0.1   5344   832 pts/5    S    22:35   0:00              \_ -bash
mky      29705  0.0  0.1   4036   520 pts/5    S    22:36   0:00              |   \_ sleep 2
root     29671  0.0  0.3   7940  1720 pts/5    S    22:35   0:00              \_ sudo /usr/bin/tee /root-file
root     29673  0.0  0.1   4040   576 pts/5    S    22:35   0:00              |   \_ /usr/bin/tee /root-file

и сделать от пользователя mky:

echo BB >> /proc/29670/fd/1
То вот этот «BB» попадёт в tee и будет записан в файл. А ТС'у именно от этого и защищается, чтобы обычный пользователь не мог передать информацию (команды) рутовому процессу.

mky ★★★★★ ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.