LINUX.ORG.RU
ФорумAdmin

Как запретить все логи, .bash_history и пр.

 


0

1

Задача стара, как мир *nix'ов :=)
Поскольку задача создания своего дистра LiveCD для меня нетривиальная, прошу подсказать, как запретить создание всех логов, .bash_history и прочих возможных следов жизнедеятельности Debian.
Не отправлять их в память (где их можно в текущем сеансе прочитать), а пресечь их создание прямо на корню.
Гуголь находит много инфы по данной теме, но вся она не очень надежно.

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

 service rsyslog stop

Then, you can disable it at boot:

systemctl disable rsyslog
А вот ни фига - часть логов больше не пишется, и их можно грохнуть, но часть все таки продолжает обновляться, например, Xorg.
Нужен более действенный метод.

Что касается запрета создания .bash_history, то и нас есть такая такая темка, но в ней наши парни наворотили столько всего, что непонятно, за что хвататься :=)

★★★★★

Последнее исправление: chukcha (всего исправлений: 1)

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

imb ★★
()
Ответ на: комментарий от imb

но приложение не обязано его использовать и может само писать в свой файл

Хорошо, но наверное, любые приложения пишут где-то в районе /var/log ?
Тогда можно помониторить их поведение и попробовать с ними побороться.

А пока хотя бы как надежно запретить чисто системные логи и .bash_history?

Тем более что моя система - это минимизированных консольный Debian без каких-либо излишеств вредных дополнительных приложений :=)

chukcha ★★★★★
() автор топика

В общем случае задача разумным способом не решается. Неразумным она решается монтированием всех файловых систем в readonly и запретом любой записи в память, тогда точно ни один лог не пройдет.

slowpony ★★★★★
()
Ответ на: комментарий от slowpony

Неразумным она решается монтированием всех файловых систем в readonly и запретом любой записи в память, тогда точно ни один лог не пройдет.

Но тогда, наверное, и система не сможет никак работать :-(

chukcha ★★★★★
() автор топика
Ответ на: комментарий от chukcha

задача была озвучена так

как запретить создание всех логов

и на неё был дан ответ, если рассматривать частные случаи, то и решения будут частные, как уже предложенный использовать read-only файловую систему, для некоторых сервисов/приложений можно отключить логирование через конфиг или направить его, как пример, в /dev/null

imb ★★
()
Ответ на: комментарий от chukcha

Но тогда, наверное, и система не сможет никак работать

почему? зависит от того что делается в системе, как пример, многие embedded устройства использую read-only файловую систему и, если нужно, отдельный read-write раздел для изменяемых данных

imb ★★
()

Поскольку задача создания своего дистра LiveCD для меня нетривиальная, прошу подсказать, как запретить создание всех логов, .bash_history и прочих возможных следов жизнедеятельности Debian.

Я не вполне понял, а при чем тут LiveCD? Логи в них очень даже пишутся, просто в оперативную память, а сама ОС работает из RO.

Vsevolod-linuxoid ★★★★★
()

Вариант номер ноль. Ищешь дистрибутив, в котором эта проблема уже решена и все компоненты настроены на то, чтобы не писать, или писать в ramdisk небольшого размера. Что-то из эмбеддед. Я бы посмотрел в сторону yocto.

Вариант самопальный.

  1. Запускаешь систему с R/W оверлеем, в рамдиске или ещё как. Даёшь на неё целевую нагрузку, которая должна вызывать срабатывание всех возможных записей.

  2. Анализируешь содержимое оверлея.

  3. Прикладываешь усилия по настройке ПО на отключение найденных логов. Самый простой способ это сделать ln -s /dev/null /var/log/logfile. Могут быть и другие варианты.

  4. Опционально. Монтируешь систему в R/O, все каталоги, которые должны быть доступны для записи, монтируешь в R/W в tmpfs или ещё как. Если за чем-то не углядел, может что-нибудь сломаться.

vbr ★★★
()
Ответ на: комментарий от imb

почему? зависит от того что делается в системе, как пример, многие embedded устройства использую read-only файловую систему и, если нужно, отдельный read-write раздел для изменяемых данных

Это да, но это же какие-то каким-то переделанные дистрибутивы?
А не просто взял нативный Debian, для read-only записал его на CD, для изменяемых данных флешку и вуаля/
Так, имхо, оно работать не сможет, надо что-то переделывать в системе

Я не вполне понял, а при чем тут LiveCD? Логи в них очень даже пишутся, просто в оперативную память,

Точно? И в знаменитом Tails тоже пишутся?

chukcha ★★★★★
() автор топика
Ответ на: комментарий от vbr

Повозился с запретами логов, и вот что получилось:
- если запретить rsyslog этими командами -

service rsyslog stop
systemctl disable rsyslog
то картина получается такая:
-rw-rw-r--   1 root utmp            292292 Jul 27 18:17 lastlog
-rw-rw-r--   1 root utmp             26112 Jul 27 18:17 wtmp
-rw-r-----   1 root adm              28294 Jul 27 01:35 daemon.log
-rw-r-----   1 root adm             216387 Jul 27 01:35 syslog
-rw-r-----   1 root adm             173149 Jul 27 01:33 messages
-rw-r-----   1 root adm               3137 Jul 27 01:30 auth.log
-rw-r--r--   1 root root             32032 Jul 27 01:27 faillog
-rw-rw----   1 root utmp               768 Jul 27 01:27 btmp
-rw-r-----   1 root adm             186405 Jul 27 01:24 kern.log
-rw-r-----   1 root adm              14454 Jul 27 01:24 debug
-rw-r--r--   1 root root            118985 Jul 27 01:24 dpkg.log
-rw-r--r--   1 root root              7454 Jul 27 01:24 alternatives.log
drwxr-xr-x   7 root root              4096 Jul 27 01:24 .
drwxr-xr-x   3 root root              4096 Jul 27 01:24 runit
drwxr-xr-x   2 root root              4096 Jul 27 01:24 apt
drwx------   2 root root              4096 Jul 27 01:14 private
drwxr-sr-x+  3 root systemd-journal   4096 Jul 27 01:14 journal
drwxr-xr-x   3 root root              4096 Jul 24 14:26 installer
drwxr-xr-x  11 root root              4096 Jul 24 14:21 ..
Т.е. 2 лога таки меняются:

- lastlog
- wtmp

а остальные, значит, можно удалить.
Правда, при ошибках залогинивания возникают еще логи btmp и может еще какие-то, которые наверное тоже можно запретить.

Но проблема в другом - в Дебиане, обычному юному хацкеру доступно содержимое такого стратегицкого каталога, как /proc, из которого можно выудить о системе что угодно, и при этом даже не нужно быть рутом!
А еще права каталогов, создаваемых при добавлении юзеров - 755!
Это вообще задница, которую разрабы Дебиана не исправляют лет двести :-(
В редхатах, кстати, это сделано правильно - 700

Не, Debian явно не серверный дистр, но приходится пользоваться....

chukcha ★★★★★
() автор топика
Ответ на: комментарий от chukcha

Но проблема в другом - в Дебиане, обычному юному хацкеру доступно содержимое такого стратегицкого каталога, как /proc, из которого можно выудить о системе что угодно, и при этом даже не нужно быть рутом!

Что Вы там собрались прятать? Задавайте права при монтировании раз так смущает, права на /sys или /dev не смущают?

А еще права каталогов, создаваемых при добавлении юзеров - 755! Это вообще задница, которую разрабы Дебиана не исправляют лет двести :-(

Почему Вы решили что это проблема и именно проблема Debian?

$ grep  HOME_MODE /etc/login.defs 
# HOME_MODE is used by useradd(8) and newusers(8) to set the mode for new
# If HOME_MODE is not set, the value of UMASK is used to create the mode.
#HOME_MODE      0700
imb ★★
()
Последнее исправление: imb (всего исправлений: 1)
Ответ на: комментарий от imb

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

Разве это не проблема, когда один юзер может запросто читать содержимое каталога другого юзера?
Это тогда извините не Linux, а Виндоус 95 на FAT.

chukcha ★★★★★
() автор топика
Ответ на: комментарий от chukcha

Да все смущает в этой дырявой системе

И как Вы или другие можете эксплуатировать эту «дырявость»? Или это перестраховка? Какую проблему Вы решаете?

Разве это не проблема, когда один юзер может запросто читать содержимое каталога другого юзера?

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

imb ★★
()
Ответ на: комментарий от chukcha

Но проблема в другом - в Дебиане, обычному юному хацкеру доступно содержимое такого стратегицкого каталога, как /proc, из которого можно выудить о системе что угодно, и при этом даже не нужно быть рутом!

Какие страшные хакеры. Могут прочитать данные процессов, что они сами и запустили. Решето, однозначно.

PPP328 ★★★★★
()
Ответ на: комментарий от imb

Это не проблема linux и конкрентного дистрибьютива,

Кажется, я точно изложил? Это - проблема именно Debian. В Редхатах ее нет.
Про другие дистры не помню, давно дело было.

chukcha ★★★★★
() автор топика
Ответ на: комментарий от chukcha
man journald.conf

да, так тоже можно )

И там чуть-ли не в самом начале написано то что написал superuser.

OPTIONS

       Storage=
       Storage=
           Controls where to store journal data. One of "volatile", "persistent", "auto" and
           "none". If "volatile", journal log data will be stored only in memory, i.e. below the
           /run/log/journal hierarchy (which is created if needed). If "persistent", data will be
           stored preferably on disk, i.e. below the /var/log/journal hierarchy (which is created
           if needed), with a fallback to /run/log/journal (which is created if needed), during
           early boot and if the disk is not writable.  "auto" is similar to "persistent" but the
           directory /var/log/journal is not created if needed, so that its existence controls
           where log data goes.  "none" turns off all storage, all log data received will be
           dropped. Forwarding to other targets, such as the console, the kernel log buffer, or a
           syslog socket will still work however. Defaults to "auto" in the default journal
           namespace, and "persistent" in all others.

PS

Про ln сами прочитайте, это ДЗ.

peregrine ★★★★★
()
Последнее исправление: peregrine (всего исправлений: 1)
Ответ на: комментарий от chukcha

Нет, в данном случае проблемой Вы выставляете разные значения по-умолчанию, но это не верно.

Поменяйте значения по-умолчанию если они Вам не нравятся, инструмент у Вас есть, если Вы о нём не знаете то это не проблема дистрибьютива.

Это - проблема именно Debian

Вы конечно же сообщили о ней и можете привести номер?

imb ★★
()
Ответ на: комментарий от imb

Вы конечно же сообщили о ней и можете привести номер?

Номер чего - багрипорта? Об ошибке, которая заложена в Debian от дня его создания, и которую никто никогда не будет исправлять?
Не смешите. Эта ошибка входит в философию Debian, что он десктопный, а не серверный дистрибутив, так что разрабам пофиг на безопасность.

chukcha ★★★★★
() автор топика
Ответ на: комментарий от chukcha

Номер чего - багрипорта? Об ошибке, которая заложена в Debian от дня его создания, и которую никто никогда не будет исправлять? Не смешите. Эта ошибка входит в философию Debian, что он десктопный, а не серверный дистрибутив, так что разрабам пофиг на безопасность.

sudo dpkg-reconfigure adduser

Rootlexx ★★★★★
()
Ответ на: комментарий от Rootlexx

При чем тут исправление ошибки некорректного доступа своими силами? Речь идет об ошибке во всей линейке Debian, которую они не исправляют с прошлого столетия.

chukcha ★★★★★
() автор топика
Ответ на: комментарий от chukcha

Речь идет об ошибке во всей линейке Debian, которую они не исправляют с прошлого столетия.

Если вы с чем-то не согласны, это ещё не значит, что это ошибка. Не нравится — поменяйте или вообще не используйте.

Rootlexx ★★★★★
()
Ответ на: комментарий от chukcha

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

Если вы не в курсе, доступ к файлу определяется прежде всего заданными правами для данного файла, а не правами для каталогов, в которых он (транзитивно) находится. Последнее элементарно ненадёжно, поскольку файл (или содержащий его каталог) может быть с-bind-ен в другое место с открытым доступом, на файл могут существовать жёсткие ссылки и проч.

Права 700 же могут помешать, например, традиционной работе ~/public_html, ибо веб-сервер обычно работает с ограниченными правами, поэтому лучше 711 как значение по умолчанию, если уж вам не нравится 755.

Rootlexx ★★★★★
()
Ответ на: комментарий от Rootlexx

Права 700 же могут помешать, например, традиционной работе ~/public_html

Вообще-то хватает и 701. Но при чем это?

Вас не шокирует тот факт, что с вашими любимыми 755 любой юзер может запросто зайти в любой home и прочитать чужие данные??
Это вообще как - много- или однопользовательская ОС?

И почему в редхатовских ОС спокойно решаются проблемы типа вашей «Права 700 же могут помешать, например, традиционной работе ~/public_html» даже с правами 700?

А в Дебиане, если по вашему мнению, чтобы не было подобных проблем, приходится давать тотальные права 755.

Может, в дебиановской консерватории что-то не так?

chukcha ★★★★★
() автор топика
Ответ на: комментарий от chukcha

Вас не шокирует тот факт, что с вашими любимыми 755 любой юзер может запросто зайти в любой home и прочитать чужие данные??

Сможет такой любой юзер прочитать, например, приватный ключ ssh? - нет, не сможет. Всё ещё не понимаете, что доступ к файлам определяется правами доступа к этим файлам, а не к домашнему каталогу?

Ну и:

Rootlexx ★★★★★
()
Ответ на: комментарий от Rootlexx

Всё ещё не понимаете, что доступ к файлам определяется правами доступа к этим файлам, а не к домашнему каталогу?

Вы ограничиваете понимание доступа только к файлам или каталогам.

Мне же НСД видится в том числе и в том, что сторонний пользователь получил доступ с ^списку^ файлов - все, дальше можно особо не продолжать, т.к. даже по названиям файлов-документов становится понятен круг интересов юзера, его увлечения, хобби, политические и другие интересы.

chukcha ★★★★★
() автор топика
Ответ на: комментарий от chukcha

Мне же НСД видится в том числе и в том, что сторонний пользователь получил доступ с ^списку^ файлов - все, дальше можно особо не продолжать, т.к. даже по названиям файлов-документов становится понятен круг интересов юзера, его увлечения, хобби, политические и другие интересы.

Если не хотите, чтобы кто-то имел доступ к списку файлов, то у вас есть все возможности этот доступ ограничить, в том числе и по умолчанию.

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

Замечу при этом, что автоматически создаваемые файлы/каталоги, содержащие потенциально чувствительную информацию — вроде .bash_history, .lesshst, .cache/, .config/, .ssh/ и проч. — по умолчанию уже имеют права, исключающие их чтение другими пользователями; что же касается файлов/каталогов, которые пользователь создаёт сам, то он же сам за них и отвечает.

Rootlexx ★★★★★
()
Ответ на: комментарий от Rootlexx

Вы прицепились к дефолту, который используется десятилетиями вообще практически везде,

Везде? Скажите в RedHat - лидеру среди серверных Linux-дистрибутивов, хоть повеселятся.
Они сумели сделать так, что и каталоги закрыты от посторонних глаз, и проблем, которые вы указали при правах 700, у них почему-то не возникает - странно, правда? Ладно, давайте на этом остановимся.

(c) Все равно его не брошу, потому что хороший! :=)

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

chukcha ★★★★★
() автор топика