https://www.opennet.ru/openforum/vsluhforumID9/6863.html существует ли относительно универсальный способ БЕЗОПАСНОГО межпроцессорного взаимодействия? то есть, мне необходимо наладить связь между двумя процессами таким образом, чтобы никакой любой третий процесс не смог получить доступ к передаваемым данным, при условии, что третий процесс вполне может быть запущен от пользователей как первого так и второго процессов. естественно, необходимо добиться максимальной скорости передачи данных, поэтому лучше защита на уровне системы, а не приложения, например шифрования.<br><br>зы безопасность понимается не только в смысле чтения, но и невозможности недоверенным процессам писать в канал или предложенный вами вид ipc.<br> https://www.opennet.ru/openforum/vsluhforumID9/6863.html#20 Wed, 24 Oct 2007 12:36:13 GMT &gt;&gt;не совсем, демон запускается от рута, идет fork()+setuid<br>&gt;<br>&gt;Зачем тогда махинации с пересылкой pid? Всю "договоренность"(например генерацию подтверждающего ключа) сделайте <br>&gt;до fork <br><br>по pid я определяю доверенный это процесс или нет, и тем более управление начинается после fork()<br> https://www.opennet.ru/openforum/vsluhforumID9/6863.html#19 Wed, 24 Oct 2007 05:44:38 GMT Механизмы разграничения прав доступа в UNIX-системах основаны на идентификации пользователей. В описанном виде задача заключается в создании дополнительного механизма, ограничивающего взаимодействие между процессами одного пользователя. Такой механизм должен включать в себя некие средства классификации на уровне кому можно - кому нельзя, плюс механизм отказа во взаимодействии тем, кому нельзя. Стандартного, а тем более переносимого механизма такого вида попросту нет.<br><br>По моим ощущениям, исходная задача некорректно сформулирована: в нее добавлены избыточные технические ограничения. Что мешает запускать "доверенные" процессы в едином контексте безопасности (организованного на базе механизма пользователей и групп), исключив тем самым все существенные угрозы по "вклиниванию" действий злоумышленников во взаимодействие???<br> https://www.opennet.ru/openforum/vsluhforumID9/6863.html#18 Tue, 23 Oct 2007 20:29:34 GMT &gt;не совсем, демон запускается от рута, идет fork()+setuid<br><br>Зачем тогда махинации с пересылкой pid? Всю "договоренность"(например генерацию подтверждающего ключа) сделайте до fork<br> https://www.opennet.ru/openforum/vsluhforumID9/6863.html#17 Mon, 22 Oct 2007 06:21:42 GMT &gt;&gt;дело в том, что запустить приложение в дочернем процессе конечно же будет <br>&gt;&gt;можно, но в таком случае, в моей конкретной задаче (на уровне <br>&gt;&gt;реализации) uid процесса будет НЕдоверительным, а это отследиться перед отправкой данных:)<br>&gt;<br>&gt;Вы просто в начале сказали, что атакующий может запускать программы от uid <br>&gt;процесса-клиента. <br><br>не совсем, демон запускается от рута, идет fork()+setuid и тут уже дочерний процесс-клиент в распоряжении злоумышленника. более того, из процесса нельзя будет вызвать другую программу, линк на исполняемый файл процесса проверяется сервером. мне кажется, что это не позволит отладить процесс.<br> https://www.opennet.ru/openforum/vsluhforumID9/6863.html#16 Sun, 21 Oct 2007 23:29:01 GMT &gt;дело в том, что запустить приложение в дочернем процессе конечно же будет <br>&gt;можно, но в таком случае, в моей конкретной задаче (на уровне <br>&gt;реализации) uid процесса будет НЕдоверительным, а это отследиться перед отправкой данных:)<br><br>Вы просто в начале сказали, что атакующий может запускать программы от uid процесса-клиента.<br> https://www.opennet.ru/openforum/vsluhforumID9/6863.html#15 Sun, 21 Oct 2007 20:16:38 GMT дело в том, что запустить приложение в дочернем процессе конечно же будет можно, но в таком случае, в моей конкретной задаче (на уровне реализации) uid процесса будет НЕдоверительным, а это отследиться перед отправкой данных:) естественно я не говорю про отладку от привилегированного пользователя, например root'а, но от него и защищаться не стоит.<br> https://www.opennet.ru/openforum/vsluhforumID9/6863.html#14 Sun, 21 Oct 2007 20:03:48 GMT &gt;а откуда права на запись в адресное пространство возьмутся? <br><br>Объясню подробнее:<br>1. запускаем вашу программу под ptrace() в спящем состоянии. Она не выполняется.<br>2. забиваем ей NOP-ами её вызов ptrace() при помощи ptrace(PTRACE_POKEDATA, ...):<br>man ptrace<br>PTRACE_POKETEXT, PTRACE_POKEDATA<br> Copies the word data to location addr in the child's memory. As above, the two requests are currently equivalent.<br><br>3. запускаем программу дальше -- она ptrace() не вызывает<br>4. ставим ей breakpoint в нужных местах, и в те моменты считываем данные, полученные из другого процесса<br> https://www.opennet.ru/openforum/vsluhforumID9/6863.html#13 Sun, 21 Oct 2007 19:42:59 GMT а откуда права на запись в адресное пространство возьмутся?<br> https://www.opennet.ru/openforum/vsluhforumID9/6863.html#12 Sun, 21 Oct 2007 19:03:28 GMT &gt;&gt;&gt;процесс-злоумышленника может быть вполне запущен от пользователя процесса-клиента<br>&gt;&gt;<br>&gt;&gt;Тогда он сможет использовать ptrace() и ему любые защиты будут "по барабану", <br>&gt;&gt;так как он сможет читать готовые полученные (и даже расшифрованные) данные <br>&gt;&gt;прямо из адресного пространства процесса-клиента. <br>&gt;<br>&gt;крис касперски писал, что можно вызвать ptrace самому себе, тем самым блокировав <br>&gt;все остальные подобные вызовы к этому процессу. отладчики уровня ядра естественно <br>&gt;не в счет. <br><br>Можно запустить процесс в "спящем" состоянии под ptrace(), а потом забить вызов ptrace() исследуемой программы NOP-ами и запустить процесс дальше.<br>