о руте

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

Гипотетический линукс-вирус будучи запущенным на машине с правами юзера (по умолчанию) может сделать все что угодно в пользовательской папке. Например, прочитать ваш .ssh/ и bash_history и передать на сторону :)

Для защиты от этого и придумывают всякие штуки типа AppArmor и SELinux. Да, я их не использую, и не умею пользоваться, но гаечные ключи уже есть, и желающие могут начинать закручивать гайки.

Я не знаю, как тебе еще объяснять, чтоб ты понял. У них общий хомяк. У них общие конфиги. Нет никакого отдельного .profile для подучетки, есть только общий для всех. В .profile писать может только username.

В таком варианте все намного более труЪ, но тут возникает проблема: как программы, запущенные от username.restricted, будут хранить свои конфиги?

Дабы решить эту проблему, разрешив каждой программе модифицировать только свой конфиг, можно применить AppArmor или SELinux (можно и без них, но тогда понадобится разрешить всем username.restricted писать в хомяк, что нехорошо). А это либо доп. трудности (с политиками), либо меньшая безопасность (если каждый username.restricted умеет писать в хомяк).

Недоступность .bash_rc и прочих конфигов баша не решает проблему, пока есть конфиги гномокед и wm-ов

И даже более того, никто в здравом уме не будет выполнять su из песочницы — ибо зачем?

Не подумал об этом. Если из username.restricted никто не будет делать su - взлом username.restricted ничего не даст. Количество уязвимых аккаунтов уменьшается до 2 - username.base (в который логинимся, из него su обязательно будет делаться) и username (который может всё в пределах хомяка пользователя). Тогда идея получается намного безопаснее, но не совсем идеал.

Дыры фиксят достаточно быстро после их обнаружения.

Fixed.

Некоторые практичные люди о дырах не сообщают, а юзают в своих целях -)

Есть PPA. А для чего в дебиане дополнительные репозитории?

Хых. Логично. Линакс давно уже не мейнфрейм на 10 чел.

Необнаруженная дыра опасна только потенциально.

Такие тоже есть, но все же:

Покажи эксплойт, которым я смогу получить права рута на своей системе с актуальным ядром (deb testing, linux 3.1) - тогда и будет о чем говорить.

Вот в том-то и суть, что достаточно доступа к конфигам баша либо других шелов

chown username /home/username/username.restricted/.bashrc
chmod 644 /home/username/username.restricted/.bashrc

Вот и всё. Все конфиги субюзера могут быть отредактированы только более привелегированным юзером.

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

Почему портит? Всякие файломенеджеры запускаются с полными правами, а вот браузеры, чатики и прочее — с ограниченными

как программы, запущенные от username.restricted, будут хранить свои конфиги?

Ты хотел написать: «как программы, запущенные от username.restricted, будут _изменять_ свои конфиги».

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

Вопрос «кто даст соответствующие права на нужные файлы/каталоги» в рамках рассмотрения самого механизма нас мало интересует. Это вопрос политики администрирования. Возможны любые варианты от «пользователь вручную» до «автоматически применять шаблоны, лежащие в /etc».

Недоступность .bash_rc и прочих конфигов баша не решает проблему, пока есть конфиги гномокед и wm-ов

Так и к ним тоже доступа на запись из ограниченной учетки нет.