История изменений
Исправление peregrine, (текущая версия) :
Почему же?
┌────────────────────────────────────┐
| Связка ключей хранит кроме ключа | Приложение при первом запуске
| электронную подпись бинарика или | (установке) сообщает свою подпись или
| скрипта, которая записала ключ или | требует себя подписать и запрашивает
| получила в явном виде от | доступ к секретному хранилищу
| пользователя право его читать. ╞═══════════════════════════════════════╗
└────────────────────────────────────┘ ⇓
┌────────────────────────────────────┐
Теперь приложение может сохранять | Модуль ядра на уровне LSM проводит |
секреты в хранилище, которое работает | проверку, что приложение, |
от специального пользователя secret | запросившее разрешение |
и чья папка не доступна на чтение | действительно имеет ту подпись или |
никому кроме root и secret | подписывает приложение |
╔═══════════════════════════════════════╡ |
⇓ └────────────────────────────────────┘
┌────────────────────────────────────┐
| Когда приложение запрашивает | Если подпись не та, то возврат ошибки и
| пароль из хранилища, то модуль | уведомление пользователя, что такой-то
| ядра проверяет подпись приложения | процесс с такого-то бинаря вредонос и
| и возвращает его связке ключей | пытался получить доступ к секретам
| | такого то приложения. В противном
| | случае возврат ключа.
| ╞═══════════════════════════════════════╗
└────────────────────────────────────┘ ⇓
┌────────────────────────────────────────────────────────────────────────────┐
| Злоумышленник может сохранять и читать только свои пароли и секреты, чужие |
| не может, может если заражена сама программа которая работает с ключами |
└────────────────────────────────────────────────────────────────────────────┘
Однако тут есть ряд оговорок и трудностей требующих большой работы над ядром.
-
Ядро должно иметь возможность надёжно отследить бинарь и процесс запущенной программы (как я понимаю сейчас это не так и в этом основная трудность).
-
dbus не безопасен (его можно читать левым программам так же как и ключи сейчас), как вариант сокеты или шифрование внутри dbus могли бы помочь.
-
Это не защищает от повышения прав до рута (но и не должно)
PS
А главная трудность в том, что тогда TPM не нужен, кроме как для DRM и очень специфичных бэкдоров и продавливать его необходимость будет труднее.
Исправление peregrine, :
Почему же?
┌────────────────────────────────────┐
| Связка ключей хранит кроме ключа | Приложение при первом запуске
| электронную подпись бинарика или | (установке) сообщает свою подпись или
| скрипта, которая записала ключ или | требует себя подписать и запрашивает
| получила в явном виде от | доступ к секретному хранилищу
| пользователя право его читать. ╞═══════════════════════════════════════╗
└────────────────────────────────────┘ ⇓
┌────────────────────────────────────┐
Теперь приложение может сохранять | Модуль ядра на уровне LSM проводит |
секреты в хранилище, которое работает | проверку, что приложение, |
от специального пользователя secret | запросившее разрешение |
и чья папка не доступна на чтение | действительно имеет ту подпись или |
никому кроме root и secret | подписывает приложение |
╔═══════════════════════════════════════╡ |
⇓ └────────────────────────────────────┘
┌────────────────────────────────────┐
| Когда приложение запрашивает | Если подпись не та, то возврат ошибки и
| пароль из хранилища, то модуль | уведомление пользователя, что такой-то
| ядра проверяет подпись приложения | процесс с такого-то бинаря вредонос и
| и возвращает его связке ключей | пытался получить доступ к секретам
| | такого то приложения. В противном
| | случае возврат ключа.
| ╞═══════════════════════════════════════╗
└────────────────────────────────────┘ ⇓
┌────────────────────────────────────────────────────────────────────────────┐
| Злоумышленник может сохранять и читать только свои пароли и секреты, чужие |
| не может, может если заражена сама программа которая работает с ключами |
└────────────────────────────────────────────────────────────────────────────┘
Однако тут есть ряд оговорок и трудностей требующих большой работы над ядром.
-
Ядро должно иметь возможность надёжно отследить бинарь и процесс запущенной программы (как я понимаю сейчас это не так и в этом основная трудность).
-
dbus не безопасен (его можно читать левым программам так же как и ключи сейчас), как вариант сокеты или шифрование внутри dbus могли бы помочь.
-
Это не защищает от повышения прав до рута (но и не должно)
PS
А главная трудность в том, что тогда TPM не нужен, кроме как для DRM и очень специфичных бэкдоров и продавливать его будет труднее.
Исправление peregrine, :
Почему же?
┌────────────────────────────────────┐
| Связка ключей хранит кроме ключа | Приложение при первом запуске
| электронную подпись бинарика или | (установке) сообщает свою подпись или
| скрипта, которая записала ключ или | требует себя подписать и запрашивает
| получила в явном виде от | доступ к секретному хранилищу
| пользователя право его читать. ╞═══════════════════════════════════════╗
└────────────────────────────────────┘ ⇓
┌────────────────────────────────────┐
Теперь приложение может сохранять | Модуль ядра на уровне LSM проводит |
секреты в хранилище, которое работает | проверку, что приложение, |
от специального пользователя secret | запросившее разрешение |
и чья папка не доступна на чтение | действительно имеет ту подпись или |
никому кроме root и secret | подписывает приложение |
╔═══════════════════════════════════════╡ |
⇓ └────────────────────────────────────┘
┌────────────────────────────────────┐
| Когда приложение запрашивает | Если подпись не та, то возврат ошибки и
| пароль из хранилища, то модуль | уведомление пользователя, что такой-то
| ядра проверяет подпись приложения | процесс с такого-то бинаря вредонос и
| и возвращает его связке ключей | пытался получить доступ к секретам
| | такого то приложения. В противном
| | случае возврат ключа.
| ╞═══════════════════════════════════════╗
└────────────────────────────────────┘ ⇓
┌────────────────────────────────────────────────────────────────────────────┐
| Злоумышленник может сохранять и читать только свои пароли и секреты, чужие |
| не может, может если заражена сама программа которая работает с ключами |
└────────────────────────────────────────────────────────────────────────────┘
Однако тут есть ряд оговорок и трудностей требующих большой работы над ядром.
-
Ядро должно иметь возможность надёжно отследить бинарь и процесс запущенной программы (как я понимаю сейчас это не так и в этом основная трудность).
-
dbus не безопасен (его можно читать левым программам так же как и ключи сейчас), как вариант сокеты или шифрование внутри dbus могли бы помочь.
-
Это не защищает от повышения прав до рута (но и не должно)
PS
А главная трудность в том, что тогда TPM не нужен, кроме как для DRM и продавливать его будет труднее.
Исправление peregrine, :
Почему же?
┌────────────────────────────────────┐
| Связка ключей хранит кроме ключа | Приложение при первом запуске
| электронную подпись бинарика или | (установке) сообщает свою подпись или
| скрипта, которая записала ключ или | требует себя подписать и запрашивает
| получила в явном виде от | доступ к секретному хранилищу
| пользователя право его читать. ╞═══════════════════════════════════════╗
└────────────────────────────────────┘ ⇓
┌────────────────────────────────────┐
Теперь приложение может сохранять | Модуль ядра на уровне LSM проводит |
секреты в хранилище, которое работает | проверку, что приложение, |
от специального пользователя secret | запросившее разрешение |
и чья папка не доступна на чтение | действительно имеет ту подпись или |
никому кроме root и secret | подписывает приложение |
╔═══════════════════════════════════════╡ |
⇓ └────────────────────────────────────┘
┌────────────────────────────────────┐
| Когда приложение запрашивает | Если подпись не та, то возврат ошибки и
| пароль из хранилища, то модуль | уведомление пользователя, что такой-то
| ядра проверяет подпись приложения | процесс с такого-то бинаря вредонос и
| и возвращает его связке ключей | пытался получить доступ к секретам
| | такого то приложения. В противном
| | случае возврат ключа.
| ╞═══════════════════════════════════════╗
└────────────────────────────────────┘ ⇓
┌────────────────────────────────────────────────────────────────────────────┐
| Злоумышленник может сохранять и читать только свои пароли и секреты, чужие |
| не может, может если заражена сама программа которая работает с ключами |
└────────────────────────────────────────────────────────────────────────────┘
Однако тут есть ряд оговорок и трудностей требующих большой работы над ядром.
-
Ядро должно иметь возможность надёжно отследить бинарь и процесс запущенной программы (как я понимаю сейчас это не так и в этом основная трудность).
-
dbus не безопасен (его можно читать левым программам так же как и ключи сейчас), как вариант сокеты или шифрование внутри dbus могли бы помочь.
-
Это не защищает от повышения прав до рута (но и не должно)
Исходная версия peregrine, :
Почему же?
┌────────────────────────────────────┐
| Связка ключей хранит кроме ключа | Приложение при первом запуске
| электронную подпись бинарика или | (установке) сообщает свою подпись или
| скрипта, которая записала ключ или | требует себя подписать и запрашивает
| получила в явном виде от | доступ к секретному хранилищу
| пользователя право его читать. ╞═══════════════════════════════════════╗
└────────────────────────────────────┘ ⇓
┌────────────────────────────────────┐
Теперь приложение может сохранять | Модуль ядра на уровне LSM проводит |
секреты в хранилище, которое работает | проверку, что приложение, |
от специального пользователя secret | запросившее разрешение |
и чья папка не доступна на чтение | действительно имеет ту подпись или |
никому кроме root и secret | подписывает приложение |
╔═══════════════════════════════════════╡ |
⇓ └────────────────────────────────────┘
┌────────────────────────────────────┐
| Когда приложение запрашивает | Если подпись не та, то возврат ошибки и
| пароль из хранилища, то модуль | уведомление пользователя, что такой-то
| ядра проверяет подпись приложения | процесс с такого-то бинаря вредонос и
| и возвращает его связке ключей | пытался получить доступ к секретам
| | такого то приложения. В противном
| | случае возврат ключа.
| ╞═══════════════════════════════════════╗
└────────────────────────────────────┘ ⇓
┌────────────────────────────────────────────────────────────────────────────┐
| Злоумышленник может сохранять и читать только свои пароли и секреты, чужие |
| не может |
└────────────────────────────────────────────────────────────────────────────┘
Однако тут есть ряд оговорок и трудностей требующих большой работы над ядром.
-
Ядро должно иметь возможность надёжно отследить бинарь и процесс запущенной программы (как я понимаю сейчас это не так и в этом основная трудность).
-
dbus не безопасен (его можно читать левым программам так же как и ключи сейчас), как вариант сокеты или шифрование внутри dbus могли бы помочь.
-
Это не защищает от повышения прав до рута (но и не должно)