Безопасность средств IPC sysv, posix

[ZaCo]

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

зы безопасность понимается не только в смысле чтения, но и невозможности недоверенным процессам писать в канал или предложенный вами вид ipc.

[ZaCo]

одним из логических решений была бы ПОЛНАЯ блокировка канала(при его использовании) на чтение одним процессом. возможно ли это с точки зрения безопасности?

[ShadOS]

существует ли относительно универсальный способ БЕЗОПАСНОГО межпроцессорного взаимодействия?
Видимо всё-таки имелось ввиду межпроцессное взаимодействие, а не межпроцессорное. Способ для *nix существует, как буду дома - отпишусь.

[ZaCo]

заранее спасибо

[nerezus]

да блин, через банальные пайпы с асимерт. шифр. =)

[ZaCo]

>>да блин, через банальные пайпы с асимерт. шифр. =)
я ищу способ, не затрагивающий шифрования. кстати, я подумал, и шифрование тоже внедрить сложно: даже используя алгоритм диффи-хеллмана для генерации ключа симм. шифра не смог найти способа нужной идентификации клиента-процесса.. чтобы шифрованное сообщение дошло в "те руки".
забавно, но только сейчас вспомнил о unix-сокетах, попробую посмотреть

[ShadOS]

Кстати, а почему бы прото к каждому блоку данных не добавлять некий Sequence ID и проверять его?

[ZaCo]

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

[ShadOS]

Вот, собственно я нащёл что искал. В книге Р.Стиверса "unix - Взаимодейсвие процессов" читай пункт 3.6 "Повторное использование идентификаторов".
Надеюсь, поможет.

[ZaCo]

а при чем здесь это? у меня серверная часть имеет вполне открытое и постоянное имя ipc на файловой системе, поэтому злоумышленник может вполне добросовестно получать дескриптор ftok("server") :) меня интересует как перехватить посланное сообщение к серверной части первым, то есть самим сервером.
очень красивая модель unix-sockets, но опять же - не могу найти способа идентификации программы-клиента. в принципе, используя концепцию сокетов это становится основной проблемой тк вклиниться в существующее соединение по-теории, как я понимаю невозможно.
теоретически на пальцах это должно выглядить так: клиент, при подключении, отправляет свой pid, серверная программа проверяет его принадлежность к доверенным процессам и отправляет случайное число, которое должно каким-то образом отобразиться в адресном пространстве процесса или где-то еще, но чтобы это подтверждало, что это тот самый процесс, с отправленным pid, если это происходит, то очевидно что на подключении доверенный процесс.
тут логично было бы использовать разделяемую память, однако в поставленной задаче процесс-злоумышленника может быть вполне запущен от пользователя процесса-клиента и если при создании shmget, например, указать бит w для владельца, без чего записывать в эту область у нас не будет прав, то все процессы этого пользователя смогут туда писать...
мысль вторая, клиент, после получения случайного числа, ставит дополнительно бит записи в /proc/pid, создает там сокет /proc/pid/RANDOM и общение происходит уже по нему, снимает бит записи с каталога.. вполне возможно, что это решение.

[ShadOS]

хм, ну не знаю тогда как это сделать просто... Нужно пробывать. Я даже плохо представляю ещё как это можно перехватить. Откуда такая потребность в защите?

[MicRO]

Почему бы сначала не посылать несколько пакетов пусть шифрованые, пусть даже мультикастом, в котором гденибудь будет id как машина получит id , она бы отвечал пакетом и начиналась передача