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

Может быть лучше сразу сдаться?
Отсидеть свое и начать новую жизнь.

по-моему, вы все-таки смешиваете понятия plausible deniability и стеганографию.

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

Это будет стоить не малых денег - обращаться в фирму.
И что фирма может?
Она может только если спец модуль к ядру написать, но это будет стоить очень прилично.
Лучшая секретность - та, секъюрность которой все могут проверить. Оупенсорс на этом стоит. Поэтому и я советуюсь с народом.

Что касается фирм - у меня 2-е из 3-х знакомых, существенно лучше меня разбирающихся в юниксе, работают в сфере компьютерной безопасности.
Ни один из них толком сказать ничего не смог, но вклад в дело они внесли. Я скомпоновал их решения в единое целое, и получил нечто уже более приемлемое. Один из них предложил использовать неразбитое место на диске как криптофс... Это не так плохо, но всё же подозрительно, особенно когда люди с большим опытом будут искать где же там запрятано несколько гигов на диске. Другой человек по сути посоветовал ровно тот же неразбитый раздел, но на флэшке - использовать как криптофс. Это тоже плохо, так как всего лишь переносит проблему с диска на флэшку. Тем более, что у меня нет сейчас флэшки на несколько гигов.
Есть у нас такая контора в стране, много, наверное, о себе мнящая -
называется demos.ru. Я попросил человека, там работающего, узнать, что думают секъюрити-специалисты по этому поводу. Оказалось, что они ничего не думают. Видать, задачи такого рода обычно перед людьми не ставились, поэтому они в этом смысле столь же бессильны как и обычные юзеры. Всё что они могут - это написать соответствующий софт, который будет делать именно то, что мне нужно. Но за деньги, и не малые :)

Если все так будут думать - то шифрование вообще не нужно.

Да нет, вроде бы не путаю.
Как я понимаю, "plausible deniability" - это на человеческом уровне правдоподобность того, что ничего такого нет. А стеганография - это математическое выражение данного принципа :) Например, если я надёжно застенографирую свою приватный ключ в кучу видеофайлов - то математически, то есть, в данном случае, стеганографически, доказать сложно будет, что я что-то туда записал (если использовать самые хорошие алгоритмы), но с человечкской "plausible deniability" точки зрения наоборот всё уже скопрометировано: использую стегософт - значит не зря. Всё. Я не правильно понимаю?

Если напишешь свои размышления - буду очень благодарен :).
Очень хочу услышать чужое критическое мнение и подход :).

За несколько недель размышлений над этой задачей и консультаций с разного рода народом я уже пришёл к ряду выводов. На данный момент известно что
1) То, что я хочу можно сделать в линуксе с ядром 2.2 (и только им). При этом максимум, что прийдётся научиться делать самому - это восстанавливать стёртые файлы. Вряд ли получится скрыть больше 2-х гигабайт при этом, и при этом это будет очень ненадёжная система в силу ненадёжности определённого софта - его не поддерживали уже долгое время.
2) Это можно сделать, скорей всего, в любой юникс-системе если руками отлючить некие ограничения в исходнике ядра (это более глубокая вещь чем компановка опций конфигурационного файла ядра - прийдётся поковыряться в исходниках).
3) Есть как всегда параллельная стратегия: можно наоборот заботиться не о надёжной правдоподобности отсутствия информации, а о том, что она будет в критический момент безвозвратно уничтожена. Такие системы и диски уже существуют, это стандартные решения на основе аппаратного шифрования. Действия сводятся к тому, что надо будет вовремя сломать ключ-карточку, дающую возможность смонтировать диск.
Но это тот случай, когда я заведомо признаю себя виновным, получается.

Возможно, есть вероятность, что то, что я хочу, уже существует, или это некая стандартная компановка обычных, уже давно используемых методов. Только грамотные осведомлённые специалисты могут сказать - существуют ли сейчас такие решения на основе юникса - или нет. Их существование ничему бы не противоречило. Более того, я могу сейчас спокойно представить как работала бы такая система, написанная "с нуля", с поддержкой таковой возможности: система должна обладать по умолчанию, в базовой поставке, спецвозможностями ядра: неким интерфейсом, который позволяет сразу после загрузки системы самому по желанию указать, где находится место на диске, куда писать не надо, так как там лежит специнфа - например привязать место на диске к конкретной пассфразе (установить соответствие). Далее, в ядре есть поддержка специального интерфейса к файловой системе: указав некую пассфразу, ядро "рапознаёт некие места на диске, и начинает их считать файлом, инфа о котором хранится только в оперативной памяти". Далее маунтим этот файл как криптоФС и всё. Может, где-то нечто похоже уже сделали? Кто-нибудь знает?

По идее, было бы хорошо обратиться с такими вопросами к Торвальдсу или Theo De Raadt'у, с английским у меня нормально, но я мало уверен что они ответят.

Я может чайник, но что мешает проанализировать весь жесткий диск, каждый его сектор и обнаружить с какого то места подозрительные байты? Да и следы будут в /tmp, в swap-e, в /etc/fstab возможно ... та же .bash_history, ваш скрипт для монтирования этой фс и размонтирования ... если только ручками каждый раз не набирать, а историю стирать ...

Да и при наличии каких то косвенных улик вам очень светит ректотермальный криптоанализ :) Лучше подумать над тем сколько лет ... и 1000$ и купить специальный контейнер с батарейками для отдельного жесткого диска (поищите - найдете в средствах мгновенного уничтожения информации), только если вы не вставите таблетку/карточку или будет плохой контакт/фон - можете мигом все потерять :)

Да не, ну что ж вы так.... совсем примитивно..
Насчёт анализирования каждого сектора - не знаю.
Хоум у меня весь на криптофс - поэтому всякие там хистори и прочая автоматитчески защищены, нет проблем.
В /tmp практически никогда у меня ничего такого не пишется.
Остался /var . Ну, там надо разбираться с ведением логов и что-то придумывать, но это уже мелочи.
А в fstab по умолчанию никто и не ставит автомаунты при загрузке в таких ситуациях :)
Самое сложное - это /var, но и там, думаю, что-то можно придумать.


Я сейчас уже понял как всё сделать более-менее конвенционально, ровно то что хотел... Но оказалось, что хотел я мало. Народ говорит, что удалённые файлы в ufs легко можно восстановить, причём восстановить всю инфу о файле кроме его имени - если это так, то обесценивается вся идея об удалении :(
Надо думать.

Не знаю как в BSD, но в линуксе можно включать криптографию свопа на лету, так что ничего тоже можно не отражатьв конфигах.
Не в этом проблема

Да, есть такие идеи, но они не лучше, чем надёжно прятать инфу на своём диске.

Я уже написал о пертурбациях с карточками для распознавания файловых систем.

Но найти такой удалённый диск - очень просто :) современными средствами :) Даже в унитазе, говорят, находили :) Так что... это мы уже проходили.

Просто случай со своевременным физическим уничтожением карточки может служить в некоторых случаях окончательным доводом, что я, например, виноват. Так они б взяли диск, проверили, не нашли ничего, засомневались... А тут, со сломом карточки, уже всё ясно. Если сочтут существующие данные достаточными, то и всё на том. Поэтому надо думать заранее.

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

К счастью, и эта проблема решена.
Уже известно как можно сделать так, что никто не заметит подмены ядра. Это сделать просто. Но для этого надо написать спецмодуль, что не так просто. Я не программист :)

В какой-то мере, да, конечно.. Но это опять же зависит от провессионализма и настойчивости исчущих.. ;-)) В самом деле, не мы же тут одни такие умные.. И наличие нестандартного модуля и подмену ядер и модификации всё можно отследить, если кто-либо начнёт копать в этом направлении.. Необычные вещи всегда привлекают внимание.. А вообще, идея с ядрами и модулями на мой взгляд наиболее всего подходит.

Просветите непосвяшённого:
Сколько не встречался в реальной жизни - везде писали, что если не вопрос жизни и смерти, то даже не пытайтесь восстанавливать стёртые файлы в UFS. Это правда? Интересна степень трудозатратности для спецслужб по восстановлению удалённых файлов в UFS.

Не забудьте про locate :) Да много всего вылезет и будет указывать ... уж лучше ту железку купить.

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

> Интересна степень трудозатратности для спецслужб по восстановлению удалённых файлов в UFS.

на мой взгляд, это не слишком трудозатратно.

Точно, тут уже заметили по поводу трудозатрат.. А вообще, собственно, почему именно UFS? Если уж начинать модификации, то и FS можно выбрать и соответствующим образом модифицировать, и из самых безобидных модулей изьять содержимое, подменить своим.. чтоб, по возможности, от оригинальных не отличались.. ну и ещё ряд нужных действий в том же ракурсе предпринять..

Если сделать reiserfs в файле на reiserfs, то восстановление будет очень сложным ;-)

консультации отдела "R" у пециалистов с LOR

НЕСПЕЦИАЛИСТ!
концепция(не проверенная)
1)UPS 2шт + кнопка отключения питания матери
на стуле,клаве, и на движение мышки по плоскости
2)4Gb RAM
3)bootloader grub (в шелле набрать опции отличные от menu.lst)
4)initrd с флопа (после загрузки уничтожить физически)
5)ramdisk 2Gb /home (ручками, может быть с шифрованием)
6)ramdisk 1.5Gb /tmp+/var
и не выключать

передо мной стоит точно такая же задача

но я отношусь к ней менее параноидально

у меня шифр. контенер по методологии LUKS и парольная фраза более 20 символов разного регистра с цифрами и доп. символами

была идея следующего харрактера:

генерим из /dev/urandon сколько-нибудь байт

далее с помощью того же gnupg шифруем это и пишем нуу к примеру на флешку ,далее мутим скрипт который будет монтировать флешку ,спрашивать парольную фразу для тех сгенерированных символов символов в файле на флешке и подставлять то что расшифровалось в качестве ключа контейнера LUKS

но это я даж не знаю слишком ,господа как вы думаете каково время криптоанализа контейнера зашифрованного алгоритмом AES-256 с парольной фразой ну скажем ровно 20 символов, а так же есть ли вероятность то называется лазеек как в этих алгоритмах шифрования так и в ПО реализующие их

Вот смотрите, как я понимаю ситуацию.

Ваш контрагент - либо правительство, либо организации, обладающие значительными финансовыми и людскими ресурами. Контрагент весьма заинтересован в получении вашей информации, атака направлена именно на нарушение конфиденциальности. Для простоты предположим, что вы - оппозиционная партия при тоталитарном режиме. :)

Понятно, что если вы хотите что-то противопоставить такому контрагенту, ваши финансовые вливания тоже должны быть достаточно велики. Вы же говорите, что для вас это малоприменимо. Т.о. адекватной защиты вы организховать все равно не сможете, все, что написано ниже - только обозначения подходов.

Самый простой вариант, который мне видится - не хранить документы локально, а держать их на хостинге за рубежом, разумеется в той стране, которая при случае не будет сотрудничать с вашим контрагентом. Затем использовать AFS или sshfs и шифровать данные на другой стороне.

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

При правильной организации стеганографического контейнера, контрагент не сможет доказать существование других данных.

Ну, для паранои, можно какие-то части такой системы, программу шифрования, ключевой файл, или метаинформацию, держать на съемном носителе, который можно быстро уничтожить. Или, использовать смарт-карту, обладающую функционалом гарантированного удаления защищенной области.

> Информация о том, что таковые инструменты используются в системе послужат только дополнительным доводом в пользу аргумента: "шифрует, значит - не зря...".

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

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

Еще простой вариант - взять съемный носитель, USB диск, на 40 GB, скажем. Отрезать первые 20 и сделать там обычную FS. Сложить туда всякую ерунду. Остальные 20 сделать томом TrueCrypt. Поскольку у TrueCrypt нет сигнатур, обозначающих его применение, контрагент не сможет доказать использование средств шифрования. Выглядеть это будет просто, как неразмеченный кусок диска с мусором. Так это и можно будет объяснить - хотел туда linux поставить загрузочный, но не успел. Опять же, это не будет защитой от контрагента, не действующего в правовом, так сказать, поле. ;)

Hope, this helps.

> далее с помощью того же gnupg шифруем это и пишем нуу к примеру на флешку ,далее мутим скрипт который будет монтировать флешку ,спрашивать парольную фразу для тех сгенерированных символов символов в файле на флешке и подставлять то что расшифровалось в качестве ключа контейнера LUKS

это, как правило, лишнее. большинство систем и так это делают.

> как вы думаете каково время криптоанализа контейнера зашифрованного алгоритмом AES-256 с парольной фразой ну скажем ровно 20 символов

слишком мало данных.

> а так же есть ли вероятность то называется лазеек как в этих алгоритмах шифрования так и в ПО реализующие их

есть.

2 ivlad

>> а так же есть ли вероятность то называется лазеек как в этих алгоритмах шифрования так и в ПО реализующие их

> есть.

конкретно конечно же ничего неизвестно ?

на ваш взгляд каким симетричным шифром и какой opensource технологией пользоваться ?

я пользуюсь AES-256, cryptsetup-LUKS

> конкретно конечно же ничего неизвестно ?

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

Я кое-какие ссылки на днях в блоге у сбя кидал: http://ivlad.livejournal.com/148785.html

Что касается предумышленных лазеек в дизайне Rijndael/AES, то в этом я сильно сомневаюсь. Конечно, возможны подвижки в этой области математики (кстати, Шнаер любит критиковать Rijndael за недостаточную глубину разработки соответствующего математического аппарата, хотя, возможно, он кривит душой немного), которые приведут к появлению новых атак, но от этого никто не застрахован.

Легенды о "секретных теоремах линейной алгебры" всплывают с завидной регулярностью. Каждый решает для себя, верить в них, или нет.

> на ваш взгляд каким симетричным шифром и какой opensource технологией пользоваться ?

зависит от паранои. некоторые предпочитают Twofish+Rijndael. LUKS на мой взгляд на сегодняшний самый оптимальный выбор. Ну и TrueCrypt еще.

Я не знаю, что делать :(((
Ладно, поделюсь с вами своими достижениями :)
И всё-таки нельзя(!!!) отследить допмодули и модификацию ядра!
Если я написал, значит скорее всего уже решение есть, как это делается.
Я расскажу как постом пониже.

К сожелению, я не знаю, что такое locate.
Если не сложно - объясни, плиз.
Насчёт железки: это другое(!) решение. В случае с железкой я только подтвержду что я что-то скрывал. Тогда модно просто сделать попроще систему самоуничтожения и не морочить себе голову.

про таблетку:
А если у меня УПС не выдержит после очередного выключения питания?
Мне не очень приятно будет терять данные :(
Пока я стремлюсь к созданию иллюзии того, что у меня всё как у всех и я ничего не скрываю.
Уничтожение без возможности восстановления - это другая стихия.
Это тоже хорошо в чём-то, но не во всём.
А то так и напишут: боясь судебного преследования, уничтожил все данные :)))
Это доказательство, если есть ещё какие-то улики?
Вот потому и борюсь.

По поводу выбора FS:
Дело в том, что мне BSD нравится, и я хотел бы под ней работать :)
Потому ufs - более естественно.
Какой-нить райзер в опёнке ещё не поддерживается, например.
"Подменять своим" :) Да, именно это и можно делать, а что ещё остаётся? Только надо аккуратно подменять. Потом расскажу идеи.

> Если сделать reiserfs в файле на reiserfs, то восстановление будет очень сложным ;-)

:)))
Только с райзером разобраться будет настолько сложно, что оптимальней тогда будет вообще ничего не шифровать :))

хм..
Ну, такая идея тоже была уже.
Типа, всё пишем в tmpFS.
В данный момент я хотел бы там держать 10 гигов. Не многовато ли?
А когда всё-таки надо комп выключить - что делаем? А если он зависнет, это уже "всё"? Мне так не нравиццаа...

Интересно...
Плиз, ссылку на LUKS, если не сложно.
Насколько я понимаю, здесь идея, что мы используем неразбитое, не используемое якобы системой место на диске. Последнее время начал я думать, что не так-то это и плохо, оосбенно если половина диска будет незатронута.

Идея с контейнерами truecrypt хороша, но они там малость не додумали... Они бы сделали её "внутрисистемной" - вот это был бы класс. То есть контейнеры мы должны создавать НЕ НА СВОБОДНОМ месте на диске, а на той его части, которая официально принадлежит файловой системе. Причём с точки зрения файловой системы это никак не должно выглядеть - просто всякие осколки и мусор на диске. И вообще, могли бы ребята продумать чуть получше трукрипт - так, чтоб не видно было само то, что этот самый трукрипт используется.

2 ivlad.
Спасибо, что написал.
По поводу храниния чего-либо на удалённых хостах:
это хорошо для малых объямов инфы, с которой редко приходится работать. Не могу же я все домашние конфигурационные файлы, вплоть до истории браузера хранить на удалённом хосте? Плюс это и в денюжку вылетит, и в траффик, да и надёжность... я бы ни одной стране не поручил такое дело.

По поводу съёмных носителей:
это другая стратегия, если с уничтожением. Тогда всё можно и проще сделать. А если привлекать допносители для той же plausible deniability... Мож это и усложнит спецслужбам жизнь.. Но в конечном счёте и допносители должны у них оказаться.

Думаю, если б судили и у нас, то аргумент о применении шифрования в суде играл бы не в мою пользу. Не говорю уже о проблеме выпытывания пассфраз...

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

Почему? пытки?

по поводу:

> Еще простой вариант - взять съемный носитель, USB диск, на 40 GB, скажем. Отрезать первые 20 и сделать там обычную FS. Сложить туда всякую ерунду. Остальные 20 сделать томом TrueCrypt. Поскольку у TrueCrypt нет сигнатур, обозначающих его применение, контрагент не сможет доказать использование средств шифрования. Выглядеть это будет просто, как неразмеченный кусок диска с мусором. Так это и можно будет объяснить - хотел туда linux поставить загрузочный, но не успел. Опять же, это не будет защитой от контрагента, не действующего в правовом, так сказать, поле. ;)

Хорошо, а откуда сам трукрипт будет запускаться и как?
Будет ли виден сам факт, что программа "трукрипт" установлена?
Если да, то плохо.
В конце ещё напишу сегодня о своём частичном решении.

РЕШЕНИЕ - 1

Рассказываю о своём первом РЕШЕНИИ поставленной проблемы.
Это будет работать только на линуксе и на ядре 2.2 так как на остальных ядрах поддержки stegfs нет.
Компилим в какой-нить директории модуль к ядру со stegfs (согласно документации на stegfs есть 2 возможности - намертво прикомпилить к ядру и как модуль). После компиляции всё ненужное стираем, а модуль шифруем каким-нить методом, сохраняя на диске в определённом месте, и стираем его, запоминая куда мы его записали. Действия после:

1) Подходим к компу, восстанавливаем стёртый файл с зашированным модулем stegfs и расшифровываем этот модуль стразу в tmpfs. После сразу же удаляем файл с модулем и следим, чтобы на это место физически ничего не писалось - где лежит этот модуль.
Теперь у нас ядро с модулем, а модуль есть только в памяти.

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

3) Ещё тогда нужно будет продумать систему с ведением логов в /var а так же, чтобы не появлялись нигде ненужные пути.

Нажатие на ресет вернёт всё к исходному состоянию.

Минусы:
1) Возможно, с музфайлами, служащими как контейнеры для stegfs ничего нельзя будет делать.
2) По заверениям разработчиков stegfs ненадёжна, и сильно будет тормозить по ср. с обычной криптофс на файле.
3) Это будет работать на данный момент только на линуксе и только на ядре не более новом, чем 2.2.
4) Можно будет установить, что есть стёрнтый файл с чем-то небольшим и зашифрованным... (с модулем stegfs).

В общем, приятного мало.

РЕШЕНИЕ - 2

Очень просто, работает везде, интересный подход.
Делаем так:

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

После же перезагрузки нужно восстановить стёртый файл с криптофс (надо помнить где он находится...), смонтировать его как криптофс и снова удалить. При этом нужно следить за тем, чтобы физически не писалось на место, где файл с криптофс не расположен. Также, нужно следить и за
/var.

Минусы:
1) После того, как диск попадает в руки спецслужб, они восстанавливают стёртые файлы и видят: был какой-то файлик с невнятным содержанием на несколько гигов... К чему бы это?
2) На практике восстанавливать стёртые файлы может оказаться не простой процедурой, и для этого прийдётся хорошо разобраться с тем, как устроена fs. Вроде бы по этому делу нет документации, а так же нет утилит восстановления стёртых файлов в ufs. Некогда искал - не нашёл.

Но это уже усложнит задачу службам - ещё надо восстановить файл с криптофс, а не получить его существование нахаляву.
Поидее надо стирать и метаданные о криптофс-файле с диска, но тогда после стирания криптофс-файла с диска пользоваться им не получится (как я тут расписал)...

Ещё идеи: можно грузиться с сидюка для всякой такой работы, но опять же, а где хранить инфу после перезагрузки...
Ещё можно сделать привязку к нескольким людям и компам: чтобы, например, получить ключ, нужно чтобы кто-то ещё кроме меня ответил на запрос. С одной стороны, это потеря самостоятельности, а с другой стороны, в критический момент только того, что имею я будет недостаточно для восстановления информации. (Ядерная кнопка у нас в стране так устроена: чтоб полетела ракета - нужно чтоб 3 человека дали спецсигнал, а после этого ракета полетит, если только 2 текущих на дежурстве летейнанта решат что её запустить всё-таки надо... А могут и решить что не надо... Хотя по уставу должны. Более, того, уже были случаи, когда один чел должен был запустить, но не запустил. А то холодная война стала б горячей :) )

Держать всё в tmpfs тоже хорошая идея, но если ресет...
И не очень понятна процедура синхронизации tmpfs с диском перед перезагрузкой, как это делать.

У кого ещё какие мысли по поводу написанного?

Да ладно.. не знаете.. ;-) А я вот знаю, надо Jethro Tull 69-го послушать чтоб отпустило.. ;-) Охотно ознакомился бы с вашими достижениями.. ;-)

Вы совершенно правы, это используется - и модификация ядра и модулей также.. Я лет 6 тому назад столкнулся с подобной ситуацией.. классно всё было зделано.. в логах - всё чисто, файловай система - идеал, но.. человек допустил маленькую ошибку.. забыл или не сумел внести именения в ядро, а потому оно при загрузке, хоть очень быстро но всё же ругалось на модуль, что и обратило моё внимание на него.. ;-)) в логах это никак не отражалось - тем более странно.. Вообщем.. сами понимаете, стоит лишь возникнуть подозрению..

А модуть так грамотно написан был, если бы не неряшливость внедрявшего... может до сих пор работал бы.. ;-)

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

Да, я понимаю.. ;-) Лично я своё знакомство с операционными системами именно с BSD и начинал,.. стоит ли ещё говорить насколько это также и мне близко.. Но, спарведливости ради, стоило бы признать, что ufs уже давно нуждается в модификации.. В принципе уже давно есть претенденты на включение в опёнок того же рейсера, просто, Тео эта идея почему-то не внушает оптимизма..

Ага расскажите, обмен опытом - это всегда интересно.. ;-) Я, в свою очередь, тоже поделюсь чем-нить..

Да нет там ничего сложного.. ;-)

Можно совет, лучше не в качестве модуля,...

2 MiracleMan:

Вы сотрудник спецслужб, что ли??
Что за ужас!

Ну что вы.. Господь с вами... ;-)) Не люблю я всякие службы, особенно спец.. ;-) Так, просто, иногда знакомые звали помочь, взломы всякие раскрывать..

2 MiracleMan
Ну ладно, тогда ещё жить можно...

Вы бы тогда рассказали поподробнее про того человека, что с модулем натворил... Чем закончилось, что за цель такая была у него... В общем-то надо очень хорошо поломать систему если он смог даже свой модуль подгрузить... Странно это как-то. Он что, поломал серверную и установил своё программное обеспечение??

А почему лучше "не в качестве модуля"?
Если грузиться система будет без модуля - всё будет работать...
Не надо же его статически прописывать..
А ошибиться всегда и много в чём можно.

Я на опёнке когда-то сидел, можно сказать, даже, пратически на него сразу с винды спрыгнул (хотел на фрю, но из-за хардварных глюков видеокарта не заработала по-человечески). А потом всё равно вернулся на фрю, но уже новой версии - тогда я не умел ещё стандартными тулзами опёнка обходиться, аську мне хотелось интерфейсную с гуями...
Думаю, что вернусь снова к опёнку скоро.
Поэтому очень не хотелось бы рассматривать что-то отличное от их ФС.
Казалось бы, в оупене должны быть какие-то системы и для моего случая, исходя из их лозунгов...
Тео любит стабильность, и надёжность... За это уважают его и его систему. Поэтому и не включает. Кроме того, Тео вообще не переносит такое понятие как "линукс" в принципе.
Наверное, чем включать райзер в бсд.. лучше уж просто ставить себе линукс. Зачем линь дублировать...

Да, я, к сожалению (или к счастью) не программист :) а всего лишь самый обычный пользователь.

Собственно, проблема на данный момент свелась к тому, что уже написал:
Файлик с криптофс можно удалить и продолжать с ним работать, но метаданные остались, а значит, он может быть легко восстановлен.
Удалим вместе с метаданными - работать перестанет после удаления.
Опять плохо. Может, это тупиковый путь.

С контейнерами работать как-то оно тоже не понятно...
Задача сводится к предыдущей тривиально: где и как будет сама прога "трукрипт" храниться? Сменные носители ведут в итоге к такой идеи в конце концов: всё секъюрное хранится где-то, а не на рабочем компе. И защищать, надо, типа, те сменные носители. Но в таком случае можно сразу защищать свой комп или поставить систему самоуничтожения, хоть даже с тем карточками...

Не знаю.
Видать, мало у кого такая проблема вставала. А то уж давно б решили.

2secure_crolik

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

А я как-то исторически.. так получилось, что знакомство, по серьёзному, с системами начинал именно с FreeBSD 2.2.8 - долго оставалось моим фаворитом.. В идеале, конечно, я тогда Solaris для домашних нужд хотел, но.. спарки были дорогие, а x86 от Sun, откровенно говоря, тогда было просто убожество.. Затем, почему-то NetBSD, и только потом OpenBSD.. Зато мне понравилось.. Система простая до гениальности.. ;-)

Конечно же, зачем дублировать.. Не в том дело.. Вот, к примеру, мне надо, у меня дома много систем живёт.. И мне бы хотелось, чтобы они в любом случае могли общатся друг с другом.. В принципе, не вижу тому преград, кроме "религиозных"..Всё-таки мне кажется рано или поздно эта проблема найдёт своё решение.. Я, конечно же, уважаю Тео за его принципиальную позицию, но иногда мне кажется, что он просто слишком упёрт в некоторых вопросах..

Вы в самом деле думаете, что такие проблемы не решали? Думаете кто-либо в здравом уме о таком на форумах распространяться будет? Задача ясна, Пути решения тоже.. Осталось лишь начать и закончить.. ;-)

man locate, вкратце - шарится по винту и создает кэш для быстрого поиска.

> А если у меня УПС не выдержит после очередного выключения питания?

Это как это? Тут вариант такой - или вас не будет, или вы будете и ничего не предпримете? Используйте ИБП с обратной связью (nut в помощь).

Я вот вспомнил, в некоторых продуктах alladin есть дополнительный пароль для ввода под принуждением, его нужно сообщить, когда вам угрожают, диск откроется, но на некоторое время (1-2 минуты обычно), после чего система симулирует зависание, а после перезагрузки контейнер будет сильно поврежден.

> Хорошо, а откуда сам трукрипт будет запускаться и как? > Будет ли виден сам факт, что программа "трукрипт" установлена? > Если да, то плохо.

Не плохо, сделайте маленький томик TrueCrypt с историей болезни и.т.п, как писал ivlad.

Ну что же ты делаешь? Ето же не игра.. Сто раз подумай, прежде чем что-либо советовать..