amarao (amarao_san) wrote,
amarao
amarao_san

User-driven application

В своих раздумьях о том, как должно работать приложение на django (где хранить конфиги и т.д.) и наблюдая за текущей грызнёй в debian-russian о методах запуска сервисов, я, кажется, вижу некое принципиальное разногласие между двумя парадигмами.

Эти парадигмы можно сформулировать как ответ на вопрос: чьи приложения на машине?

Варианты ответа:
1) пользовательские
2) администратора

Нужно понимать, что под "приложением" понимается реализация любого алгоритма любым способом, выходящим за пределы sandbox'а. Даже если этот выход трижды разрешён пользователем. Разумеется, любой веб-сайт с активным содержимым является приложением, причём приложением опасным (к которому имеют доступ все желающие из интернета).

Итак, парадигма номер один: администратор обеспечивает платформу, разделение прав и ресурсов, а пользователь волен запускать всё, что ему будет приятно. Это классическая парадигма хостинга, на котором разрешено выполнение скриптов. Это же классическая модель виндовой машины. Это же классчиеская модель с ~/bin.

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

Очевидно, что второй вариант существенно затратнее в смысле администрирования: администратор должен следить за новыми версиями ПО, за тем, чтобы были все нужные программы и не было бы программ лишних. (вопрос обновлений сильно упрощается при наличии системы обновлений).

Первый же вариант очень опасен: пользователь может не иметь нужной квалификации для обновления ПО или просто не придавать этому значения. Запускаемое ПО никак не контролируется, а, значит, может быть запущено, в том числе, вредоносное ПО.

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

С корпоративным десктопом и сервером всё понятно: они могут полностью следовать второй парадигме, так как есть централизованное управление и представление о том, что "сегодня потребности в масле не имеется". Особо это понятно в условиях корпоративного сервера, на котором нет, как таковых, пользователей (в смысле, людей), а есть лишь заданный набор функционала, который и обеспечивается конфигурированием компьютера.

С "свободными" пользователями ситуация сложнее - они не желают подчиняться единой парадигме, и возникает очевидная мысль: разрешить запускать то, что они хотят.

На самом деле, такая мысль, при чётком разделении между пользователями по ресурсам, ничего в себе плохого не несёт: пользователь рискует только своими данными.

Настоящая задница начинается в тот момент, когда появляются "пользовательские приложения", интегрированные в общую (корпоративную) ИКС Простейший пример: веб-мастер, который "устаналивает сайты" на веб-сервере, администрируемом другим человеком. С одной стороны ответственность за безопасность перекладывается со специалиста (ну, какого-никакого) на человека, который совсем не готов этим заниматься, с другой стороны, ошибки этого человека ведут к компрометации ИКС, важной для многих людей и (формально) находящейся в зоне ответственности администратора.

Таким образом, следует сформулировать следующие выводы:

1) Любые приложения, работающие с правами, имеющими доступ к ИКС (выходящей за пределы одной учётной записи) должны управляться централизовано. Даже если это неудобно. Даже если это связано с необходимостью админу лично грейдить PHPBB.

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

3) Наибольшую проблему в подобном случае доставят девелоперы ИКС. Решением проблемы может быть разделение аккаунта девелопера от аккаунта, с которым девелопер имеет доступ к ИКС. Аккаунт девелопера имеет высокую степень свободы, но при этом не имеет прав. Аккаунт доступа к "настоящей" (не тестовой) ИКС имеет права, но не имеет свободы. Делать ли две машины для двух аккаунтов или нет - вопрос отдельный. Перенос компонент ИКС из "епархии" разработчика в живую ИКС должен выполняться только администратором. Разработчик не должен иметь прав на отладку/отладочный вывод или какие-то "внештатные" операции с работающей ИКС (даже если это удобнее с точки зрения выяснения причин поломки).

Подробнее об ИКС с веб-интерфейсами. Очевидно, что разрабатывая ИКС для внутриорганизационного применения, следует ориентироваться именно на схему с организационной ИКС, но никак не на схему "личного приложения" (хотя бы потому, что ИКС используется более чем одним человеком). Отсюда вытекает "правильность" хранения конфигурации и исполняемых файлов ИКС: они должны храниться либо в специализированном месте, куда его "внедряют" при установке, либо вести себя подобно всему остальному ПО, используя типичные для ОС места хранения конфигурации, исполняемых файлов и т.д. Очевидно, что если приложение планируется обновляться средствами обновления ОС, то первый вариант не может быть принят как режим по-умолчанию, т.к. процесс обновления должен проводить обновление вне зависимости от того, является ли приложение "важным" или же нет. Нестандартное внедрение в этом случае остаётся на совести администратора и предполагает, что обслуживание его целиком и полностью выполняет администратор.
Tags: администрирование, безопасность, философия
Subscribe

  • мы их теряем!

    Make: 1976 Прямо сейчас выходят на пенсию люди, для которых make был новомодной технологией, которую притащили хипстеры.

  • Админская мудрость

    Когда вывод strace на башовый скрипт становится понятнее самого скрипта, граница разумности давно пройдена.

  • Rules of internet

    Rule 34. There is porn of it. Rule 35. It's used to mine cryptocurrencies.

  • Post a new comment

    Error

    default userpic

    Your IP address will be recorded 

    When you submit the form an invisible reCAPTCHA check will be performed.
    You must follow the Privacy Policy and Google Terms of use.
  • 3 comments