МРД, systemd и "/tmp"

akaKa

New member
Сообщения
3
#1
Добрый вечер.

Имеется необходимость запуска процесса с меткой СС.
Используя PDPLabel=<Уровень>:<Целостность>:<Категории> процесс успешно запускается, но возникает проблема с сохранение данных в папку /tmp с любой меткой процесса отлиной от НС.

Конфигурация сервиса следующая:
Bash:
[Unit]
Description=test service
After=network.target

[Service]
PDPLabel=3:63:0
Type=simple
TimeoutStopSec=600
ExecStart=/usr/local/bin/CreateTempFile
User=ssuser
Group=ssuser

[Install]
WantedBy=multi-user.target
При старте сервиса получаем следующую картину:

Bash:
root@astra:/etc/systemd/system# service mytest start && tailf /var/log/daemon.log
Oct  9 18:11:53 astra systemd[1]: Reloading.
Oct  9 18:11:53 astra systemd[1]: anacron.timer: Adding 4min 4.701180s random time.
Oct  9 18:11:53 astra systemd[1]: apt-daily-upgrade.timer: Adding 11min 21.833660s random time.
Oct  9 18:11:53 astra systemd[1]: apt-daily.timer: Adding 4h 57min 35.101650s random time.
Oct  9 18:11:58 astra systemd[1]: Started test service.
Oct  9 18:11:58 astra CreateTempFile[4034]: Произошла ошибка при создании файла:: /tmp/test_rtNt0K.log

root@astra:/etc/systemd/system# systemctl status mytest.service
● mytest.service - test service
   Loaded: loaded (/etc/systemd/system/mytest.service; disabled; vendor preset: enabled)
   Active: active (running) since Fri 2020-10-09 18:11:58 MSK; 18s ago
Main PID: 4034 (CreateTempFile)
    Tasks: 1 (limit: 4915)
   CGroup: /system.slice/mytest.service
           └─4034 /usr/local/bin/CreateTempFile

окт 09 18:11:58 astra systemd[1]: Started test service.
окт 09 18:11:58 astra CreateTempFile[4034]: Произошла ошибка при создании файла:: /tmp/test_rtNt0K.log
root@astra:/etc/systemd/system# pdpl-ps 4034
4034 Уровень_3:Высокий:Нет:0x0!Нет:Нет
root@astra:/etc/systemd/system# pscaps 4034
00000000 00000000 00000000
При использовании низкого контроля целостности ситуация аналогичная:

Bash:
root@astra:/etc/systemd/system# service mytest start && tailf /var/log/daemon.log
Oct  9 18:16:20 astra systemd[1]: Reloading.
Oct  9 18:16:20 astra systemd[1]: anacron.timer: Adding 3min 3.701612s random time.
Oct  9 18:16:20 astra systemd[1]: apt-daily-upgrade.timer: Adding 59min 56.275189s random time.
Oct  9 18:16:20 astra systemd[1]: apt-daily.timer: Adding 11h 27min 37.902184s random time.
Oct  9 18:16:24 astra systemd[1]: Started test service.
Oct  9 18:16:24 astra CreateTempFile[4189]: Произошла ошибка при создании файла:: /tmp/test_r4oJSE.log

root@astra:/etc/systemd/system# systemctl status mytest.service
● mytest.service - test service
   Loaded: loaded (/etc/systemd/system/mytest.service; disabled; vendor preset: enabled)
   Active: active (running) since Fri 2020-10-09 18:16:24 MSK; 8s ago
Main PID: 4189 (CreateTempFile)
    Tasks: 1 (limit: 4915)
   CGroup: /system.slice/mytest.service
           └─4189 /usr/local/bin/CreateTempFile

окт 09 18:16:24 astra systemd[1]: Started test service.
окт 09 18:16:24 astra CreateTempFile[4189]: Произошла ошибка при создании файла:: /tmp/test_r4oJSE.log
root@astra:/etc/systemd/system# pdpl-ps 4189
4189 Уровень_3:Низкий:Нет:0x0!Нет:Нет
root@astra:/etc/systemd/system# pscaps 4189
00000000 00000000 00000000
Корректно сервис работает только с нулевой меткой:

Bash:
root@astra:/etc/systemd/system# service mytest start && tailf /var/log/daemon.log
Oct  9 18:17:47 astra systemd[1]: Reloading.
Oct  9 18:17:47 astra systemd[1]: anacron.timer: Adding 2min 42.340808s random time.
Oct  9 18:17:47 astra systemd[1]: apt-daily-upgrade.timer: Adding 12min 16.089777s random time.
Oct  9 18:17:47 astra systemd[1]: apt-daily.timer: Adding 5h 18min 54.408982s random time.
Oct  9 18:17:52 astra systemd[1]: Started test service.

root@astra:/etc/systemd/system# systemctl status mytest.service
● mytest.service - test service
   Loaded: loaded (/etc/systemd/system/mytest.service; disabled; vendor preset: enabled)
   Active: active (running) since Fri 2020-10-09 18:17:52 MSK; 9s ago
Main PID: 4277 (CreateTempFile)
    Tasks: 1 (limit: 4915)
   CGroup: /system.slice/mytest.service
           └─4277 /usr/local/bin/CreateTempFile

окт 09 18:17:52 astra systemd[1]: Started test service.
root@astra:/etc/systemd/system# ^C
root@astra:/etc/systemd/system# pdpl-ps 4277
4277 Уровень_0:Низкий:Нет:0x0!Нет:Нет
root@astra:/etc/systemd/system# pscaps 4277
00000000 00000000 00000000
Как я понимаю, независимо от уровня секретности запускаемого процесса, создать файл он пытается в папке /tmp с НС меткой.

На данный момент я вижу 2 варианта решения проблемы:
  • Принудительно при старте сервиса назначать папке /tmp уровень секретности СС;
  • Неиспользовать указание User и Group в описание сервиса, что вызовет его выполнение от root'а.
P.S. Использование PrivateTmp=yes желаемого результата не принесло.

Возможны ли иные пути решения проблемы?

Upd. Используется Astra 1.6 Update 6
 
Последнее редактирование:

oko

New member
Сообщения
1 257
#2
to akaKa
Могу ошибаться, но, вроде, вне зависимости от представления всего в *nix "as file", МРД различает сущности "файл" и "каталог". И попытка писать файл с X меткой в каталог с <X меткой закономерно приводит к ошибке...
Создайте каталог (явно не корневой /tmp, потому что туда пишут все сервисы с разной степнью тяжести) и назначьте ему метку 2 уровня, а сервис перенаправьте в этот каталог и проверьте...
 

akaKa

New member
Сообщения
3
#3
to akaKa
Могу ошибаться, но, вроде, вне зависимости от представления всего в *nix "as file", МРД различает сущности "файл" и "каталог". И попытка писать файл с X меткой в каталог с <X меткой закономерно приводит к ошибке...
Создайте каталог (явно не корневой /tmp, потому что туда пишут все сервисы с разной степнью тяжести) и назначьте ему метку 2 уровня, а сервис перенаправьте в этот каталог и проверьте...
Путей решения много. Меня больше интересует, почему даже с случае использования изолированной папки /tmp (PrivateTmp=yes) у процесса с СС меткой, папка /tmp в окружении процесса имеет метку секретности НС. Но в случае запуска процесса от пользователя root и использовании PrivateTmp=yes все работает корректно, файл создается в изолированном окружении. Как я понимаю процессу не хватает какой-то привелегии, все привелегии пользователя root наследовать я не вижу необходимости. В случае запуска приложения(не сервиса) из сессии пользователя все работает корректно, независимо от уровня секретности, проблема именно с запуском сервиса, с меткой отличной от НС.

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

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

oko

New member
Сообщения
1 257
#4
to akaKa
Очевидно, изоляция /tmp (и, например, /home/%username%) для systemd-сервиса не поддерживается...
Поиграл с вашим сервисом и простым скриптом echo > file - каталогу, куда будет писать сервис, либо заранее требуется присвоить нужную мандатную метку, либо использовать флаг ehole...
 

akaKa

New member
Сообщения
3
#5
to akaKa
Очевидно, изоляция /tmp (и, например, /home/%username%) для systemd-сервиса не поддерживается...
Поиграл с вашим сервисом и простым скриптом echo > file - каталогу, куда будет писать сервис, либо заранее требуется присвоить нужную мандатную метку, либо использовать флаг ehole...
Изоляция поддерживается, при условии запуска с привилегиями root’a, для примера попробуйте закомментировать строки User =... Group =... будет корректно работать пример.А вот метка изолированного каталога под вопросом. В принципе это решение проблемы, но получается у сервиса избыток привилегий.
 

oko

New member
Сообщения
1 257
#6
to akaKa
Благодарю, буду знать. Но что-то мне подсказывает, что такое поведение сервиса - скорее исключение (для root), чем правило (в части поддержки изоляций). В конце концов, root тем и отличается, что не должен иметь ограничений. Например, ничего не мешает из-под юзера с 0:63:0 через sudo или su читать файл с 2:63:1...