Задача шифрования папки.

Копай в сторону FUSE. А скорее всего, расчехляй компилятор, самому писать придётся.

сомневаюсь, что такое вообще кому-то и для чего-нибудь нужно.

сомневаюсь, что это принципиально реализуемо в разумных программных окружениях,

Тут скорее в сторону матчасти и здравого смысла надо копать.

Следы здравого смысла в оп-посте я вижу. А насчёт матчасти - принципиально через тот же FUSE вполне реализуемо, только директория будет точкой монтирования для чего-то там. При определённой хитрожопости в реализации добиться

1)ОС видела эту папку как не зашифрованную, и давала возможность открыть например PDF.
4)защита от LiveCD и Single User Mod

вполне реально.

2)При копировании из этой папки файла, например в /home файл больше не открывался
3)при утечки файлов, на тот же rghost, файлы не должны открываться на тех компьютерах, на которые их скачают

Добиться этого сложнее, но если например на лету шифровать блоки для чтения при выполнении read/cp/mv а перед открытием дешифровать через хитрожопую библиотечку-враппер для софта, то при отсутствии библиотеки/ключа на выходе получается нечитабельная хрень.

Или ещё круче, использовать под хранилище VM полностью на шифрованном разделе хоста без сетевого доступа к этой VM.

пункт 1 нарушает пункт 2 и 3

2,3) Как отличить копирование/загрузку на файлообменник от чтения программой-читалкой?

Задача шифрования папки

Вы уж извиняйте, что с офтопом лезу, но в такой формулировке теме в talks место. Звучит так, будто отец ТСа сильно пьет, и он решил принудительно своего отца зашифровать от алкоголизма.

Да, это всё реализуемо. Но. Это похоже на костыли, инструмент, подогнанный под форму извилин мозга конкретного человека. Возможно, ТС для начала стоит ознакомиться с основами шифрования и почитать про EncFS (для примера). Формулировки и термины ОП явно выдают слабое понимание сути его собственных вопросов.

все таки нет желания писать хитрожопую библиотеку, рассчитывалось что можно как-нибудь через аля openssl решить это, и встает вопрос с ключом, как сделать чтобы и его вместе с файлом не уперли, как решить это без eToken'a ?

1) man encfs
2) невозможно: копирование и чтение — одно и то же, учи матчасть
3) см. пункт 2.
4) см. пункт 1.

Формулировки и термины ОП напоминают мне: «а почему у меня трафик кончился, я же не качал ничего, а только смотрел?..»

1) ОС давала возможность открыть например PDF.
2) При копировании из этой папки файла, например в /home файл больше не открывался

/0

Сделай папку невидимой. Чтобы самому потом ее увидеть, нужно в свойствах эксплорера галочку поставить.

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

см. чуть выше. костыль-костылём, но есть шанс, что взлетит.

2)При копировании из этой папки файла, например в /home файл больше не открывался
3)при утечки файлов, на тот же rghost, файлы не должны открываться на тех компьютерах, на которые их скачают

Если что-то можно прочитать, значит можно и скопировать. Это правило верно всегда.

Под пункты 1 и 4 подходит ecryptfs.

Это получится сильно огороженная фигня: файлы можно будет просматривать только специализированной программкой. «Окуляром» pdf уже не откроешь.

Задача шифрования папки. (комментарий) тут про огороженность. Либо я не понимаю суть LD_PRELOAD

И? Открываешь mc, жамкаешь F5, и все — п.3 нарушен.

Если не задал LD_PRELOAD скопирует хрень. С LD_PRELOAD mc скорее всего не взлетит. Ну и до кучи, кто сказал, что mc сам копирует файлы? я думаю он это перекладывает на системные утилиты.

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

Ну и до кучи, кто сказал, что mc сам копирует файлы? я думаю он это перекладывает на системные утилиты.

Сам копирует. Ничего в этом сложного нет.

Ну, либо если не mc, то просто запустить

LD_PRELOAD=/lib/mystupidlib.so cp AnalProbe.txt /media/flash

Привет, к сожалению не знаю проги на православный линукс, но на оффтопик есть такая штука как NASCA PC Rights management

Ок. согласен.

Ладно, зайдём с другой стороны, запретить чтение файла неавторизованным утилитам через apparmor/selinux не получится?

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

ОС видела эту папку как не зашифрованную, и давала возможность открыть например PDF.

При копировании из этой папки файла, например в /home файл больше не открывался

Объясните, пожалуйста, принципиальную разницу этих действий.

use-case примерно такой: есть шифрованный раздел, доступ к которому на чтение определённых файлов ограничен средствами apparmor/selinux для списка приложений. А все остальные идут лесом. Такой вариант возможен?

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

А, ну разве что так. Т.е. разрешить, скажем, читать pdf-файлы только pdf-смотрелкам, текстовые файлы вообще запретить открывать, и т.д., и т.п.

А если провернуть, что чтение файла утилитой не из разрешённого списка читает /dev/urandom, то 2 и 3 пункты начального сообщения тоже в общем-то выполняются.

Выше, быстрее, сельнее - PrtScr.
Идея ясна, но уберечь полностью информацию не выйдет, а время будет потрачено.

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

Так вот кто придумал DRM и прочую подобную гадость!

ОС видела эту папку как не зашифрованную, и давала возможность открыть например PDF.

При копировании из этой папки файла, например в /home файл больше не открывался

Взаимоисключающие параграфы

Мамку зашифруй, вендузятник!

1)ОС видела эту папку как не зашифрованную, и давала возможность открыть например PDF.

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

Можно сделать так:

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

• пусть флешку к тонкому клиенту подключить нельзя, также нельзя вставить CD-ROM
• выход в интернет производится с отдельного компьютера, т.е. пользователь имеет перед собой два и более монитора, на одном он смотрит документы, а на другом работает в интернете

Но сфотографировать экран с секретным документом или получить VGA сигнал пользователь все равно сможет.

Вообщем вся суть в том, что нельзя доверять пользователю, дать ему в руки всю систему недопустительно.

Но на мой взгяд лучше бороться с самой проблемой (люди, которым нельзя доверять), а не с ее проявления (утечки). 100% надежных людей не бывает, но ваша задача заключается в том, чтобы найти наиболее надежных надежных людей из всех доступных.

поддерживаю.

encfs

1 и 4 - encfs.

3. Это теоретически возможно, если переформулировать задачу: нужно чтобы файлы хранились и обрабатывались зашифрованными без монтирования encfs/ecryptfs. Т.е. нужно для программ переопределить fwrite(), fread() и остальное через подгрузку собственной либы LD_PRELOAD. В либе дергать gpg для шифровки/зашифровки файла, с которым работает юзер. Но если в целом смотреть, то такой подход ни от чего не защищает реально, а лишь успокаивает параною.

2 - либо см.3; либо возможно, что selinux сможет заблокировать чтение именно скопированного файла за пределами криптоконтейнера. Selinux в ряде случаев способен отличить копирование от чтения, но по сути вместо вызова cp можно вызвать cat или dd, и обойти эту странную возможность selinux.

Очередная попытка сделать защиту от копирования, что, как мы знаем, невозможно?

А, ну разве что так. Т.е. разрешить, скажем, читать pdf-файлы только pdf-смотрелкам

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

текстовые файлы вообще запретить открывать

И целая тонна программ перестаёт работать.

Тут уже неоднократно повторили. Если можно прочитать, значит можно скопировать.

что мешает мне его из читалки сохранить куда угодно?

Из огороженной читалки не получится ☺

Но в памяти файл будет

Зашифрованный.

И целая тонна программ перестаёт работать.

А я уже говорил: дурацкая затея.

Зашифрованный.

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

Расшифровывать только текущий кусок

Расшифровывать только текущий кусок

Значит в RAM будет храниться расшифрованный кусок файла? Тогда можно считать что это равноценно нахождению файла в памяти.

И да, где будет находиться ключ?

Не мучайся и поставь что-нибудь типа truecrypt (если проприетарность не пугает) и сделай криптоконтейнер.
Монтирование с запросом пароля и отмонтирование можно на пару ярлыков
повесить.
Защита от livecd и рута.

Инкрементирую truecrypt. Если список файлов известен, можно, например, забабахать скрипт, который будет монтировать зашифрованное, вытаскивать файл, открывать его в огороженной читалке и отмонтировать обратно. Но выдрать содержимое всё равно будет возможно.

Lинукс научился грузиться из под трукрипта?

Грузить livecd и запускать внешний контейнер с трукриптом

Пускать из initramfs как и всё остальное, не?