Re: ntfs-3g и монтирование непривилегированным пользователем
Dmitrii Kashin -> debian-russian@lists.debian.org @ Tue, 11 Sep 2012 13:35:38 +0400:
>> А они точно ограничены? Или они все-таки могут позвать, скажем,
>>
>> ntfs-3g -o какие,угодно,опции /dev/sdc1 /usr
>>
>> при такой настройке? А то suid я вижу, а упоминаний про /etc/fstab в
>> man ntfs-3g - нет, и с какого перепугу он не сможет выполнить эту
>> команду, я не очень понимаю...
DK> Конкретно данную операцию - не сможет. ntfs-3g в качестве точки
DK> монтирования допускает только каталоги, в которые юзер имеет права
DK> записи.
DK> --------------------
DK> $ ntfs-3g /dev/sdc1 /usr
DK> ntfs-3g-mount: user has no write access to mountpoint /usr
DK> --------------------
DK> Более того, она должна принадлежать юзеру, или хотя бы он должен
DK> состоять в группе, имеющей право записи в директорию. Если бит записи
DK> есть у всех - примонтировать не удастся.
DK> --------------------
DK> $ ntfs-3g /dev/sdc1 /tmp
DK> ntfs-3g-mount: mountpoint /tmp not owned by user
DK> --------------------
DK> Мне кажется, разработчики хорошо продумали подобные ситуации.
А вот у меня нет такой уверенности. Что они все-таки думали, Вы меня
убедили. А вот насколько хорошо - это куда более сложный вопрос.
Безопасность - очень тонкая область, чтобы была уверенность в том, что
продумано действительно хорошо, нужен аудит специалистами, желательно в
количестве сильно больше одного.
DK> Кстати, подобная ситуация и у pmount, если не ошибаюсь. Она
DK> предоставляет список устройств, которые имеют право монтировать члены
DK> группы plugdev, однако ж ее за suid-бит Вы не ругаете. Или ругаете?
pmount я в глаза не видел, поэтому ничего про нее сказать не могу.
>> Dmitrii Kashin -> debian-russian@lists.debian.org @ Mon, 10 Sep 2012 15:22:00 +0400:
>>
>> DK> Однако и в случае с suid-битом, и в случае c sudo, ntfs-3g работает с
>> DK> правами root. Так в чем же разница? Почему sudo как решение проблемы
>> DK> по-вашему лучше, чем suid?
>>
>> А sudo позволяет сказать, что Васе можно выполнить mount /mnt/flash,
>> который сводится к ntfs-3g /dev/sdc1 /mnt/flash но нельзя выполнить
>> ntfs-3g - /dev/sdc1 /usr. В смысле, я точно уверен, что позволяет.
DK> Да, sudo обеспечивает это наверняка. Впрочем, рассуждая таким образом,
DK> я, наверное, должен создать в sudoers список из программ, имеющих
DK> suid-бит и предусмотреть все случаи их использования пользователем,
DK> разрешив ему запускать их _исключительно_ с заданными мной параметрами.
DK> Мне кажется, это будет несколько абсудрно.
В данном случае - да, учитывая, что одна из этих программ - это сама sudo.
Потом, нет, я не считаю, что если sudo обеспечивает более гибкую
настройку, то ею непременно надо пользоваться. Мне представляется, что
в рассматриваемой ситуации вариант с sudo еще и удобнее (по крайней
мере, не менее удобен), и не требует холда на пакетах (чреватых
неустановкой секьюрити апдейтов).
>> Ну и да, про отъем этих прав обратно в параллельном письме тоже верно
>> замечено. На выдачу прав это тоже распространяется, кстати - невозможно
>> сказать пользователю посреди его сеанса "я тебе дал права, можешь
>> работать". Сеанс придется закрывать, либо обучать пользователя
>> ухищрениям вида ssh localhost или (все тот же самый) sudo -u user.
DK> Да, это дело, пожалуй. Но вообще, странно слышать, что это минус. Ведь
DK> на этом принципе построены права доступа ко всему в системе вообще, и
DK> предполагается, что Вы делегируете/отбираете права не так часто и резво.
Не часто. А вот "резво" - это зачастую преимущество. Срабатывание
настройки сразу, как только админ ее сделал, куда удобнее, чем после
перелогина. Это часто важно, ибо перелогин - это почти всегда потеря
контекста решаемых задач, часто сразу нескольких. У меня, скажем, в
норме минимум двух, а чаще трех. То есть фактически потеря от 15 минут
до часа времени. Ну я, правда, довольно опытный админ сам по себе, и
могу после включения себя в группу сказать sudo -u ran нужная команда,
теряя таким образом всего несколько секунд (на то, чтобы наступить на
тот факт, что в этой сессии я еще не в той группе).
Reply to: