Наша очень крупная организация разработала стандарт для размещения приложений, согласно которому приложение и все компоненты, на которых оно основано, должны находиться в выделенном томе приложения, отличном от самой операционной системы. Например, если приложение написано на Perl, мы требуем, чтобы отдельный экземпляр Perl поддерживался в томе приложения.
Причина этого заключается в том, что те компоненты, на которые полагаются как ОС, так и приложение, могут иметь и часто имеют конфликтующие требования к версии, а принуждение приложения к поддержанию собственных ресурсов значительно упрощает исправление ОС. Кроме того, он гарантирует, что данные и журналы приложений не попадут в места, где находятся инструменты на основе ОС (это особенно важно, например, в отношении httpd).
Более того, если нет веской и документированной технической причины, процессы приложения должны выполняться как непривилегированный пользовательский идентификатор, а не как root. У нас есть обходные пути в Linux, чтобы такие процессы, как веб-серверы, можно было запускать от имени непривилегированного пользователя и принимать соединения, перенаправленные с привилегированных портов (80 и 443) на непривилегированные порты, которые они прослушивают.
Например, я профессионал в области безопасности в Unix / Linux SA в своей компании, и я тесно сотрудничаю со специалистами технической поддержки платформы, чтобы поддерживать и обеспечивать соблюдение стандартов, которые я изложил выше. Большая часть моих обязанностей - это проверка запросов на привилегированный доступ через sudo, которые управляются централизованно. Наш стандартный Linux - это Red Hat, но Ubuntu и CentOS также рассматриваются для облачных сред.
Проблема в том, что в настоящее время нас засыпают запросами от команд разработчиков приложений, чтобы разрешить им (через sudo) устанавливать приложения Linux с помощью rpm и yum, поскольку производители требуют этого и не могут предоставить никаких альтернативных средств для установки приложений. Это противоречит нашим стандартам по нескольким причинам:
Инструменты rpm и yum должны запускаться с правами суперпользователя. Это означает, что все, что они делают, работает от имени пользователя root, поэтому полученную установку часто приходится настраивать постфактум, чтобы позволить ей запускаться от имени непривилегированного пользователя.
В пакетах часто указывается, что компоненты должны быть установлены в корневом томе, а не в указанном томе. Там, где можно указать корень дерева пакетов, часто производители настаивают на том, чтобы он оставался неизменным, поскольку они тестировали его только в той среде, которая указана в пакетах.
Наконец, rpm и yum извлекают зависимости из любого репозитория, доступного системе, и хотя нам требуется, чтобы приложения использовали наш репозиторий Satellite для всего, что доступно в Red Hat, часто поставщики предоставляют свои собственные репозитории, которые должны быть включены для работы программного обеспечения.
У меня вопрос, как указать или ограничить использование rpm и yum в такой среде, чтобы гарантировать, что конфликты пакетов не возникают и исправления безопасности системы могут быть безопасно применены, при этом не запрещая использование этих инструментов для прикладного программного обеспечения в целом ( что мы делали до сих пор и обнаружили, что это бесполезное упражнение)?
Прежде чем перейти к решениям, несколько слов о стандартах безопасности вашей компании. Проще говоря, с ними очень сложно работать, и они настолько устарели, что почти не имеют значения.
Очевидно, почему с ними сложно работать, поэтому я не буду больше об этом говорить.
Что касается устаревания, очевидно, что они не принимают во внимание современные технологии, такие как виртуализация, возможности Linux, контейнеры, SELinux и т. Д., Которые помогают решать те же проблемы безопасности в гораздо более элегантном виде. и пригодный способами.
Например, привязка httpd к высокому порту и последующее перенаправление на него трафика с помощью iptables вместо того, чтобы просто позволить ему привязать и затем отбросить привилегии, как это происходит по умолчанию, граничит с паранойей и практически ничего не дает. Это также усложняет использование SELinux с httpd, поскольку такая настройка не предусматривалась при разработке политики httpd SELinux.
Точно так же, просто слепо требуя, чтобы пакеты запихивались в /opt или /usr/local ничего вам не даст, так как RPM уже поддерживает требуемое разделение независимо от того, где установлены пакеты (если пакет не сломан, что может иметь место с пакетами сторонних поставщиков, но они откажутся от установки) и теряет соответствие стандартам, возможно, делая соответствующие политики SELinux непригодны для использования и создают кошмар для обслуживания. Коллекции программного обеспечения Red Hat разработан в соответствии с этими принципами, и хотя у него есть некоторые проблемы с удобством использования, создание собственных пакетов по этому дизайну может быть временной мерой, пока вы работаете над реальными проблемами.
Однако самая большая проблема, которую я вижу, - это поддержка «большого железного» сервера или серверов, на которых все приложения работают бок о бок. Уже одно это вносит свои собственные проблемы безопасности, которые, вероятно, являются источником этих «практик безопасности». Виртуализация на данный момент достаточно развита и просто разделяет приложения на их собственные виртуальные машины, например с участием KVM на RHEL 6 или RHEL 7, воля устранить необходимость для большинства этих «методов безопасности».
Таким образом, поскольку у вас почти наверняка очень много приложений, создание частного облака с OpenStack вероятно, будет вашим лучшим выбором в краткосрочной и среднесрочной перспективе. Они будут использовать хосты RHEL 7 и запускать RHEL 7, 6 и, возможно, даже 5 гостей, поскольку у вас, вероятно, есть группа тех, кто еще жив и здоров. Это также даст вам платформу для безопасных экспериментов с новыми приложениями и операционными системами, а также упростит распределение ресурсов по бизнес-подразделениям, отделам и т. Д.
Если виртуализация слишком тяжелая для некоторых вещей, переходите к контейнерам (например, LXC / Docker на RHEL 7). Они намного легче и могут быть разделены практически только до самого пакета приложения, а затем изолированы с их собственной файловой системой, сетью и пространствами имен uid / gid, эффективно отрезая их от любого другого контейнера, кроме того, что вы случайно открыли в соответствующие межсетевые экраны. Добавление SELinux к виртуальным машинам KVM или контейнерам Linux обеспечивает второй уровень защиты и может быть включен одним щелчком мыши.
Кроме того, в вашей компании полно разработчиков, которые будут любить вас вечно, если вы начнете предлагать им OpenStack и / или Docker.
Короче говоря, пришло время оценить современные дистрибутивы Linux и возможности, которые они предоставляют, и пересмотреть все методы обеспечения безопасности в свете этих возможностей.
Что касается лицензирования, Red Hat теперь предлагает неограниченное количество лицензий на виртуализацию, позволяя запускать неограниченное количество виртуальных машин / контейнеров RHEL, и, конечно же, есть CentOS, которая заменяет RHEL примерно в 99,9% случаев. Так что здесь нет оправдания.
Самый общий ответ на ваш вопрос - «нет». Во время установки yum / rpm необходимо записать в корневую привилегированную папку.
Обычно все двоичные пакеты скомпилированы для использования на системном уровне. Вы можете использовать псевдооболочки или псевдооболочки для создания сред типа chroot и установки программного обеспечения в их домашнем пространстве.
Как сказал Марк, развертывание собственных пакетов RPM будет подходящим решением для текущего сценария.
Есть несколько ссылок, чтобы посмотреть
https://unix.stackexchange.com/questions/134181/building-rtmpdump-on-rhel-x86-without-yum-and-no-root-rights http://www.linuxquestions.org/questions/linux-software-2/can-i-run-yum-without-root-privileges-592939/ http://yum.baseurl.org/wiki/RunningWithoutRoot