Новое сообщение в форум Философия программирования

Форум	Философия программирования
Тема	Как правильно задавать вопросы

Здравствуйте, ·, Вы писали:

·>Здравствуйте, FDSC, Вы писали:

FDS>>>>Для осуществления контроля. Грубо говоря, я запускаю какую-нибудь функцию компилятора и смотрю распечатку всех модулей, где такие функции разрешены (ввода-вывода).
FDS>>>>Все остальные модули компилятор сам проверяет, что в них ничего такого нет.
FDS>>·>В каком файле? В .exe? Тогда компилятор тут непричём. Ибо .exe после компиляции можно пропатчить, например.
FDS>>Причём тут exe?
·>Если тебя заботит безопасность, то ты должен как-то верифицировать, что запускаемое это ровно то, что было скомпилировано и проверено компилятором.

FDS>>Хотя я не очень понял, как там запрещать доступ к любым методам. Там файлы, сокеты есть. Ну я не особо разбирался.
·>Там как правило ограничения на уровне классов, а не методов.

FDS>>Но это, всё равно, во время выполнения делается. А не во время компиляции.
FDS>>Но, вообще говоря, интересно.
FDS>>Забавно, что это в Java нашлось :)
·>Ну как бы java изначально проектировали под applets - произвольный код, запускаемый в песочнице браузера, поэтому нужно явно контролировать разрешенные действия.

FDS>>>>Это нужно, чтобы случайно не допустить ошибку и проще было бы контролировать операции ввода-вывода.
FDS>>·>Такое решается управлением зависимостями. Т.е. "эти файлы завият от этих библиотек. Вот списочек библиотек". Тебе останется проверить, что среди этих библиотек нет таких, которые делают ввод-вывод.
FDS>>Ну кто этот списочек-то составит?
·>Программист. Когда пишет код, он должен точно знать что ему надо для выполнения данного функционала. Аудитор этот списочек будет проверять.

FDS>>Файлы не зависят от библиотек. Они зависят от других файлов.
·>В данном случае разница только терминологическая.

FDS>>·>Это происходит в runtime. Условно говоря, если Class1 (и любой код им используемый) пытается обратиться к java.io.File, то кастомизированный ClassLoader просто кинет ClassNotFound.
FDS>>Забавно.
·>Скриптовые движки тоже умеют. Там определяешь контекст и то что есть в контексте, то работает, остальное - недоступно.

FDS>>·>Самый простой подход - защитная копия. Ты делаешь копию этого массива и передаёшь в функцию вычисления хеша. Даже если она что-то там поменяет, то пофиг, а к оригинальному массиву у неё просто не будет доступа, т.к. нет его адреса.
FDS>>Тут смысл в том, что я не должен об этом думать. И тем более, копировать что-то в runtime.
FDS>>1. Это загрязняет код
FDS>>2. Это требует кодирования
·>Ты должен думать в любом случае чтобы решить, должна ли некая функция менять данные или нет. В зависимости от этого передавать туда соответсвующий тип.

FDS>>Как раз хотелось бы в статике проверять.
·>Это и делает система типов.

FDS>>·>Сделать RedSymbol...
FDS>>Опять же, сделать вручную. Тогда проще сразу написать компилятор языка, который будет делать это автоматически.
·>Система типов может только лишь проверить, что типы не нарушаются, иногда тип может быть выведен автоматически. Но решать что какая функция может, а что не может придётся программисту.

FDS>>>>Плюс, нужно, чтобы можно было с гарантией видеть все приведения типов, чтобы их затем отдельно просматривать.
FDS>>·>Не делать приведения типов. Делов-то.
FDS>>Если я не буду делать приведений типов, то я никогда не смогу записать красную строку в зелёную.
FDS>>А нужно смочь. И чтобы этих мест было как можно меньше.
·>Поэтому выделяют API, модули, библиотеки и т.п., чтобы уменьшить attack surface. Но это вопрос проектирования конкретного приложения, а не ЯП.

FDS>>>>Плюс, у меня не должно быть сборщика мусора. Я как раз хочу уйти от него.
FDS>>·>Это почему?
FDS>>Во-первых, мне придётся самому его писать, если я буду делать загрузку через UEFI
·>Можно взять какой-нибудь существующий и допилить.

FDS>>Во-вторых, если он уже будет под Windows/Linux, то он не будет обнулять память.
·>По большому счёту сборщик мусора единственное самое надёжное место для обнуления памяти. Ясное дело, что ценой будет падение производительности... поэтому так не делают, но думаю допилить сущетсвующий будет не сложно. Лучший компромисс это когда программист явно помечает секретные данные в коде чтобы они чистились явно. Если чистить всё и всегда - будет тормозить.

FDS>>А мне нужно гарантированно обнулять память. Чтобы в оперативной памяти после использования не оставалось никаких данных, которые уже не нужны.
FDS>>Сборщик мусора это делает только случайно. Без гарантии. Что, если он что-то не перезапишет?
·>А что если процесс записал в память секрет, и тут же крешнулся или был убит? Перезаписать будет банально некому. Так что гарантировать ты никак такое не сможешь.

Теги:

Введите теги разделенные пробелами. Обрамляйте в кавычки словосочетания с пробелами внутри, например: "Visual Studio" .NET

Имя, пароль: Загрузить Нравится наш сайт? Помогите его развитию!
Отключить смайлики Получать ответы по e-mail