Параноя... Обнаружил у себя на жестком диске логи своей консоли

Проверил у себя, ничего подозрительного не обнаружено. Только почта, море не прочтенной почты с отсчетами :3
[fat]Это все Гугл хром очевидно же

находит логи, ага

/tmp в памяти?

нет, на одном разделе с /

ложная тревога?

Дайте угадаю: у всех нашедших логи /tmp на диске, а не в tmpfs?

Понимаешь ли.
Даже если это так то это все равно невероятного размера баг, это раз.
Т.к в /tmp не должна помещаться настолько важная информация как полные (!) логи юзера.
Во вторых я уже переместил /tmp в память, перезагрузил комп.

А теперь я могу найти свои логи того, что я только что делал в консоли от рута.

Ещё интересный момент: моя корневая система на SSD.

Сначало прочитал:

с:/

Ну и не ответил.

Я не думал, что дело только в /tmp, тут все намного глубже зарыто.
Сейчас перезагружусь ещё разик для чистоты эксперимента.

Даже если это так то это все равно невероятного размера баг, это раз.
Т.к в /tmp не должна помещаться настолько важная информация как полные (!) логи юзера.

Даже если перехватить дескриптор файла, пока он не удалён, к нему наверняка всё равно никто, кроме самого пользователя, не имеет доступа. В чем баг?

Но найти, кто пишет эти файлы, конечно, очень интересно. Т.к. это крайне необычно.

Во вторых я уже переместил /tmp в память, перезагрузил комп.
А теперь я могу найти свои логи того, что я только что делал в консоли от рута.

А что находится на том разделе, откуда ты их грепаешь? Я имею ввиду — из доступных на запись каталогов.

Да, если кому интересно:
Находит НЕ только локальные логи bash, но и логи работы на ssh.

Находится корень, исключая /var /home и /tmp (теперь).

Вообще у меня на ноуте корневая ФС шифрована, и на старом компе тоже.
А здесь я поленился и не сделал, больше никогда не буду ленится шифроваться.

В чем баг?

Баг в том, что у меня директория пользователя шифрованная.
А эти логи пишутся непонятно кем и куда.

swap в новых убунтах по дефолту идет зашифрованный, например. И шифруется он одноразовым ключем.

если, что у меня даже свап в файле и серовно ничего не находит подозрительного.

Находится корень, исключая /var /home и /tmp (теперь).

Мистика какая-то. Я начинаю верить в неведомых руткитов и черную магию.

Ну это очевидно потому, что у тебя достаточно оперативки :)
Вот например в swap файле playstation 3 была куча всего интересного...

Ну по поводу логов рута: my bad, это не то, это просто был bash_history рута который лежит там где должен лежать.
В общем /tmp унесено подалее в оперативку, поэтому завтра я смогу проверить нет ли ничего новенького на диске.

Ну и надо посмотреть что баш мог писать в /tmp.

консоль хранит весь вывод (он ведь легко проматывается назад при необходимости) причем именно весь. возможно для экономии оно делает это на диск.

Это логично, вопрос в том что strace для баша не дает никаких намеков на то, что оно делает это на диск :)

это делает не баш, это делает xterm

Пока собираю дамп обращений к диску через blktrace, но предварительный вывод - гадит именно gnome-terminal. В его открытых файловых дескрипторах много треша в /tmp:

router@amalthea:~$ ls -l /proc/2791/fd/
итого 0
lr-x------ 1 router router 64 Дек 28 22:16 0 -> /dev/null
lrwx------ 1 router router 64 Дек 28 22:16 1 -> /home/router/.xsession-errors
lr-x------ 1 router router 64 Дек 28 22:16 10 -> pipe:[13614]
l-wx------ 1 router router 64 Дек 28 22:16 11 -> pipe:[13614]
[...]
lrwx------ 1 router router 64 Дек 28 22:16 2 -> /home/router/.xsession-errors
lrwx------ 1 router router 64 Дек 28 22:16 20 -> /dev/ptmx
lrwx------ 1 router router 64 Дек 28 22:16 21 -> /tmp/vteP4U66V (deleted)
lrwx------ 1 router router 64 Дек 28 22:16 22 -> /tmp/vteY0U66V (deleted)
lrwx------ 1 router router 64 Дек 28 22:16 23 -> /tmp/vteYXU66V (deleted)
lrwx------ 1 router router 64 Дек 28 22:16 25 -> /tmp/vteTW3R6V (deleted)
lrwx------ 1 router router 64 Дек 28 22:16 26 -> /tmp/vte6UES6V (deleted)
lrwx------ 1 router router 64 Дек 28 22:16 27 -> /tmp/vteCTES6V (deleted)
lrwx------ 1 router router 64 Дек 28 22:16 28 -> /tmp/vteSP596V (deleted)
lrwx------ 1 router router 64 Дек 28 22:16 29 -> /tmp/vteXK596V (deleted)

Похоже, что гадят любые терминалы, использующие vte:

$ strace terminal |& grep 'tmp'
connect(3, {sa_family=AF_FILE, path=@"/tmp/dbus-qzIVGC3jsS"}, 23) = 0
connect(4, {sa_family=AF_FILE, path=@"/tmp/.X11-unix/X0"}, 20) = 0
getpeername(4, {sa_family=AF_FILE, path=@"/tmp/.X11-unix/X0"}, [20]) = 0
connect(6, {sa_family=AF_FILE, path=@"/tmp/dbus-qzIVGC3jsS"}, 23) = 0
open("/tmp/vteBCKV6V", O_RDWR|O_CREAT|O_EXCL|O_LARGEFILE, 0600) = 13
unlink("/tmp/vteBCKV6V")                = 0
open("/tmp/vte0TJV6V", O_RDWR|O_CREAT|O_EXCL|O_LARGEFILE, 0600) = 13
unlink("/tmp/vte0TJV6V")                = 0
open("/tmp/vteUQIV6V", O_RDWR|O_CREAT|O_EXCL|O_LARGEFILE, 0600) = 13
unlink("/tmp/vteUQIV6V")                = 0
write(15, "/etc/tmpfiles.d\n", 16)      = 16
open("/tmp/vteNA196V", O_RDWR|O_CREAT|O_EXCL|O_LARGEFILE, 0600) = 13
unlink("/tmp/vteNA196V")                = 0
open("/tmp/vte7B096V", O_RDWR|O_CREAT|O_EXCL|O_LARGEFILE, 0600) = 13
unlink("/tmp/vte7B096V")                = 0

xterm и urxvt не гадят.

мда, а ведь ты прав...
Правда ничего особенного не происходит т.к пишет он в /tmp.

lsof выдал целую кучку файлов которые он открыл.
И там куча таких:
/tmp/vte2MH26V
/tmp/vteVX3Y6V

Интересно, с какими правами создаются эти файлы...

Параноя... Обнаружил у себя на жестком диске логи своей консоли (комментарий)

0600

Уже понял.
Да и файла по сути не существует, только его дескриптор, если я правильно все это понимаю.
Так или иначе это намек на то, что диск надо всегда шифровать целиком, ибо...

А через любой дескриптор можно обратиться к файлу, используя /proc :

$ ls -l /proc/`pgrep terminal`/fd/
итого 0
lrwx------ 1 vadim vadim 64 дек.  29 02:46 0 -> /dev/null
lrwx------ 1 vadim vadim 64 дек.  29 02:46 1 -> /dev/null
l-wx------ 1 vadim vadim 64 дек.  29 02:46 10 -> pipe:[135666]
lrwx------ 1 vadim vadim 64 дек.  29 02:46 11 -> socket:[307070]
lrwx------ 1 vadim vadim 64 дек.  29 02:46 12 -> /tmp/vteP6H46V (deleted)
lrwx------ 1 vadim vadim 64 дек.  29 02:46 13 -> /tmp/vte32H46V (deleted)
lrwx------ 1 vadim vadim 64 дек.  29 02:46 14 -> /tmp/vte6VH46V (deleted)
lrwx------ 1 vadim vadim 64 дек.  29 02:46 15 -> /tmp/vteD6T96V (deleted)
lrwx------ 1 vadim vadim 64 дек.  29 02:46 16 -> /tmp/vteN1T96V (deleted)
lrwx------ 1 vadim vadim 64 дек.  29 02:46 17 -> socket:[499760]
lrwx------ 1 vadim vadim 64 дек.  29 02:46 18 -> /tmp/vteCLW76V (deleted)
lrwx------ 1 vadim vadim 64 дек.  29 02:46 19 -> /tmp/vte0LW76V (deleted)
lrwx------ 1 vadim vadim 64 дек.  29 02:46 2 -> /dev/null
lrwx------ 1 vadim vadim 64 дек.  29 02:46 20 -> /tmp/vteR1V76V (deleted)
lrwx------ 1 vadim vadim 64 дек.  29 02:46 3 -> socket:[135016]
lrwx------ 1 vadim vadim 64 дек.  29 02:46 4 -> anon_inode:[eventfd]
lrwx------ 1 vadim vadim 64 дек.  29 02:46 5 -> socket:[135630]
lrwx------ 1 vadim vadim 64 дек.  29 02:46 6 -> /dev/ptmx
lrwx------ 1 vadim vadim 64 дек.  29 02:46 7 -> /dev/pts/8
lrwx------ 1 vadim vadim 64 дек.  29 02:46 8 -> socket:[135632]
lr-x------ 1 vadim vadim 64 дек.  29 02:46 9 -> pipe:[135666]

Ну так или иначе читать эту информацию может только тот у кого права есть.
Но подход к хранению временной информации очень странный...

Да, с blktrace я немного промахнулся :) Даёт много информации, но от полученного номера блока к pid'у я так и не дошёл. strace в этом случае оказался гораздо полезнее

Странный - мягко говоря. Мечта фбр. Кто-то из подобных контор однозначно коммитил код :D

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

Получается, единственный выход - выносить /tmp в память

Теперь самое интересное заключается в том, какой сакральный смысл был хранении хистори таким уникальным методом :)

Смысл - чтоб не выпендривались со своей кулхацкерской осью. Надо будет - правильные парни прочитают диск и нежно ухватят за МТС

Кто запилит отчёт в багтрекер своего дистрибутива? Ну и новость на opennet, а то мужики-то не знают

Ну в убунтовском багтрекере примерно оно есть:
https://bugs.launchpad.net/ubuntu/ source/vte/ bug/778872

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

какой командой? какой оффсет?

dd, 284633.

Я имел ввиду всю команду целеком и оффсет в байтах... Ты же говоришь 0 блоков — значит что-то не так написал

Только несколько блоков снял при помощи dd, вот что получилось

Видимо ошибка в команде. Или как вариант пробуй пропускать через strings

А теперь я могу найти свои логи того, что я только что делал в консоли от рута.

Какой эмулятор терминала?

А через любой дескриптор можно обратиться к файлу, используя /proc

Так ты пробовал посмотреть содержимое этих файлов (вроде через /proc можно восстанавливать открытые удалённые файлы)? Это действительно логи или нет?

gnome-terminal
Но запускаемый через питоновский terminator.

Да это действительно полный вывод консоли.
Оно создает эти файлы, получает их дескриптор, и моментально удаляет.
Но продолжает в них писать и читать их через дескриптор.

Как и написано выше:
ls -lia /proc/[PID]/fd/
Сможешь увидеть весь список файлов куда в текущий момент пишет терминал.

Оно создает эти файлы, получает их дескриптор, и моментально удаляет.

Но зачем? Было бы логичней создавать их в /tmp/vte и удалять при завершении программы.

Хотя может быть это они для того что бы если прогу убьют через kill -9, в /tmp не осталось мусора?

Хотя может быть это они для того что бы если прогу убьют через kill -9, в /tmp не осталось мусора?

Да. Вероятнее всего.

Но зачем вообще это делать? Есть же оперативка...

Вот что нагуглил:

http://ubuntuforums.org/showthread.php?t=1830432

Так что не я первый обнаружил.

Самый юмор в том, что с этой «фичей» любая программа без проблем будет шпионить за терминалом, просто поключившись через tail -f к дескриптору в /proc/<pid>/fd/. Тут даже перенос в tmpfs не поможет.

Пора изучать selinux

Тут даже перенос в tmpfs не поможет.

Зато поможет неиспользование терминалов на vte плюс запуск каждой программы от отдельного юзера...

плюс запуск каждой программы от отдельного юзера...

Как ты себе это представляешь? Может ещё на QubesOS перейти? :)

Может ещё на QubesOS перейти? :)

Почему так негативно настроен к идее?
Тебе часто надо руками лезть в конфиги IM клиента, браузера.
Часто надо их копировать?

Я вот какое то время сидел на системе, где каждый браузер работает в своем chroot окружении.
Несколько месяцев назад осилил Apparmor для всех сетевых преложений и рад.
Ничего не глючит, не тормозит, и не имеет право читать/писать никуда кроме заданных мной директорий.

Как ты себе это представляешь? Может ещё на QubesOS перейти? :)

Ну хотя бы браузер можно запускать от отдельного юзера, плюс IM-клиенты.

В общем, те, которые работают с интернетом.

Может ещё на QubesOS перейти? :)

А почему нет?

MAC — это хорошо. По юзеру на каждую аппликуху — это не нужно.

linux-1cxy:/home/mopsene # dd if=/dev/sda2 bs=4096 skip=$284633 count=1 > /home/suspected.sector.dd
1+0 записей считано
1+0 записей написано
скопировано 4096 байт (4,1 kB), 0,00751888 c, 545 kB/c

Как теперь правильно ее снимать? Я делал так:

linux-1cxy:/home/mopsene # dd if=/home/suspected.sector.dd of=/dev/stdout bs=4096 count=1

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

Ну и мандатные системы конечно намного удобнее чем chroot, только вот настраивать надо под каждую софтину персонально (чруты можно 100% автоматом генерить).

Для начала поднял вопрос в рассылке debian-russian http://lists.debian.org/debian-russian/2011/12/msg00727.html