Как стать автором
Поиск
Написать публикацию
Обновить

Docker в песочнице: Запуск контейнеров без root-прав и привилегий

Уровень сложностиСредний
Время на прочтение7 мин
Количество просмотров3.4K
Java*

Приветствую всех! В своей прошлой и по совместительству первой статье я рассказывал про упаковку приложения в докер контейнеры (ссылка на нее находится в конце этой статьи). В комментариях мне сделали замечание, что я не упомянул про защиту приложения и запуск от non-root. Что ж, исправлюсь и сделаю это в отдельной статье. Напомню, что я написал простое приложение для голосование за лучший ресторан и попытался по простому объяснить, как произвести его контейнеризацию. Также уточню, что упор я делаю именно на упаковку приложения в докер контейнеры, а не на бизнес-логику и UI.

Есть несколько релизов:

Но! конкретно в этой статье речь пойдет о версии:

Запуск контейнера от непривилегированного пользователя (non-root) — это критически важный слой защиты от эксплойтов. Разберем, как это работает, на примерах и технических деталях. DeepSeek дает вот такое лаконичное определение эксплоиту:

Эксплоит — это программный код, скрипт или метод, который использует уязвимость в системе, приложении или сети для выполнения несанкционированных действий. Это может быть кража данных, получение контроля над устройством, нарушение работы системы и т.д. 

Но мы же понимаем, что лучше один раз увидеть, чем семь раз услышать. Возьмем кейс, который в идеале никогда не должен произойти в вашем приложении. Для этого вернемся к предыдущей версии проекта, а именно клонируем релиз 1.0.1 (https://github.com/codyRhett/restaurantVote/tree/release/1.0.1) 

Обратите внимание на REST контроллер UserRestController, а конкретнее на его тестовый endpoint:

 @GetMapping("/execute")
    public String executeCommand(@RequestParam("cmd") String cmd) {
        log.debug("executeCommand");
        try {
            Process process = Runtime.getRuntime().exec(cmd);
            BufferedReader reader = new BufferedReader(new InputStreamReader(process.getInputStream()));
            return reader.lines().collect(Collectors.joining("\n"));
        } catch (IOException e) {
            return "Error: " + e.getMessage();
        }
    }

В качестве RequestParam передается строка cmd, которая преобразуется в исполняемую команду. И злоумышленник может передать туда, например, команду rm -rf с указанием пути на системные файлы и спокойно удалить их, если контейнер запущен от привилегированного пользователя - root. Повторюсь:

... что ни один нормальный разработчик не сделает такого уязвимого эндпоинта.

Это я сделал чисто для примера. А способов выполнить данный скрипт много, в том числе просто зайти в контейнер через docker exec и выполнить эту команду там.

Как же это будет выглядеть?

Собираем war файл через mvn package. Далее исполняем docker-compose up и ждем пока создадутся контейнеры. После этого выполняем классический набор запросов в командной строке:

Серия запросов для демонстрации root-привилегий
Серия запросов для демонстрации root-привилегий

  • docker ps - получаем список запущенных контейнеров

  • docker exec -it 49d672f4e359 /bin/bash - заходим в командную строку нашего основного запущенного контейнера

  • cd ../ - переходим в основную директорию

  • делаем GET запрос в эндпоинт:

curl http://localhost:8080/api/user/execute?cmd=rm%20-rf%20/tmp/%20--no-preserve-root

Кстати, этот же запрос можно кинуть через браузер. Этот GET запрос передает команду rm -rf /tmp --no-preserve-root, которая удаляет папку tmp вместе с ее содержимым.

  • Далее исполняем команду ls и убеждаемся, что папки tmp больше нет. Тоже самое можно проделать с остальными папками. Думаю, не надо объяснять, почему это плохо. И вообще с большинством системных папок можем делать, что угодно - удалять, перезаписывать и т д. И все это потому, что контейнер запущен от root.

Как обезопасить себя от такого поведения?

Клонируем себе релиз 1.0.3 (https://github.com/codyRhett/restaurantVote/tree/release/1.0.3). Отличие от предыдущих релизов заключается в двух файлах - dockerfile и docker-compose.yml. Я их переписал для безопасного запуска контейнеров, чтобы усложнить задачу злоумышленников взломать наш сервис.

Начнем с того, что необходимо немного модифицировать dockerfile, чтобы наглядно продемонстрировать как работают привилегии. Приведенный ниже код демонстрирует конфигурацию для запуска от non-root:

FROM adoptopenjdk/openjdk11:ubi

# Создаем системного юзера и группу с явным UID/GID
RUN useradd -r -u 1001 appuser && \
    # создаем директорию app
    mkdir /app && \
    # Настройка прав доступа к директории /app \
    # 7 (владелец): Чтение + запись + выполнение (rwx).
    # 5 (группа): Чтение + выполнение (r-x).
    # 0 (остальные): Нет прав (---).
     chmod 750 /app && \
    # Назначение владельца директории /app
    chown appuser:appuser /app && \
    mkdir -p /app/data/logs && \
    chmod -R 750 /app/data/logs && \
    chown -R appuser:appuser /app/data/logs

# укзываем рабочую дирректорию
WORKDIR /app

# Укажите переменную окружения для пути к логам
ENV LOG_DIR=/app/data/logs

# Копируем файлы с правами
ARG WAR_FILE=target/restaurantVote-1.0-SNAPSHOT.war
# Копирование файлов с назначением владельца и группы
COPY --chown=appuser:appuser ${WAR_FILE} /app/application.war
COPY --chown=appuser:appuser src/main/webapp /app/webapp

# Явное переключение пользователя и рабочей директории
# Используем UID вместо имени. Запуск от имени нового созданного юзера
USER 1001

ENTRYPOINT ["java","-jar","/app/application.war"]

Что же тут нового и необычного?

  • Мы создаем группу и пользователя appuser и присваиваем ему идентификатор 1001

  • Даем права папкам app, где лежит исполняемый файл и app/data/logs, куда будем складывать логи (chmod - дает права доступа к файлам и директориям, chown - смена владельца папок, потому что по умолчанию владельцами папок является root)

  • Копируем файлы программы в новые папки с назначением владельца и группы

  • Явно указываем от какого пользователя осуществляем запуск контейнера USER 1001

Не буду расписывать тут подробно про то, какие бывают права. Если вкратце, то наши права зашифрованы числом 750. Первая цифра - права на владельца, вторая - на группу, третья на всех остальных. В нашем случае - 1. все права, 2. чтение+выполнение и 3. нет прав соответственно. В докер файле я привел просто пример, как можно использовать права непривилегированного пользователя. Можно создавать папки, файлы и настраивать к ним такие права доступа, какие пожелаем.

Следующий этап - это уже настройка непосредственно контейнера

Создание DOCKER-COMPOSE

Приведенный ниже код демонстрирует docker-compose.yml для безопасного запуска контейнеров

version: '2'
services:
  app:
    image: 'restaurant'
    build: .
    security_opt:
      - no-new-privileges
    cap_drop:
      - ALL
    volumes:
      - ./host_logs:/app/data/logs  # папка на хосте -> контейнер
      - app_volume:/app/data/logs
    user: "1001:1001"
    container_name: app
    ports:
      - "8080:8080"
    depends_on:
      - db
    environment:
      - SPRING_DATASOURCE_URL=jdbc:postgresql://db:5433/restaurant
      - SPRING_LIQUIBASE_URL=jdbc:postgresql://db:5433/restaurant
      - SPRING_DATASOURCE_USERNAME=postgres
      - SPRING_DATASOURCE_PASSWORD=1234
      - SPRING_JPA_HIBERNATE_DDL_AUTO=update
  db:
    image: 'postgres:latest'
    container_name: db
    build: .
    user: "999:999"
    security_opt:
      - no-new-privileges
    cap_drop:
      - ALL
    environment:
      - POSTGRES_USER=postgres
      - POSTGRES_PASSWORD=1234
      - POSTGRES_DB=restaurant
      - PGPORT=5433
volumes:
  app_volume:

На что тут стоит обратить внимание?

security_opt:
  -  no-new-privileges

Эта опция запрещает процессам внутри контейнера повышать свои привилегии (например, через sudo или su). Даже если злоумышленник получит доступ к контейнеру, он не сможет стать root.

cap_drop:
  -  ALL

Эта опция отключает все привилегии ядра Linux для контейнера.

  • Изменить владельца файлов (CAP_CHOWN).

  • Работать с сетевыми настройками (CAP_NET_ADMIN).

  • Монтировать файловые системы (CAP_SYS_ADMIN).

user: “1001:1001”

Эта опция говорит о том, что контейнер запускается от пользователя с идентификатором 1001 (которого мы создали на предыдущем шаге)

Теперь проделываем те же действия, как и для релиза 1.0.1. НО! Обязательно выполнить билд без использования кэша через команду:

docker compose build --no-cache

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

После этого запускаем контейнеры, заходим в restaurant и через команду ls -l можем видеть владельцев файлов и директорий в корне контейнера. Также через whoami можно посмотреть пользователя, от которого запущен контейнер.

Набор команд для просмотра прав и владельцев папок
Набор команд для просмотра прав и владельцев папок

Далее заходим в bash контейнера через docker exec и кидаем GET запрос на удаление папки tmp:

curl http://localhost:8080/api/user/execute?cmd=rm%20-rf%20/tmp/%20--no-preserve-root
Демонстрация обработки GET запроса при запуске контейнера от non-root
Демонстрация обработки GET запроса при запуске контейнера от non-root

Что же мы видим? Папка tmp не удалилась, потому что владельцем этой папки является root, а контейнер запущен от пользователя appuser, у которого мы сильно урезали права. Также попробуем напрямую удалить файлы из папки app.

Демонстрация удаления файла, владельцем которого является appuser
Демонстрация удаления файла, владельцем которого является appuser

Видим, что мы успешно удалили файл application.war, потому что владельцем папки является пользователь appuser, от которого и запущен контейнер.

Собственно, это все!

Итого: Если злоумышленник и зайдет в контейнер, то он сможет удалить только то, что не очень важно для нас (благодаря гибкой настройке прав). Например, как в данном случае, не сможет удалить системные файлы, владельцем которых является root.  В зависимости от ваших потребностей вы можете ставить свои ограничения, но запуск контейнера ВСЕГДА должен осуществляться НЕ от Root!

Вы спросите, а какой смысл, если пользователь, например, зайдет в контейнер из под root и вообще возможно ли такое? А я отвечу - это проблемы инфраструктуры и такого в принципе не должно быть. А запуск не от привилегированного пользователя - просто необходимая ступень защиты, которая должна усложнить жизнь злоумышленникам. И эту защиту можно обойти, но на это нужно время.

Использование appuser подразумевает, что по умолчанию в контейнере нет пользователя root, а все процессы запущены с минимальными привилегиями.

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

Docker для начинающих: простое развертывание приложения за несколько шагов

Теги:
Хабы:
+7
Комментарии7
5
Карма
7
Рейтинг
Артём @Rhett_cody

Java Developer

Отправить сообщение

Публикации

Работа

Java разработчик
178 вакансий

Ближайшие события

Ваш аккаунт

Разделы

Информация

Услуги

Техническая поддержка
© 2006–2025, Habr