Ребрендинг KDE

>Я уже описал в чём был бы профит, если бы была написана system-wide library

Несколько строк накатать так сложно, да. :)

Шифрацию конфигов, с предоставлением возможности пользователю изменить ключ или алгоритм шифрования конкретного конфига.

Причём здесь шифрация, не совсем понятно (точнее совсем непонятно).

Кстати, выделение конфигов отдельный каталог даёт возможность примонтировать этот каталог в зашифрованный раздел. А с XDG_CACHE_HOME можно, к примеру, один кэш сделать общим для всех юзеров и для всех машин (если какая-то прога генерит кэш особенно долго и особо крупных размерах). Вот тебе и профиты. :)

А так пока получается что переменная HOME, определяемая в /etc/profile

ЩИТО???

> ЩИТО???

Виноват. Исправлюсь. Я имел ввиду, что переменная HOME определяется для любого пользователя в системе. Я НЕ правильно написал что она определяется в /etc/profile, она определяется в файле, содержащим данные об учётных записях пользователей. Как правило, /etc/passwd. Правда, полагаться на этот файл в своём коде я бы не стал, т.к. рекомендована к использованию функция getpwent(), описанная в <pwd.h>...

Ну, виноват... Виноват... :) Посыпаю пеплом голову... :)))

Причём здесь шифрация, не совсем понятно (точнее совсем непонятно).

Не понятно? А зря... На самом деле, это дало бы возможность хранить данные об учётной записи пользователя на некотором внешнем ресурсе более безопасно.

Т.е., например, есть пользователь, у него есть ноут. На ноуте установлена Linux-версия софта, который (например) логинится в БД. Учётка для БД хранится в зашифрованном конфиге вместе с настройками данной программы (адрес, порт, имя пользователя, пароль, дата последнего обращения к БД, ключ SSL, что угодно или что Вам ещё может прийти в голову). Доступ к этой информании заблокирован паролем, который назначается пользователем и хранится, например, в модуле TPM. Пример из этой области, но отвязанный от «конфигов» -> https://www.grounation.org/index.php?post/2008/07/04/8-how-to-use-a-tpm-with-... Как оно вообще работает.

Таким образом, даже в случае, если пользователь потеряет свой ноут, за разумное время ни кто не сможет воспользоваться этой учёткой к БД а пользователь может например, получить новый ключ SSL (да, получить, т.к. по выделяем пользователю ключу аутентифицировать «интереснее», чем по паролю или его хэшу в МД5).

Если пользователь не теряет свой ноут, а просто работает, то он может не волноваться насчёт аутентификации и авторизации. Ему достаточно _один_ раз аутентифицироваться в _своей_ системе, чтобы его программы самостоятельно, основываясь на данных из конфигов (кстати, расшифровываемых «налету») могли бы предоставлять ему доступ к информации прозрачным для него (пользователя) образом.

> Кстати, выделение конфигов отдельный каталог даёт возможность примонтировать этот каталог в зашифрованный раздел.

Можно. Но ненужно. Во-первых, не стоит складывать в одну кучу конфиги и пароли. Во-вторых, один пень надо мудровать с cryptoloop. В третьих, и сейчас ровным счётом ни что не мешает так делать.

А с XDG_CACHE_HOME можно, к примеру, один кэш сделать общим для всех юзеров и для всех машин (если какая-то прога генерит кэш особенно долго и особо крупных размерах). Вот тебе и профиты. :)

А вот так делать совсем-совсем не нужно. Уж поверьте... ;) У Брюса Шнаера найдите ответ АНБ на вопрос насколько криптостоек алгоритм АЕС... Мне Вы наслово не поверите, боюсь... :)))

>Я НЕ правильно написал что она определяется в /etc/profile, она определяется в файле, содержащим данные об учётных записях пользователей.

Кстати, переменные XDG_* действительно опеределяются в /etc/profile.d/xorg.sh. :) По крайней мере, в арче.

Учётка для БД хранится в зашифрованном конфиге вместе с настройками данной программы (адрес, порт, имя пользователя, пароль, дата последнего обращения к БД, ключ SSL, что угодно или что Вам ещё может прийти в голову).

Что-то подобное видел в gconf, но толком не разбирался. В любом случае там такое можно организовать через бэкенды.

> Что-то подобное видел в gconf, но толком не разбирался. В любом случае там такое можно организовать через бэкенды.

В данный момент — «да». Через бекэнды и только. Я же ратую (например) за то, чтобы с уровня бэкенда этот подход вышел бы на уровень «стандартной либы» (system-wide library).

Поясню откуда ветер дует. У меня служебная машинка — таблетка от Gateway. C-142XL. На ней есть и TPM и сканнер отпечатков пальцев. Я давным-давно уже не ввожу пароли «врукопашную». Только «пальчики»... :) Но незадача — сейчас «ввёл пароль», через cryptoloop монтируется «нужная» партиция и мы начинаем работать.

Кстати, изначально я извратился по поводу StegSF, стеганографическая ФС, которая ставится «поверх ext2» и хранит данные с большой избыточностью в «свободных блоках» HDD. Даже если мой винт попадёт в «кроватку» для посекторного чтения (а такие есть, можете мне поверить наслово), то там будет «мусор» как в случае, если там что-то было записано, а потом стёрто. Данные там ещё и шифруются. Проект довольно древний, но он работает. Сейчас пришлось с него отползать со слезами на глазах. Ну не кошерен ext2 уже... А с рейзером оно хреново дружит. Ссылка на то, откуда начинать копать -> http://forum.sources.ru/index.php?showtopic=44130 Я это лет пять назад ещё писал... :)))

Так вот. В случае, если либа, работающая с конфигами, в состоянии работать с TPM, получается что нам нет нужды в бэкендах (я _НЕ_ЗРЯ_ говорю про system-wide library). Нам нет нужды криптовать что-либо софтом. Сам по себе TPM основан на ATMega8, так что там шифратор есть полу-аппаратный. А он даёт изрядный прирост в скорости только за счёт того, что ключи хранятся в той же микрухе, алгоритм работает в той же микрухе... По сути дела блок данных извне пришёл, обработался, ушёл. Всё. Скорость довольно хорошая.

На уровне прикладного ПО это может выглядеть типа пакета Seahorse, но с «брелком» в железке. Через ту же либу программьё обращается к TPM, получает оттуда данные и дальше с ними работает. Изменить данные в памяти довольно сложно. Изменённые данные будут жить ровным счётом пока не будут считаны заново из TPM. Изменить данные в TPM? Ну, это так же гиморно. Нужно для этого все права иметь... Так что... почти безнадёга. И необходимость тратить ресурсы на cryptoloop отпадает. Совершенно. Экономия ресурсов налицо.

Короче, про TPM, если кому интересно. Даташиты - http://category.alldatasheet.com/index.jsp?semiconductor=TPM Они, от разных производителей, почти одинаково устроены... :) Базовые спецификации и т.д. и т.п. -> http://www.trustedcomputinggroup.org

Как с ними работать в Linux — http://sourceforge.net/projects/trousers/ релиз от IBM. http://trousers.sourceforge.net/tpm_keyring2/quickstart.html и http://trousers.sourceforge.net/tpm_keyring2/ecryptfs.html Последние две ссылки — немного не то, что я хочу. К сожалению.

Как-то так, в общем...

> В данный момент — «да». Через бекэнды и только. Я же ратую (например) за то, чтобы с уровня бэкенда этот подход вышел бы на уровень «стандартной либы» (system-wide library).

Единая библиотека для считывания и разбора конфигов? Зачем? Такую единую библиотеку уже пытались создать, ничего хорошего не вышло - так получился реестр винды.

Почему-то некоторые забывают, что кроме конфигов программы хранят много всего (кеш, логи, временные файлы, сертификаты, шаблоны, скины, плагины...) И разработать универсальную библиотеку, которая покроет все это... Такая библиотека уже есть - это функции read/write файловой системы. Для отдельных видов данных тоже давно есть библиотеки (libpng для картинок, libxml для древовидных текстовых данных и т.д.) Какая из задач не покрывается существующими библиотеками?

К тому же файловая система вполне позволяет добавить шифрование для любого нужного каталога или группы каталогов. И для программ это будет намного удобнее и прозрачнее, чем «system-wide library». Вот и получается, что лишний уровень абстракции над файловой системой будет... лишним.

На ней есть и TPM и сканнер отпечатков пальцев. Я давным-давно уже не ввожу пароли «врукопашную». Только «пальчики»... :) Но незадача — сейчас «ввёл пароль», через cryptoloop монтируется «нужная» партиция и мы начинаем работать.

Это - что, предложение заменить ввод паролей от шифрованных разделов отпечатками пальцев? Защита критические данные отпечатком не выглядит надежной. Если у меня украдут ноутбук, то мой пароль при этом не узнают. А если там авторизация по отпечатку... Да тех отпечатков по всему ноутбуку полно, считай - пароль написан на крышке.

Или в чем, собственно, была идея? Для чего еще использовать TPM? Для тивоизации, что-ли?

> изначально я извратился по поводу StegSF ... Сейчас пришлось с него отползать со слезами на глазах.

А MagikFS или Scramdisk не работают?

Еще есть hidden volume в truecrypt.

> Единая библиотека для считывания и разбора конфигов? Зачем? Такую единую библиотеку уже пытались создать, ничего хорошего не вышло - так получился реестр винды.

Ну, идея, положим, относительно хорошая. Особенно, если использовать не программные, а аппаратные средства обеспечения безопасности. А так... да... «реестр вянды»... И в этом плане что HOME, что XDG_CONFIG_HOME — что е?ать подтаскивать, что ё?аных оттаскивать... Без разницы.

Почему-то некоторые забывают, что кроме конфигов программы хранят много всего (кеш, логи, временные файлы, сертификаты, шаблоны, скины, плагины...) И разработать универсальную библиотеку, которая покроет все это... Такая библиотека уже есть - это функции read/write файловой системы. Для отдельных видов данных тоже давно есть библиотеки (libpng для картинок, libxml для древовидных текстовых данных и т.д.) Какая из задач не покрывается существующими библиотеками?

Изо всего перечисленного интересуют только «сертификаты» и данные для парольной аутентификации. Иногда сертификат получить гиморнее, чем его надлежащим образом сохранить. Касаемо всего остального — это не критичные данные. Их можно сносить-восстанавливать как и сколько угодно. В самом крайнем случае — затарить в тупую и не париться, чай не на дискеты бекапы сохраняем...

Касаемо функций доступа к данным, здесь важнее не «как», а «что» и «откуда» читать. Да. POSIX и функции ввода-вывода законодательно не отменяли. Однако, остаётся вопрос — мы читаем/пишем просто конфиг или мы читаем/пишем информацию, чувствительную к доступу? Значащую, иными словами...

К тому же файловая система вполне позволяет добавить шифрование для любого нужного каталога или группы каталогов. И для программ это будет намного удобнее и прозрачнее, чем «system-wide library». Вот и получается, что лишний уровень абстракции над файловой системой будет... лишним.

Файловая система в случае применения TPM здесь примерно как зайцу триппер. Всё просто. Она не используется для хранения значащей информации. С другой стороны, если мы переходим к использованию «железки», то огород городить из 10-20-30 дополнительных программ для доступа смысла нет. Гораздо проще использовать одну библиотеку.

Чуть не забыл...

Это - что, предложение заменить ввод паролей от шифрованных разделов отпечатками пальцев? Защита критические данные отпечатком не выглядит надежной.

А для «собаки» или «двух собак» и не предлагается. Для коммерсов — вполне-вполне. Они потенциально не в состоянии запомнить сложный пароль. К сожалению. Уж пусть лучше так, чем пароль типа «123», который крайне чувствительнен к угадыванию. Я бы с удовольствием кинул ссылку на книгу про «password guessing», только один хрен читать не будете (ссылки про TPM, судя по последнему предложению Вашего постинга, не осилили, а здесь посложнее малость). Расскажу вкратце своими словами — там чувак собрал порядка 4 млн. «плохих паролей». И с удивлением обнаружил, что все 4 «ляма» просто уложились в пятьсот паттернов. Уже легче, не так ли? :)

Тогда что эффективнее — заставлять юзера вводить пароль ХЗ какого вида, который он один пень не запомнит, а запишет где-то (как следствие — потеряет, разгласит или что ещё придумает), или заставить провети пальчиком по сканнеру? И в случае его аутентификации на внешних ресурсах кто даст гарантию что в «одноклассниках» он не использует того же пароля, что и для доступа к корпоративной VPN (он же _помнит_ пароль к VPN чётко)? Или, может, пусть железочка поможет ему в генерации пароля и его хранении? Чисто для «однотрахников» или «мыло.ру»? ;) А пароль для VPN пусть будет паролем к VPN.

Если у меня украдут ноутбук, то мой пароль при этом не узнают. А если там авторизация по отпечатку... Да тех отпечатков по всему ноутбуку полно, считай - пароль написан на крышке.

Бррр... Большая просьба — не надо больше смотреть/читать детективов. Это фигня. Полная. Спросите у любого судмедэксперта — какие отпечатки и какого качества он откатает со слегка шероховатой поверхности ноута? В случае с тонкой полоской сканера, Вам придётся не просто «подержать пальчик» на сканере, а провести по нему. Замечу из опыта. В результате в транспорте, дай Бог, раза с третьего будете давать хороший отпечаток. И то после «тренировки». Положение пальчика немного «не то», наклон «не тот», рука вспотела, дрогнула при вводе, всё — тренируемся ещё раз.

Или в чем, собственно, была идея? Для чего еще использовать TPM? Для тивоизации, что-ли?

Батенька, я не могу себе представить как (если подозревать что по ссылкам о TPM Вы прогулялись) в Вашу голову постучался такой «вывод». Вообще, откуда это? Для тивоизации довольно и более простых средств. Зачем для неё крипто-engine? Зачем хранить ключи? Нет. Я решительно отказываюсь это дальше обсуждать. По причине того, что при таком «выводе» обсуждать тут, мягко говоря, нехуя.

> А MagikFS или Scramdisk не работают?

Сожалею, но MagikFS это дальнейшее развитие -> http://www.cl.cam.ac.uk/~mgk25/ih99-stegfs.pdf всё той же StegFS. С точно такой же ориентацией на ext2fs в качестве «базовой». Т.е., по сути дела, те же яйца, вид в профиль.

Scramdisk — это вообще не в ту кадушку. Уж простите. Мне нужна максимальная _скрытность_, причём, осуществляемая без разного рода извратов на почве переразбиения дисков.

Еще есть hidden volume в truecrypt.

И это вослед за Scramdisk. Мне _НЕ_ нужны варианты, основанные на переразбиении диска, на создании доп. партиций. Они всегда «заметны» если читать диск.

В случае со стегфс, партиция создавалась, но через дополнительный софт, который можно было просто поставить/переименовать чтоб не палиться, или переустановить при необходимости. Никаких дополнительных партиций ни где не создавалось. Доступ к данным на таком «диске» — только через программьё на пользовательском уровне.