существует ли относительно универсальный способ БЕЗОПАСНОГО межпроцессорного взаимодействия? то есть, мне необходимо наладить связь между двумя процессами таким образом, чтобы никакой любой третий процесс не смог получить доступ к передаваемым данным, при условии, что третий процесс вполне может быть запущен от пользователей как первого так и второго процессов. естественно, необходимо добиться максимальной скорости передачи данных, поэтому лучше защита на уровне системы, а не приложения, например шифрования.зы безопасность понимается не только в смысле чтения, но и невозможности недоверенным процессам писать в канал или предложенный вами вид ipc.
pipe() + fork()?
>pipe() + fork()?процессы отнюдь не родственные:)
а в чем проблема шифрования? Необязательно ведь выбирать ресурсоемкий алгоритм. Возьмите что-нибудь простое с симметричным шифрованием и диффи-хеллман для обмена ключом.
>а в чем проблема шифрования? Необязательно ведь выбирать ресурсоемкий алгоритм. Возьмите что-нибудь
>простое с симметричным шифрованием и диффи-хеллман для обмена ключом.за диффи-хеллмана спасибо, интересно:) но мне бы очень не хотелось задействовать для действительно безопасной генерации длинную арифметику и вообще сам факт применения шифрования, возможно все же есть техническое решение уровня системы?
модуль ядра позволит и читать и писать всё что угодно в каком угодно месте любого процесса -- и вообще ИМХО какая-то очень странная задача
а вообще есть такие вещи как RSBAC и LIDS например -- в данном случае самое оно. (особенно RSBAC, selinux с его MAC не знаю умеет-ли)
>а вообще есть такие вещи как RSBAC и LIDS например -- в
>данном случае самое оно. (особенно RSBAC, selinux с его MAC не
>знаю умеет-ли)эхх, переносимость без дополнительных надстроек на ядром играет не малую роль, поэтому такой вариант тоже не подойдет.
>модуль ядра позволит и читать и писать всё что угодно в каком
>угодно месте любого процесса -- и вообще ИМХО какая-то очень странная
>задачано разве не логично иметь системную функцию типа flock, только действительно безопасную, где read, например, будет блокироваться без договоренности процессов. я вот и интересуюсь существует ли подобное решение
> существует ли подобное решениеfifo и unix socket не подходят? (кроме переносимости).
fifo имеет два конца, socket тоже можно сделать лимит соединения 1, третий никак не вклинится. Защищать файл сокета, fifo правами.
спасибо, очень красивая модель unix-sockets, но опять же - не могу найти способа идентификации программы-клиента. в принципе, используя концепцию сокетов это становится основной проблемой тк вклиниться в существующее соединение по-теории, как я понимаю невозможно.
теоретически на пальцах это должно выглядить так: клиент, при подключении, отправляет свой pid, серверная программа проверяет его принадлежность к доверенным процессам и отправляет случайное число, которое должно каким-то образом отобразиться в адресном пространстве процесса или где-то еще, но чтобы это подтверждало, что это тот самый процесс, с отправленным pid, если это происходит, то очевидно что на подключении доверенный процесс.
тут логично было бы использовать разделяемую память, однако в поставленной задаче процесс-злоумышленника может быть вполне запущен от пользователя процесса-клиента и если при создании shmget, например, указать бит w для владельца, без чего записывать в эту область у нас не будет прав, то все процессы этого пользователя смогут туда писать...
мысль вторая, клиент, после получения случайного числа, ставит дополнительно бит записи в /proc/pid, создает там сокет /proc/pid/RANDOM и общение происходит уже по нему, снимает бит записи с каталога.. вполне возможно, что это решение, однако смущает момент установки/снятия бита
> процесс-злоумышленника может быть вполне запущен от пользователя процесса-клиентаТогда все завивит от информированости злоумышленика о работе пограммы.
Сорцы будут закрыты? :(
>процесс-злоумышленника может быть вполне запущен от пользователя процесса-клиентаТогда он сможет использовать ptrace() и ему любые защиты будут "по барабану", так как он сможет читать готовые полученные (и даже расшифрованные) данные прямо из адресного пространства процесса-клиента.
>>процесс-злоумышленника может быть вполне запущен от пользователя процесса-клиента
>
>Тогда он сможет использовать ptrace() и ему любые защиты будут "по барабану",
>так как он сможет читать готовые полученные (и даже расшифрованные) данные
>прямо из адресного пространства процесса-клиента.крис касперски писал, что можно вызвать ptrace самому себе, тем самым блокировав все остальные подобные вызовы к этому процессу. отладчики уровня ядра естественно не в счет.
>>>процесс-злоумышленника может быть вполне запущен от пользователя процесса-клиента
>>
>>Тогда он сможет использовать ptrace() и ему любые защиты будут "по барабану",
>>так как он сможет читать готовые полученные (и даже расшифрованные) данные
>>прямо из адресного пространства процесса-клиента.
>
>крис касперски писал, что можно вызвать ptrace самому себе, тем самым блокировав
>все остальные подобные вызовы к этому процессу. отладчики уровня ядра естественно
>не в счет.Можно запустить процесс в "спящем" состоянии под ptrace(), а потом забить вызов ptrace() исследуемой программы NOP-ами и запустить процесс дальше.
а откуда права на запись в адресное пространство возьмутся?
>а откуда права на запись в адресное пространство возьмутся?Объясню подробнее:
1. запускаем вашу программу под ptrace() в спящем состоянии. Она не выполняется.
2. забиваем ей NOP-ами её вызов ptrace() при помощи ptrace(PTRACE_POKEDATA, ...):
man ptrace
PTRACE_POKETEXT, PTRACE_POKEDATA
Copies the word data to location addr in the child's memory. As above, the two requests are currently equivalent.3. запускаем программу дальше -- она ptrace() не вызывает
4. ставим ей breakpoint в нужных местах, и в те моменты считываем данные, полученные из другого процесса
дело в том, что запустить приложение в дочернем процессе конечно же будет можно, но в таком случае, в моей конкретной задаче (на уровне реализации) uid процесса будет НЕдоверительным, а это отследиться перед отправкой данных:) естественно я не говорю про отладку от привилегированного пользователя, например root'а, но от него и защищаться не стоит.
>дело в том, что запустить приложение в дочернем процессе конечно же будет
>можно, но в таком случае, в моей конкретной задаче (на уровне
>реализации) uid процесса будет НЕдоверительным, а это отследиться перед отправкой данных:)Вы просто в начале сказали, что атакующий может запускать программы от uid процесса-клиента.
>>дело в том, что запустить приложение в дочернем процессе конечно же будет
>>можно, но в таком случае, в моей конкретной задаче (на уровне
>>реализации) uid процесса будет НЕдоверительным, а это отследиться перед отправкой данных:)
>
>Вы просто в начале сказали, что атакующий может запускать программы от uid
>процесса-клиента.не совсем, демон запускается от рута, идет fork()+setuid и тут уже дочерний процесс-клиент в распоряжении злоумышленника. более того, из процесса нельзя будет вызвать другую программу, линк на исполняемый файл процесса проверяется сервером. мне кажется, что это не позволит отладить процесс.
>не совсем, демон запускается от рута, идет fork()+setuidЗачем тогда махинации с пересылкой pid? Всю "договоренность"(например генерацию подтверждающего ключа) сделайте до fork
>>не совсем, демон запускается от рута, идет fork()+setuid
>
>Зачем тогда махинации с пересылкой pid? Всю "договоренность"(например генерацию подтверждающего ключа) сделайте
>до forkпо pid я определяю доверенный это процесс или нет, и тем более управление начинается после fork()
Механизмы разграничения прав доступа в UNIX-системах основаны на идентификации пользователей. В описанном виде задача заключается в создании дополнительного механизма, ограничивающего взаимодействие между процессами одного пользователя. Такой механизм должен включать в себя некие средства классификации на уровне кому можно - кому нельзя, плюс механизм отказа во взаимодействии тем, кому нельзя. Стандартного, а тем более переносимого механизма такого вида попросту нет.По моим ощущениям, исходная задача некорректно сформулирована: в нее добавлены избыточные технические ограничения. Что мешает запускать "доверенные" процессы в едином контексте безопасности (организованного на базе механизма пользователей и групп), исключив тем самым все существенные угрозы по "вклиниванию" действий злоумышленников во взаимодействие???