Как ограничить вызов Ajax для запуска с определенными разрешениями POSIX?

У меня есть jsTree, который вызывает веб-службу RESTful для получения списка файлов и каталогов. Я хотел бы ограничить возможности этой веб-службы на основе разрешений POSIX пользователя, который делает этот вызов.

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

В настоящее время веб-служба ищет зашифрованные данные в файле cookie, который проверяет пользователя, вошедшего на веб-сайт. После аутентификации пользователя веб-служба выдает ответ для папки, указанной jsTree (например, для всех файлов и каталогов в /home/userA). Веб-служба вызывается еще раз для подкаталогов, еще раз для подподкаталогов и так далее.

Однако веб-служба работает с разрешениями уровня root, поэтому, если каким-либо образом было указано другое имя пользователя с помощью userA, например. для просмотра /home/userB, то userA мог видеть список файлов и каталогов, на просмотр которых ему или ей не было предоставлено прав.

Есть ли какой-то эквивалент suExec, который может запускать веб-службу с разрешениями указанного пользователя?

Если это поможет, моя конкретная служба представляет собой сценарий Perl, использующий File::Find::Rule для предоставления одноуровневого глубокого списка содержимого указанного пути.

ИЗМЕНИТЬ

Все передается через соединение с шифрованием SSL.


person Alex Reynolds    schedule 12.02.2011    source источник
comment
Хм. Может быть, поместить все действия в отдельный скрипт и выполнить sudo на основе зашифрованного имени пользователя в файле cookie? Поскольку вы работаете как root, у вас не должно возникнуть проблем с sudo'ing в качестве фактического пользователя.   -  person Pekka    schedule 12.02.2011
comment
Вы зашифровали пользователя в куки? И отправлять данные по http? Это очень плохая идея, см. codebutler.com/firesheep для простой демонстрации того, что может произойти, если кто-то использует ваш сайт через Wi-Fi в кафе.   -  person btilly    schedule 12.02.2011


Ответы (1)


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

Во-вторых, сохранение имени пользователя в зашифрованном файле cookie и отправка данных по протоколу http делает ваших пользователей уязвимыми для перехвата сеанса. Учитывая, что вы получаете доступ к их фактической учетной записи пользователя, это проблема. Особенно с учетом того, сколько людей используют беспроводную связь и сколько детей имеют доступ к инструментам для перехвата сеансов типа «укажи и щелкни», таким как firesheep.

Поняв эти моменты, вы можете воспользоваться несколькими подходами. Предполагая, что вы используете предварительный веб-сервер (а не многопоточный), вы можете использовать POSIX::setuid, чтобы временно изменить себя на нужного вам пользователя, а затем использовать его снова, чтобы вернуться к своей обычной личности.

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

person btilly    schedule 12.02.2011