Это разумная вещь: другие платформы, такие как MacOS-X, и приложения, такие как Chrome, используют «песочницу» для запуска целых приложений или частей приложений таким образом, что они перестают иметь полный контроль, эквивалентный тому, что у вас есть.
Итак, в ответ на 1, да, если вы запускаете приложение, работающее от вашего имени, оно имеет эквивалентный доступ к тому, что вы делаете: любой файл, который вы можете редактировать, он может редактировать и так далее. Единственное исключение - если само приложение делает что-то для ограничения прав.
В ответе на 2 вы, вероятно, должны быть смутно обеспокоены этим гораздо больше, чем активно беспокоиться об этом. В конце концов, каждое приложение, которое вы запускаете, имеет одинаковый доступ - единственное, что отличает DropBox, это то, что оно было получено от кого-то другого, кроме дистрибутива восходящего потока.
Итак, 3: вы можете это исправить? Ответ "вероятно, нет". Дело не в том, что это невозможно, а в том, что это, вероятно, будет трудно сделать так, чтобы удовлетворить ваши желания использовать приложения или услуги.
Использование chroot позволяет вам делать вид, что существует другой «корневой каталог», чем настоящий. Это изолирует приложения (например, dropbox) от вашего реального корня - и может позволить вам избежать риска, что он сможет прочитать остальную часть вашего домашнего каталога. (Добавьте символическую ссылку из ~/.dropboxв, ~/chroot/whatever/home/you/.dropboxи это не так уж неудобно.
Однако вам нужно быть пользователем root или использовать такой инструмент, как schroot, для управления доступом к запуску приложения, а chroot изолирует только несколько частей системных файлов. Приложения с корнем внутри, которые все еще могут видеть снаружи или уйти. Различные другие ресурсы (IP-порты, pids и т. Д.) По-прежнему используются совместно.
Кроме того, могу поспорить, что DropBox имеет компонент пользовательского интерфейса, и он не очень хорошо работает в хроматическом режиме. Даже если это так, это ограничение вредит другим приложениям.
Альтернатива, приложение setuid, - это способ сказать: «независимо от того, кто его запускает, запускайте его как этот другой пользователь, а не как пользователь, который его запустил».
Это чаще всего используется для того, чтобы приложения, которые вы, обычный пользователь, запускали от имени пользователя root, запускали, например, sudo. Однако он может также назначить пользователя или группу процесса непривилегированным пользователем.
Проблема в том, что он запускается от имени другого пользователя - так же, как вы запускали его с чем- sudo -u another-user dropboxлибо еще. Это означает, что у него нет доступа к вашему домашнему каталогу, и, без усердной работы, у вас нет доступа к домашнему каталогу других пользователей.
Вы можете обойти это, но это не тривиально и не удобно в общем случае. Как правило, вы хотите поделиться группой и попытаться организовать, чтобы файлы, которые она может читать, принадлежали этой группе, а не вашей стандартной группе. Это не тривиально, даже с каталогами setuid (которые изменяют группу или владельца созданных под ними файлов), отчасти потому, что вам нужно управлять umask, а это плохо для Linux.
Наконец, вы можете использовать AppArmor или SELinux для защиты приложения. Я считаю, что AppArmor - это то, что Ubuntu выбрал в качестве своего предпочтительного варианта. Хотя убедительно утверждается, что он менее безопасен, чем SELinux, он также концептуально проще, поскольку основан на видимых именах и путях в большей степени, чем защищенные метки.
Вы можете обнаружить, что это эффективный способ повысить безопасность без необходимости идти по более сложным путям. Теоретически это должно позволить вам ограничить DropBox только той ~/.dropboxпапкой и ничем иным, без необходимости запуска от имени другого пользователя.
Итак, если вы действительно хотите улучшить свою безопасность, посмотрите путь к chroot. Это наименее болезненный способ улучшить безопасность DropBox в Ubuntu - гораздо меньше, чем приложение setuid, по крайней мере.
Тем не менее, шансы, что ваш самый большой риск разоблачения связан с сотрудником DropBox - мы знаем, что они дедуплицируют даже между пользователями, поэтому их системы могут видеть незашифрованный контент, что означает, что кто-то, работающий на них, мог бы сделать то же самое.
Вы могли бы вместо этого использовать encfs для шифрования файлов перед их отправкой в DropBox ...