Блог

Главная - Вопросы по программированию - Как безопасно обмениваться номерами между двумя процессами

Как безопасно обмениваться номерами между двумя процессами

#c #security #secure-coding #information-hiding

Вопрос:

Вот пример кода для myapp1 и myapp2 :

код myapp1:

 int main(int argc, char *argv[])
{    
    int secret = 123;
    char buffer[20];
    sprintf(buffer,"%d",secret);

    char *argv[] = { "/bin/myapp2", buffer, 0 };
    char *envp[] =
    {
        "HOME=/",
        "PATH=/bin:/usr/bin",
        0
    };

    int retval = execve(argv[0], amp;argv[0], envp); 
    printf("return value is: %dn", retval);
    
    return 0;
}

код myapp2:

 int main(int argc, char *argv[])
{
    int val = atoi(argv[1]);
    some_process(val);

    return val;
}

Как вы можете видеть, я вызываю приложение myapp2 , из myapp1 использования execve() . Я посылаю секретный номер myapp2 в его аргументах.
myapp2 выполняет некоторую обработку и возвращает тот же секретный номер вызывающей программе.
Теперь моя проблема в том, что я хочу, чтобы этот секретный номер был секретным от внешнего мира. секретный номер можно легко взломать с помощью этой ps команды.
Чего я хочу, так это того, чтобы я был уверен, что myapp2 тот, кто был вызван, является оригинальным. Если кто-то заменит его на a myappfake , который также возвращает тот же секретный номер, как я узнаю, что меня обманывают?

В принципе, я хочу убедиться , что ответ myapp2 , от которого я получаю ответ, является подлинным.

Комментарии:

1. Почему бы не использовать пару каналов для передачи данных между двумя процессами туда и обратно?

2. Кроме того, либо вы удалили его в своем примере кода, чтобы упростить его, либо вы неправильно понимаете, как exec* работает семейство функций. Прежде всего, вам нужен fork вызов, чтобы иметь возможность запускать первый процесс параллельно. И, во-вторых, даже если execve бы он был возвращен, он вернул бы индикатор успеха/неудачи самого execve вызова, а не то, что вернул другой запрограммированный.

3. Если у кого-то есть полный доступ к машине, вы никоим образом не можете гарантировать такую безопасность. Использование труб лучше, чем передача секретов в виде аргументов, но все равно это только безопасность через неизвестность .

4. Вы могли бы взглянуть на boost boost.org/doc/libs/1_54_0/doc/html/interprocess/… , тогда существуют также решения, зависящие от платформы. RPC-это вариант, но, возможно, излишний для одного номера.

5. @Someprogrammerdude: Общий пример кода предназначен только для упрощения кода. На самом деле myapp1-это модуль ядра Linux. И myap2 вызывается с помощью API call_usermodehelper (). Я думаю, что мы не можем использовать трубы в этом сценарии.

Ответ №1:

Я бы дал вам направление на RPC — удаленный вызов(ы) процедур.
Это старый протокол, но я использую некоторые современные ОС, такие как Linux или Windows.
Этот протокол можно использовать по сети. Таким образом, вы не ограничены местной станцией.
И поскольку Linux и Windows поддерживают локальные (бессерверные) среды, не составляет проблемы протестировать или расширить протокол (также он не ограничен количеством вызовов, которые вы можете совершать).
Вы можете зашифровать или де-зашифровать все данные с каждой стороны (точка приложения). RPC-это старый протокол. Итак, вы должны сами заниматься своими ценными бумагами. И вы можете кодировать свои приложения RPC на разных платформах, потому что протокол RPC не зависит ни от какой платформы (в родной форме). Но вы должны хранить две копии вызовов функций (сервер/клиент). Если вы умны, вы можете расширить свою функцию пакета RPC, расширяясь и не беспокоясь о протоколе. Это всегда одно и то же. Таким образом, вы очень гибки, если хотите расширить свое приложение.

Метки: