существует ли относительно универсальный способ БЕЗОПАСНОГО межпроцессорного взаимодействия? то есть, мне необходимо наладить связь между двумя процессами таким образом, чтобы никакой любой третий процесс не смог получить доступ к передаваемым данным, при условии, что третий процесс вполне может быть запущен от пользователей как первого так и второго процессов. естественно, необходимо добиться максимальной скорости передачи данных, поэтому лучше защита на уровне системы, а не приложения, например шифрования. зы безопасность понимается не только в смысле чтения, но и невозможности недоверенным процессам писать в канал или предложенный вами вид ipc.
одним из логических решений была бы ПОЛНАЯ блокировка канала(при его использовании) на чтение одним процессом. возможно ли это с точки зрения безопасности?
Видимо всё-таки имелось ввиду межпроцессное взаимодействие, а не межпроцессорное. Способ для *nix существует, как буду дома - отпишусь.
>>да блин, через банальные пайпы с асимерт. шифр. =) я ищу способ, не затрагивающий шифрования. кстати, я подумал, и шифрование тоже внедрить сложно: даже используя алгоритм диффи-хеллмана для генерации ключа симм. шифра не смог найти способа нужной идентификации клиента-процесса.. чтобы шифрованное сообщение дошло в "те руки". забавно, но только сейчас вспомнил о unix-сокетах, попробую посмотреть
этот блок данных может быть перехвачен. а как id не подтвердит того, что данные пришли от кого нужно? отсюда и возвращать данные не пойми кому тоже не вариант
Вот, собственно я нащёл что искал. В книге Р.Стиверса "unix - Взаимодейсвие процессов" читай пункт 3.6 "Повторное использование идентификаторов". Надеюсь, поможет.
а при чем здесь это? у меня серверная часть имеет вполне открытое и постоянное имя ipc на файловой системе, поэтому злоумышленник может вполне добросовестно получать дескриптор ftok("server") меня интересует как перехватить посланное сообщение к серверной части первым, то есть самим сервером. очень красивая модель unix-sockets, но опять же - не могу найти способа идентификации программы-клиента. в принципе, используя концепцию сокетов это становится основной проблемой тк вклиниться в существующее соединение по-теории, как я понимаю невозможно. теоретически на пальцах это должно выглядить так: клиент, при подключении, отправляет свой pid, серверная программа проверяет его принадлежность к доверенным процессам и отправляет случайное число, которое должно каким-то образом отобразиться в адресном пространстве процесса или где-то еще, но чтобы это подтверждало, что это тот самый процесс, с отправленным pid, если это происходит, то очевидно что на подключении доверенный процесс. тут логично было бы использовать разделяемую память, однако в поставленной задаче процесс-злоумышленника может быть вполне запущен от пользователя процесса-клиента и если при создании shmget, например, указать бит w для владельца, без чего записывать в эту область у нас не будет прав, то все процессы этого пользователя смогут туда писать... мысль вторая, клиент, после получения случайного числа, ставит дополнительно бит записи в /proc/pid, создает там сокет /proc/pid/RANDOM и общение происходит уже по нему, снимает бит записи с каталога.. вполне возможно, что это решение.
хм, ну не знаю тогда как это сделать просто... Нужно пробывать. Я даже плохо представляю ещё как это можно перехватить. Откуда такая потребность в защите?
Почему бы сначала не посылать несколько пакетов пусть шифрованые, пусть даже мультикастом, в котором гденибудь будет id как машина получит id , она бы отвечал пакетом и начиналась передача