Комментарии 39
Хм, в последней версии macOS появился контроль не только с помощью unix прав (user-group-other),
но и можно разрешить или запретить определенным приложениям доступ к конкретным директориям. Это не решает проблему с хранением приватных данных, если разрешить доступ тольк самому signal ?
Вообще, проблема тут несколько шире.
Например, в Windows вредоносное приложение, запущенное от текущего пользователя, спокойно может прочесть все файлы других приложений из %AppData%. Допустим, историю и пароли вашего Firefox (если вы не включили шифрование паролей мастер-паролем, а по умолчанию это отключено, следовательно, для большинства пользователей этой фичи словно и не существует). И документы может прочесть, и файлы с рабочего стола.
Этого слона в комнате все "эксперты" старательно избегают замечать.
Этого слона в комнате все "эксперты" старательно избегают замечать.
Этого "слона" пытались вылечить в восьмой винде, но пользователи выбрали легаси, к сожалению. Нерешаемая задача.
Никто е хочет её решать, вот и нерешаемая. Работающие sandboxы на винду есть, а значит можно и реализовать и стандартизировать, не слишком перелопачивая систему. Но M$ вместо этого назвали Sandbox-ом виртуалку, чтобы окончательно запутать возможность нагуглить решение.
Проблема не в перелопачивании системы (в системе всё нужное для изоляции приложений afaik есть), а в перелопачивании юзерских привычек. Давно ли мы все под виндой под админским аккаунтом сидели?
Я бы сказал, что подавляющая часть пользователей так и сидит. Ограничены UAC (который с настройками по умолчанию, кстати, толком не защищает - для реальной защиты его надо выкрутить на максимум), но аккаунты-то админские. Очень мало кто после установки создаёт себе дополнительно пользовательский аккаунт и сидит в нем.
Ну и, конечно, есть доля тех, кому с UAC "ощущения не те" (к слову, Microsoft не тестирует Windows с отключенным UAC, так что эти товарищи добровольно вступают на территорию "тут живут драконы"), а также секта свидетелей встроенного Администратора (это вообще конченые люди, которые верят в какое-то особое могущество встроенной учётной записи, хотя отключение UAC уравнивает всех администраторов со встроенным).
хотя отключение UAC уравнивает всех администраторов со встроенным).
Не знаю, как оно сейчас, но в семерке точно у встроенного администратора было чуть больше прав, чем у любого другого. Я уже не помню, что именно было доступно только под этой административной учеткой, но помню, что что-то таки было. Другой вопрос, что подавляющему большинству пользователей (99.9...%, в том числе продвинутых) эти возможности совсем не нужны). Мне в свое время пришлось логиниться в эту учетку только пару-тройку раз в жизни, причем только один раз по делу (что-то нужно было подправить в системе, и только учетка администратора давала к этому доступ). Остальное - исключительно удовлетворение нездорового любопытства.
Я, наоборот, не помню, как оно там раньше, но сейчас единственное отличие - на встроенного администратора по умолчанию не распространяются ограничения UAC.
Соответственно можно уравнять всех админов, либо отключив UAC политикой, либо, наоборот, включив другую политику, которая применяет ограничения и ко встроенной учётке.
То есть, если хочется превратить встроенного админа в обычного, то в реестре делаем FilterAdministratorToken = 1, а если обычных во встроенного, то EnableLUA = 0.
Вот и вся "магия" встроенного админа...
Ну да. M$ со всем его ресурсом не смог переломить юзерские привычки и изобрёл костыль, чтобы хоть как-то ограничить запускаемый софт.
Проблема не в перелопачивании системы (в системе всё нужное для изоляции приложений afaik есть), а в перелопачивании юзерских привычек. Давно ли мы все под виндой под админским аккаунтом сидели?
В ваших словах мне чудится какая-то либеральная буква «Д» осуждение.
А знаете что? Среди моих коллег были люди, занимавшиеся… как бы это назвать повежливей… борьбой за расширение прав. Только не думайте, что для какой-нибудь чернухи — битлокеров, краж или шантажа. Нет, для вполне богоугодных дел, типа скликивания бюджетов, которые некоторые люди платили СЕОшникам (согласитесь, что такие люди должны быть наказаны). Так вот, глядя на их работу, я пришёл к выводу, что если вы запускаете приложение локально (хоть под какими дискриминированными учётками и ограничениями), про безопасность можете забыть, точка.
А теперь давайте посмотрим, что это несёт пользователю. Раньше надоевший майкрософтовский браузер можно было тупо стереть (если он вдруг вылезал в странных местах после смены умолчаний на что-то другое). Сейчас для этого нужно пройти квест: забрать владение, разобраться, какая учётка какие права должна иметь для его удаления, а какая — ни в коем случае не должна во избежания восстановления. Откроешь список процессов — мать Наделлы за ногу, каждый апдейт что-то круто меняет в системе, а тебе и знать не полагается, что там за что отвечает. Хотя больше половины там НАХРЕН НЕ НУЖНО. Закончится тем, что чатбот из Редмонда будет иметь админские права на этот компьютер, а юзер — никаких вообще (и это не шутка).
Что мы имеем в чистом итоге, если смотреть практически? У простого юзера безопасности ни хрена не прибавилось (trust me, я видел), а у инженеров сильно убавилось возможностей управлять.
Привычки-то, выходит, у нас поздоровей были, чем сейчас.
Хром запрашивает пароль (или аналог) от пользователя, под которым он запущен, при первой попытке заполнения пароля (потом запоминает на какое-то время). Что в этом нерешаемого?
Мы про доступ к файлам вне своей директории говорим ведь, да? В этом вопросе не бывает простого решения. Запрещаем доступ к файлам вне своей рабочей папки - и как мы фотошопом будем править фото из папки "фотографии"? Расширьте это поведение "хром который спрашивает пароль при первом автозаполнении в сеансе" и попробуйте решить вышеозвученную задачу применяя такой метод.
Нет? Причём здесь доступ вне директории? Хром просто не хранит пароли в незашифрованном виде на диске: https://superuser.com/questions/146742/how-does-google-chrome-store-passwords
Совет запускать приложения от root для решения проблемы это конечно огонь, сразу видно экспертов по безопасности.
Следующая новость будет о том, что ssh хранит ключи на файловой системе с правами 0600 и при копировании домашней директории у вас автоматически прорастают все доступы?
приложение Signal хранит ключи шифрования локальной истории чата в текстовом файле, доступном любому процессу в системе.
Никогда такого не было — и вот опять!
А какая альтернатива? Каждый запуск спрашивать пароль для расшифровки ключа?
На макоси, как описано в статье, хранить в keychain секрет, на котором шифровать директорию. При попытке прочитать из-под контекста чужого приложения (например, терминала), макось потребует подтвердить это паролем пользователя.
На десктопном Linux подобное можно проделать через gnome-keyring/kwallet, но по факту бесполезно т.к. они уязвимы к чтению по id секрета при запуске зловреда не из-под чего-то вроде flatpak.
Использовать штатные средства ОС для хранения секретов. На macOS - keychain. И нет - так просто прочитать и все выдрать оттуда - не получится (без авторизации пользователя, возможность попросить систему вот этому приложению на вот эту запись давать авторизацию автоматом - тоже есть).
Насколько помню, на винде тоже есть апи для хранения секретов.
Если у злоумышленника есть доступ к системе на уровне возможности чтения файлов, то так ли критично, что файлы лежат в открытом виде?
Иногда стоит читать статью.
Можно скопировать файлы на свой пк и читать чужие чаты ещё неизвестное количество времени. Без обнаружения.
Я не про это. У злоумышленника уже есть доступ к файловой системе - это более серьезная проблема, чем незашифрованный файл в системе.
Это разные проблемы. Вы можете поставить сигнал на условно рабочий компьютер, а там внезапно окажется, что молча кому-то позволено читать ваш сигнал.
Шифрование хранимых данных (encryption at rest) это типовое требование к приложениям, которые обрабатывают конфиденциальную информацию. Оно сильно уменьшает поверхность атаки. Атаковать могут не только используя доступ к файловой системе, но и, например, бекапы.
Но, это требование к данным на сервере. На локальном ПК никто не шифрует ключи и файлы.
Я помню даже вычитывал где то в рекомендациях от Майкрософт о допустимости хранения ключей в файловой системе. В этом нет ничего плохого.
На локальном ПК никто не шифрует ключи и файлы.
Возможно вы обобщаете какой-то свой опыт. Шифрование данных поддерживается в клиентском софте, где это важно. Даже ssh, к которому есть масса вопросов, при генерации ключа предлагает задать-таки пароль.
Другое дело, что здесь часто возникает компромисс между удобством и безопасностью, а пользователи часто выбирают первое. Но это не только техническая проблема.
Ну вот вполне реальный сценарий (ну кроме того что Signal я по другому пользуюсь - через Matrix bridge).
хост с Proxmox VE
бекап-сервер с Proxmox Backup Server
виртуалка с Windows 11 (бекапы снимаются каждые 2 часа). Bitlocker НЕ включен (в явном виде, manage bitlocker говорит что отключено, есть виртуальный TPM и windows говорит TPM is ready to use, насколько реально - не знаю, с точки зрения Windows - процессор у этой виртуалки где то десятилетней давности)
хосты PVE и PBS НЕ имеют TPM. диски не зашифрованы, вариант с загрузкой с флешки - вполне работает и восстановлением дисков - прямо предусмотрен(для данных отдельно разделы) (помогало не раз)
шифрование бекапов не включено (у PBS оно создает некоторые проблемы)
Если ключи доступа Signal не шифруются то можно доступ к ним получить если засунуть (или убедить пользователя запустить) троян в виртуалку или получить физический доступ к железу (автоматчиков там у дверей нет все же...). Если же они зашифрованы - то чуть меньше attack surface. Тем более что чего стоит еще уровень?
MS с bitlocker вот похоже умно сделали - с определенных версий насколько помню - если можно шифровать - диск шифруется, пусть даже ключ рядом лежит, если пользователю защиту надо получше - пусть вклю
Интресный бэкдор заложен разработчиками Сигнала: кто угодно может зайти под вашей учётной записью и вы даже не будете знать об этом. Приватность по американски. Еще кто-то верит в неё?
Ну а как правильно то? Интересуюсь, потому что начал свой типа-чат писать, причём не под Мак, а под Линь, Вынь, и Дрюнь. Шифровать историю легко, но чем? Паролем учётки в чате? Но по идее пользователь вводит её один раз и забывает (в хранилке или с концами). А ещё мне ведь нужно пароль пользователя для API как-то хранить, он нужен каждый раз.
Под линукс есть keyring/kwallet, но они есть далеко не везде, и по опыту общения народ их терпеть не может, отключает и сносит. Это скорее корпоративная замута. Под винду тоже есть что-то похожее, но ещё более неизвестное. Не удивлюсь, если в говносборках типа Tiny11 не работает. Так что это всё не варианты.
Либо я чего-то крупно не знаю, либо господа эксперты опять выкатывают претензию, что невозможное не сделано.
Можете просто ничем не шифровать. Даже в статье упоминается, что «эта практика является стандартной».
Вопрос же в том, что описывается ситуация для Mac. А там KeyChain есть в любом случае и большинство приложений его используют
Хотя бы - хешем системного логина пользователя + дата установки ОС. Уже лучше чем НЕ шифровать. Вообще на винде лучше DPAPI - https://learn.microsoft.com/en-us/windows/win32/api/dpapi/nf-dpapi-cryptprotectdata (для линукса универсального решения нет - это ж линус)
Настольная версия приложения Signal для Mac (и не только) хранит ключи шифрования на ПК в виде обычного текста