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

Может изначально зашифровать этот канал двух килобайтным ключём?

а что мешает другому левому процессу взять этот же ключ и тоже зашифровать?

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

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

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

Генерация ключей на лету (тот же алго Диффи - Хеллмана)

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

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

Что никак не мешает заюзать свой ГПСЧ

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

кто сказал? man dup

Ух ты, работает. Спасибо.

незачто, см. ещё man pipe(2) и что-либо вроде http://tldp.org/LDP/lpg/node11.html

Гарантированно? Нет.

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

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

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

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

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

вариант рас:

в-нулевых, тебе надо снять 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} посмотришь, а что за бинарь тебе позвонил. если все чисто, то ура.

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

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

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

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

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

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

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

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

хотя я вру, бро.

через /proc/{pid}/mem достанут. а там как было решето так и осталось.

тут не помешает напомнить о vaxocentrism'е.

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

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

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

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

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

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

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

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

Есть named pipe

Я вот не уверен насчёт 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