LINUX.ORG.RU
ФорумTalks

О принципе построения безопасности

 ,


0

1

Пришла мне в голову мысль, что большинство современных систем безопасности (компьютерой и не только) построены по запретительному принципу. Как, например, замок на дверях. В своем обычном состоянии дверь свободно открывается, но замок мешает ей открыться. Или система пароля в *nix. login, su, sudo используются именно в качестве замка, не допускающего свободный запуск оболочки. И взломав замок, можно получить доступ в квартиру, оболочку итд.

А вот с шифрованием наоборот. Там система шифрования - единственное, что может дать доступ к данным. Если приводить аналогию с реальным миром, это сродни карте, позволяющей пройти из точки A в точку B. И испортив карту, ты не только не попадешь быстрее, а возможно и вообще не сможешь попасть в нужное место (если не добудешь новую карту).

Потому, на мой взгляд, было бы куда безопаснее делать операционную систему (оболочку) именно по такому принципу. Чтобы без пароля она вообще была неработоспособной.

UPD: Как самый простой вариант реализации подобного принципа: хешируем пароль, полученный хэш используем для инициализации массива указателей на функции. И функции в теле программы-оболочки вызываем не напрямую, а через массив указателей на них. Соотв, при неправильной инициализации оболочка не будет работать. Из недостатков такого метода можно сразу указать необходимость подгона алгоритма под заданный хэш, усложенение кода функций (чтобы запуск неверной функции не приводил к переполнению стека, записи в невыделенную память итд), и многие другие.

★★★★★

Последнее исправление: cvs-255 (всего исправлений: 2)
Ответ на: комментарий от cvs-255

зависать не вариант - значит надо проверять - а это как я сказал выше ничем не отличается от проверки хеша пароля

quest ★★★★
()

Соотв, при неправильной инициализации оболочка не будет работать.

Слабым местом твой системы опять же остается человек. Тебе в попу вставят раскаленный взломщик 4096 битного ключа на 220 вольт, и все дела!

vada ★★★★★
()
Ответ на: комментарий от quest

Можно не зависать, а вываливаться по exception, если на вход функции некорректные параметры подаются

cvs-255 ★★★★★
() автор топика
Ответ на: комментарий от vasily_pupkin

Потому, на мой взгляд, было бы куда безопаснее делать операционную систему (оболочку) именно по такому принципу.

Почему?

потому-что он кушает вещества.

emulek
()
Ответ на: комментарий от Yustas

Евгений Касперский, вон, кричал что для его супер-защищённое ОС нужно спец-железо.

хотел бабла напилить.

fail.

emulek
()
Ответ на: комментарий от cvs-255

Ведь враг может с лайва загрузится, и/или отформатировать HDD, и поставить уютную восьмёрочку максимальную.

при удаленном логине нет

при чём тут удалённый логин? Иди проспись наконец!

А как проспишься, так и поймёшь, что намного более безопасно просто не пускать удалённо кого попало.

Так и делается. Например демон sshd выдаёт логин только тому, кто осилит доказать свои права. Т.е. sshd выдаёт случайное число потенциальному клиенту, и пускает его тогда, и только тогда, когда потенциальный клиент осилит его подписать известной (для sshd) подписью. (подразумевается, что авторизация по паролям запрещена в sshd_config).

А вот от локальной атаки нет защиты. Единственный выход — шифровать паролем все данные (sic! именно данные, а вовсе не код!)

Можно шифровать и ключом, но придётся таскать с собой этот ключ. (на флешке например). Это неудобно и небезопасно(т.к. враг может выкрасть ключ, причём достаточно просто его скопировать).

emulek
()
Ответ на: комментарий от cvs-255

Можно не зависать, а вываливаться по exception, если на вход функции некорректные параметры подаются

ну вот например gcc — почему я должен защищать его от врагов? Если враг украдёт мой девайс, то зачем защищать gcc? Ну защитим, враг тогда свой gcc воткнёт.

Как раз наоборот — надо ОТКРЫТЬ для врага НАШ gcc, который будет стучать «меня украли!». Причём для этого нужно:

1. разрешить врагу доступ к gcc

2. сделать так, что-бы gcc отлично работал, и стучал НЕЗАМЕТНО.

А вот что ты предлагаешь — упоротость ненужная.

emulek
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.