Назад | Перейти на главную страницу

После изменения марионетка теперь запускается как пользователь «ubuntu», и auditd нервничает.

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

У меня несколько систем Ubuntu 14.04, работающих в AWS EC2.

У нас есть несколько VPC, предназначенных для разных целей - prod / qa / dev / etc

Я бегаю марионеткой с кукловодом. Довольно стандартно. За исключением того, что изначально у нас был один марионеточный мастер, который обрабатывал конфигурацию для всех узлов во всех VPC.

Недавно я перенес puppetmaster в отдельный puppetmaster, для каждого VPC. Но конфигурация - то есть манифесты марионетки, модули и т. Д. - была скопирована дословно. Таким образом, все хосты должны по-прежнему получать одинаковые определения узлов от марионетки. Со временем это может дрейфовать, но на момент отсечки марионеточные мастера были настроены идентично.

Я запускаю auditd для всех из них с правилами, которые проходят через идентификатор пользователя «audit» - «auid» - всякий раз, когда одно sudo обращается к другой учетной записи. Правила auditd установлены на «неизменяемые» - для изменения действующих правил им требуется перезагрузка.

Пример:

$my-laptop# ssh fred@web.example.com   # "fred"'s uid is 9999 in this example
web.example.com# sudo su -
web.example.com$ grep config_item /etc/ -r

Этот тип событий будет отображаться в audit.log как что-то вроде

type=SYSCALL msg=audit(1457613844.394:1234567): arch=c000003e \
 syscall=59 success=yes exit=0 ppid=1234 pid=5678 auid=9999 \
 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 \
 tty=(none) ses=51 comm="expr" exe="/bin/grep" key="sudo-command"

(Я разбил эту однострочную запись журнала на несколько строк, чтобы ее было легче читать)

В любом случае, пользователь Ubuntu по умолчанию в EC2 Ubuntu 14.04 AMI - это «ubuntu» с UID 1000. Я вижу тонну сообщений с «auid = 1000» в них.

Изменение, вызвавшее эту проблему, состоит в том, что я перенес Puppetmaster с одного VPC на другой и изолировал марионеточные агенты, чтобы они разговаривали только с puppetmaster в их VPC.

Похоже, что перезагрузка решает эту проблему.

Есть ли какое-то состояние гонки или другая ситуация, когда auditd видит неправильный идентификатор auid?

Что-нибудь, что угодно, идеи или мысли. Я сбит с толку.

А пока все перезагружаю.

Возможно, AWS EC2 выполняет какую-то базовую управленческую деятельность через этого пользователя ubuntu.

Для начала выясните, какие команды выполняет пользователь auid = 1000 (также известный как ubuntu). Включите на время мониторинг системных вызовов execve, чтобы при необходимости получить дополнительную информацию, согласно -a exit,always -F arch=b64 -S execve -k cmds