Чем писать действия пользователя в Linux?

Question

[Иван Гуменюк]

Есть виртуальные машины с Red Hat Enterprise Linux 7. Текущий DE - Gnome3. К ним подключаются удаленно с рабочего места для обработки чувствительных данных. Они находятся в изолированном, контролируемом окружении. Нельзя допустить утечки этих данных на физическую машину пользователя.

Задача:
Чем писать лучше действия пользователя на виртуальной машине? Нужно писать в том или ином виде X11 и по возможности дополнительно в виде логов мониторить действия. Предпочтительно свободное ПО.

UPD:
Вполне вероятно, что более оптимально будет делать скриншоты в ч/б с хорошим сжатием и отправлять их на отдельный сервер.

Answer 1

[Дмитрий Александров]

Если надо скриншотами то вперед писать скрипт, тут ничего сложного.
Другой вопрос что за данные такие, если это некая программа то может порезать права пользователя и не загружая dm сразу запускать эту программу?
Если же dm нужен то можно сделать отдельного пользователя для работы этой программы и связанных с ней каталогов. У юзверя ярлык на запуск проги, сам скрипт запуска только на чтение и выполнение, текущему пользователю полный запрет на rwx в каталоге програмки.

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

Comments

[Иван Гуменюк]

Нет, там по условиям задачи полноценное окружение для разработчика. Но для мониторинга обязательна запись пользователя.
Интернета там нет, USB нет. Это не проблема. Ключевая задача именно запись происходящего. Чем кошернее дергать скриншоты? Я предполагаю черно-белый png раз в пару секунд лить на внешний сервер, а там уже аналитику прикручивать.

[Дмитрий Александров]

Иван Гуменюк, если нет интернета и нет usb то собственно как предполагается что пользователь сможет унести секретные данные?

[Tom Nolane]

Дмитрий Александров, скопировать в мозг через глаза)

[CityCat4]

Дмитрий Александров, снять на камеру смартфона. Но это не зафиксировать :) разве только смартфоны у всех отбирать. Это кстати вовсе не шутка - я еще в нулевых в оборонке работал, там сотрудники некоего отдела утром сдавали смартфоны, вечером получали...

[Дмитрий Александров]

CityCat4, как режимка работает я знаю не по наслышке. Имел счастье поработать в таком месте году в 2012, на входе металодетектерные рамки, сдается все в коробочку и на полку у охраны, дальше под роспись в журнал, комп на МСВС. Все права порезаны, один из интересных моментов там был в компах. Весь userspace работал в overlayfs который мапился в озу, любое подключение usb девайсов сразу требовало повышенных прав в системе, если была необходимость сохранения то опять же повышенные права на специальную флешку, флешка берется и сдается под роспись у специально человека на посту, флешка тоже не простая, сделанная на заказ с хардварным шифрованием и работать будет только на том же ПК. Бэкапы этих флешек делал специально обученный секретчик на другой носитель.
Короч жесть во всех смыслах, чтобы банально напечатать текст и сохранить его уже 9 кругов ада, если требовалось еще и распечатать то мук еще больше.

[Иван Гуменюк]

Дмитрий Александров, требование ИБ)

[Дмитрий Александров]

Иван Гуменюк, требования ИБ это писать экран? Как вариант можно еще делать не скриншоты а писать видео но сделать 1 фпс в нем =)

[Иван Гуменюк]

Дмитрий Александров, можно. Но тут вопрос CPU и сети.

[Дмитрий Александров]

Иван Гуменюк, с 1 к\с CPU скорее всего будет даже проще чем делать скриншоты и в конечном счете как итог сам файл будет легче из за алгоритмов сжатия в видео. Сеть да, тут придется думать так же как и со скришотами. Как вариант начинать писать экран при логине пользователя а при выходе останавливать запись и выгружать куда надо.

[Иван Гуменюк]

Что-то вроде такого получилось:
#!/bin/bash
while :
do
curDate=$(date +'%Y-%m-%d.%H-%M-%S')
imgName=$curDate.$USER.png
imgSaveDir="~/screenshot/"
imgSaveFullPath=$imgName
#xwd -root -silent | convert xwd:- -colorspace Gray -colors 16 -trim PNG8:$imgSaveFullPath
xwd -root -silent | convert xwd:- -colorspace Gray -colors 16 -trim PNG8:$imgSaveFullPath
echo "Iteration $i done"
done
echo "test done"

Но процессор зверски грузит.

[Дмитрий Александров]

Иван Гуменюк, может не стоит цикл делать, а дергать скрипт по крону.

[Иван Гуменюк]

Дмитрий Александров, здесь цикл исключительно с целью нагрузочного тестирования. Даже без преобразования скрина в черно-белую картинку оно жручее. Под сотню процентов ест. Неприемлемо для рабочей станции.

[Дмитрий Александров]

Иван Гуменюк, скорее всего жрется проц изза конвертации в png. Попробуй напрямую дампить.
к примеру xwd -root -silent -out cap.xwd чтобы сделать дамп.
сам дамп потом отдельно уже перегони в png. типа так mogrify -format PNG -path ./pngs cap.xwd

По идее сам дамп экрана будет очень быстрый, особенно если дампить будешь не на хард а скажем в tmpfs\ramfs и т.д.

[Дмитрий Александров]

Еще scrot можно попробовать.

[Иван Гуменюк]

Дмитрий Александров, оно жрет даже если сразу в /dev/null отправлять. Сам процесс очень агрессивно ресурсы потребляет.

Answer 2

[Иван Гуменюк]

Я думаю использовать в cron imagemagick с сохранением в некий ограниченный буфер. Потом через rsync на удаленный сервер по ssh. Тут только еще вопрос встает. Пользователь не должен иметь прав потушить скрипт. И скрипт должен работать в его графическом окружении.

Comments

[Валентин]

Права потушить у него будут, т.к. скрипт придется от этого пользователя и запускать. Но это не проблема - не надо делать скрипт, который висит в памяти. Надо делать такой, который снимет скриншот, отправит его и убьется. А на systemd повесить задачу его запуска. Есть там таймеры, можно сделать таймер на, к примеру, "30 секунд после умирания". Таким образом, во-первых, тяжело отследить сам момент скрипта - 1-2 секунды ему на всё про всё надо, во-вторых - конфигурять systemd без sudo уже не выйдет, так что пользователь не отключит таймер.

[Иван Гуменюк]

Валентин, отличная мысль, спасибо.