Шифрование без доступа root-a

encfs

Плюсую анонима. Сам только что проверил: если я монтирую зашифрованную директорию, даже рут ее открыть не может.

любой root может сделать su - uky и поиметь доступ к файлам

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

а разве можно делать sudo su?

можно, хотя достаточно sudo -i -u uky

можно делать subo bash, sudo -s, su.

sudo su

извращенцы.

настроить sudoers так, чтобы все, кто имеет право делать суду, делали его для конкретных команд, а не с целью получить интерактивную оболочку ;)

sudo su

извращенцы.

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

С EncFS можно вроде юзать с pam_mount, который будет монтировать ФС при логине, и отцеплять после логаута. Т.е. пока ты в системе - кто-то в принципе может подглядеть что и как, но если вышел - всё.

На то он и root.

Т.е. пока ты в системе - кто-то в принципе может подглядеть что и как

Нет. EncFS по умолчанию монтирует шифрованый каталог так, что войти туда может только смонтировавший, остальным она возвращает ошибку. Правда, никто не ззащищает от su - encrypted_dir_owner ....

См. комент выше + можно настроить виртуалку с шифрованием. Хотя, теоретически, её можно поиметь из-под рута (причём очень даже есть тулзы для этого, т.к. дебаг всем нужен), но врятли кто-то будет этим заниматься. Если нет поддержи аппаратной виртуализации, то вместо KVM можно юзать Xen, либо qemu (с большими потерями производительности, однако без root'а и перезапуска вообще). Далее монтируй sshfs или NFS.

И почему ты не можешь другим юзерам запретить sudo? Или, если они только 2-3 команды юзают, то разреши только их.

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

слушай, ну мне пофиг, но как быстро и просто запустить баш от рута имея sudo? писать sudo /bin/bash в несколько раз длинее чем sudo su -.. мне пофиг сколько «контрацептивов» ибо это хромая аналогия. sudo su - работает отлично.

вообще-то, sudo -i. но маны же не для тебя, да? ;)

гм :)

ну а короткий аналог sudo su - user1 ? :)

ибо sudo -iu user1 - прав не хватает, прописывать надо..

но в целом спасибо, просветил отсталого :)

хех, это называется нечитай@навопросотвечай

Можно попробовать какой-нибудь хак написать, чтобы было что то вроде такого (если KDE): LD_PRELOAD=libmyopenhack.so dolphin

При запуске libmyopenhack.so запросит пароль и будет показывать вместо реальной папки /home/user/somefolder содержимое зашифрованного файла. Dolhpin - это файловый менеджер KDE. Как только он откроется таскайте файлы туда-сюда drag'n'drop-ом, можно даже из окошка с файлами в приложение (открытый KWord какой-нибудь).

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

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

Помимо упомянутой EncFS есть EcryptFS и прочие Tahoe. Они решают задачу: расшифровываться будет на удалённом клиенте, а храниться на сервере.

А если работать надо локально, то задача нерешаема (разве что специальные модули SeLinux с прозрачным аудитом его настроек всеми теми, кто имеет root-доступ).

Если машина удалённая, то можно. Монтируем по sshfs каталог на сервере, кладём туда крипт-контейнер, который тоже монтируем в локальный каталог. Для рута на удалённом сервере вы будете просто писать в большой файл всякий мусор, т.к. шифрация/дешифрация будет происходить в памяти вашего компьютера, а запись\чтение fs на сервере. Смысл в том, что бы разделить эти два процесса физически - тогда секьюрно.