Список следящего ПО (безопасная установка Debian)
Давайте соберём список проприетарных и открытых программ, которые без ведома пользователя по умолчанию отправляют статистику и подобные вещи? Если эта функция в программе не отключается, то можно выделять заголовок страницы с программой жирным.
Ещё можно читать соглашения конфиденциальности и брать только интересные части, отсеивая всё лишнее, упоминая о продаже пользовательской информации.
Прим. модер.: поскольку тема ожидаемо превратилась в местный филиал ЛОР, то следящие программы в следящих ОС можно обсудить где-то отдельно. В разделе оффтопик, например ;)
Таки второй. Ваш метод убирания из стартапа вроде работает, после перезагрузки не вижу CUPS в списке.
xdm стартует автоматически, всё по-заводскому. Тем не менее, второй.
Обычно пишут how-to мануалы с полным траблшутингом, где описывают step-by-step, что должно быть установлено, как проверять работоспособность каждой компоненты и т.д. Если пошагово их проходить, то точно можно понять источник проблемы. То ли я плохо искал, то ли нет такого для CUPS. Или это обратная сторона --no-install-recomends — что-то важное не поставилось или не сконфигурировалось. В системе печати столько разных интерфейсов, методов и легаси, что не сразу поймёшь, какие именно мануалы читать вообще не стоит. Например, старый LPD умел печтать, как я понял, только текстовые файлы. Тем не менее, его файлы конфигурации /etc/printcap до сих пор как-то используются совместно с CUPS. Я на одном удалённом сервере попытался распечатать pdf через lp, так он пошёл его печтать как текстовый файл (т.е. примерно то, что вы увидете в pdf, открыв его в vim).
Да, F5 показало чуть больше, чем было — 6 индикаторов. Судя по F6, звуковая всё же одна.
Вопросы:
комментариев: 11558 документов: 1036 редакций: 4118
Отнюдь (см. ISO 19005), просто к нему есть куча проприетарных расширений. Если в конкретном файле они не используются, то без разницы, откроете вы его в Adobe Reader или в каком-нибудь qpdfview.
Я компилил собственные pdf-ки из LaTeX. При просмотре их разными pdf-вьюерами заметны небольшие отличия — это первое. При печати из некоторых проприетарных ОС играет роль, с какого вьюера файл был отправлен на печать — это второе. В силу этих причин я с тех пор стал всё печатать из acroread.
Предполгаю, что одна из причин может быть в следующем: в стилевом файле latex указаны шрифты, которых в системе нет. В итоге эти шрифты заменяются наиболее близкими к ним. У разных pdf-вьюеров разный набор доступных шрифтов (в частности, у acroread есть свои полупроприетарные, которые сидят либо в нём, либо доставляются зависимостями к нему — не знаю), поэтому идентичный документ может выглядеть по-разному. Соответственно, и принтер их понимает по-разному(?).
комментариев: 11558 документов: 1036 редакций: 4118
Ещё хотел спросить про нормальное шифрование в userland. Хотелось бы, чтобы запуская скрипт и давая ему пароль происходило следующее:
- Монтировалось какое-то устройство/файл или логический том.
- С конфигами этого тома запускалась программа (например, там хранится БД почты, которую использует mutt).
- Давая определённую команду, я закрыаваю mutt и отмонтирую том.
Просто идея, что ключи с доступом к критическим даным постоянно висят в памяти, мне не нравится. Хотелось бы подключать их по простому 128-битному паролю с юзерофильным скриптом, а потом так же легко отмонтировать. У eCryptFS и EncFS есть вроде бы всякие issues из-за того, что они шифруют пофайлово, а cryptsetup не может работать в userland — я правильно понимаю? И какой тогда выход? Каждый раз логиниться под рута, чтобы подмонтировать нужный том? Или надеяться, что sudo безопасно? Нужно, чтобы sudo давало выполнить определённый набор команд определённому пользователю и ничего другого (никому и никогда и ни при каких обстоятельствах) — это реально? Т.е. никаких sudobushbash.Я в шоке. Зачем я тогда ему -4 указывал? Или в Lunux IPv6 можно отключить только через опцию к grub?
комментариев: 11558 документов: 1036 редакций: 4118
Если не извращаться с конфигурацией, sudo достаточно надёжно. Напишите нужный скрипт, положите его в директорию рута и дайте конкретному юзеру через sudo право на исполнение этого конкретного скрипта.
комментариев: 11558 документов: 1036 редакций: 4118
Отключите в ядре.
Без перекомпиляции ядра никак? Или можно каждый раз какой-то ядерный модуль выгружать после старта системы?
комментариев: 11558 документов: 1036 редакций: 4118
Этот способ ещё не устарел для современных Linux-ядер?
В меню grub2 есть опция linux ... root=/dev/mapper/NAME, которая сливает название всей volume group и logical volume для root, находящееся внутри LUKS, в незашифрованный /boot раздел. Скажите, зачем так в Linux делают? UUID'ы для всего и вся, там прописанные, тоже не радуют.
Grub2 ужасен, тотально ужасен. Наворотили столько автоматики, что караул. Убрали всё ручное управление, теперь рулится только из заумных скриптов, которые будут считать себя умнее вас. Надеюсь, если в меню grub это не указано явно, он не будет пытаться с PXE по сети загрузиться?
В каком месте правильно указывать правила iptables, которые система должна читать после загрузки? Этот способ с rc.boot вызывает вопросы, потому что rc.boot вроде как, пишут, устерл и хранится только для совместимости. Кроме того, на сайте Debian написано, что он всё равно выполняется после старта всей системы, а не at boot time, т.е., не понятно, чем он слаще стандартного rc.local. Можно ещё с if-up скрптами поиграться, но намного ли лучше это, чем rc.local? По уму правила должны загружаться сразу после загрузки ядра и ещё до старта всех сетевых демонов. Возможно ли такое легко сделать, не ковыряясь в глубинах SysV-ранлевелов? В BSD был конкретный файл, куда прописывались правила pf, выполняемые во время boot. Всё было просто и понятно.
комментариев: 9796 документов: 488 редакций: 5664
Извините, на многие вопросы подробно не ответить, просто лень. Когда-то ставил давно, на тот момент как-то сообразил как настроить до нужного состояния. Если лично мне понадобится — придёться вспоминать или ломать голову снова, или надеяться, что само заработает. Потом апгрейдил системы до wheezy. Времени на полный аудит всех систем нет, на попытку чистовой установки и пошагового воспроизведения тоже. Когда давно пользуешься системой остаются бэкапы старых конфигов, разные текущие конфиги, куда при новой установке можно глянуть.
На ходу приходиться каждый раз разбираться. Без конца что-то меняется. Чего стоят всякие изменения в /proc, udev и пр. Вот пропихнут и навяжут всем систему инициализации от Л.Поттеринга с кучей фич, наподобие бинарных фрагментов в логах и поимеем ещё кучу геморроя с багами, утечками, сложностью нестандартных настроек.
В Debian был (есть?) какой-то стандартный способ складывания конфигов iptables. Не помню насколько плохой, но дико бесящий своими попытками облегчить жизнь неопытным пользователям. Закинуть свой скрипт в /etc/network/if-pre-up.d/ пока остаётся самым надёжным. Только после каждого нового релиза — как ходьба по минному полю со старыми знаниями по настройке.
У меня сложные отношения с SELinux. У команды Debian похоже тоже. Они не осилили новую сборку правил и пихнули в wheezy то, что кое как работало с предыдущего релиза. Из-за кучи непофикшенных правил, теперь стало ещё больше глюков. Соответственно, больше штук приходиться отключать или допиливать, чтобы работало.
Общий принцип: это слой защиты, который лучше, чем ничего. Он, по идее не сможет сделать хуже (несмотря на своё АНБ-шное происхождение), но во вногих местах он серьёзно перекрывает возможность эксплуатации уязвимостей и утечек. Но где-то он может не сработать. Никаких гарантий. Кое где явно приходиться отключать многие из его фич из-за невозможности побороть их глючность.
По сложности настройки — это не волшебная кнопка. Или придёться копаться немного (но даже это очень головоломно) внутри, или отключить (почти) всё.
В wheezy сделали выбор из SELinux и AppArmor, из-за плачевного опыта внедрения и поддержки первого. Но как-то жалко переходить на альтернативы потому что теоретически подход SELinux более правильный.
Почти всё показывает и всё больше без него. Остальное скачиваете через cclive и просматривайте через mplayer, поставленный из репозитория debian-multimedia. Так даже получается скачать часть закрытых для просмотра роликов (не говорите об этом баге гугловцам :). Кстати, SELinux, ограничивающий пользователя и mplayer, здесь как раз очень полезен из-за того что mplayer пишется с наплевательским отношением к безопасности.
Ни в коем случае! Evince, Okular, Acroread, что-угодно, только не Adobe!
Для этого предназначен pmount с суидным битом. Имел критические баги, также как и sudo. Это не в смысле, что надо отказываться, а что или полное неудобство, или безбажных утилит практически не бывает.
Всякие автораны — плохая штука. Хотя, в /etc/cryptab можно прописывать и свои скрипты, но оно не предназначалось для этой цели.
Ключи будут доступны или юзеру, или только тому, кто получит рута. Поэтому любой механизм передачи ключа от юзера к руту будет также потенциально уязвим, как и sudo. Причём из-за сложности и экзотичности это имеет больше шансов оставаться зеродеем, открытым узкой группой иссследователей.
В /etc/default/grub строка CRUB_CMDLINE_LINUX= должна содержать ipv6.disable=1. Затем сделаете grub-update и после ребута не должны видеть никаких ipv6, например по ifconfig. Некоторые программы могут ругаться (локальная почта), но у них в конфигах запросы к ipv6 тоже при необходимости отключаются.
И это (почти) всё идеологически правильно, не буду аргументировать подробно почему именно. В общем, многое из этого работает над повышением надёжности, безглючности и гибкости шифрования. Которое может стартовать, например с рейда. Тренд разработчиков: в шифровании ещё многое недоделано, поэтому на сокрытие и анонимность забиваем (и забываем) на десятилетия. Пытаясь с наскоку по-простому что-то допилить и быть умнее разработчиков в этой плохо решаемой проблеме можно получить вместо улучшения сокрытия с шифрованием — плохое сокрытие и ухудшенное шифрование.
Этому можно верить? Там почти все сервисы в /bin/sh, боюсь сломать систему такой модификацией.
Стоит ли держать /boot подмонтированным? Автор предлагает так делать. Если не делаются апгрейды чего-то, с grub связанного, то казалось бы, незачем его монтировать по умолчанию. Или информация в нём как-то влияет на установку других пакетов при apt-get?
Это сомнительный, на мой взгляд, совет. Если понадобится вдруг рестартнуть сеть во время работы прозрачной торификации, будет выполнен скрипт pre-up, а в этом скрипте, как правило, первая строчка — сброс уже существующих правил iptables. Пока новые правила не загрузятся, будет некий промежуток времени. Кто даст гарантию, что в этот промежуток левый пакет не уйдёт в сеть напрямую? Он, конечно, pre, но вот насколько он pre? Что происходить будет с уже установленными сетевыми соединениями в момент /etc/init.d/networking restart? Вот в BSD всё совсем не так: там правила fw сами по себе, сетевые интерфейсы — сами по себе. Если в какой-то момент сетевого интерфейса ещё нет, а правило есть, ни один сетевой пакет под правило не подпадает и всё ОК.
Это была не просьба к вам конкретно, а мысли в слух. :) Всё-таки разработчики соответствующих систем обычно пишут мануалы к своим программам, в том числе, и по траблшутингу. Если вдруг попадётся толковый мануал по решению проблем с CUPS, киньте ссылку.
acroread — это и есть адобовский acrobat reader, разве нет?
А без таких механизмов лучше? Допустим, запущен джаббер. Там висят ключи в памяти, содержимое сообщений. Хочется куда-то отойти, и что делать? Заблокировать экран и всё? Тогда ключи продолжат висеть в памяти, как для PGP, так и для дискового шифрования. Хотелось бы каждый раз перед блокированием экрана выключить джаббер и отмонтировать раздел с конфигами/логами, которые он пишет/читает, это было бы самым надёжным, но тут получается много шагов:
- Выходим из джаббера (ключ, надеюсь, при этом сносится из памяти) и блокируем экран.
- Идём в консоль, логинимся под root.
- umount лог. тома
- luksClose на девайс
Когда через 5 минут возвращаемся обратно, повторяем опять те же шаги. Слишком длинно получается, хотел как-то упростить...Уже сделал, но не перезагружался ещё. ifconfig и сейчас ничего про ipv6 не показывает, но это не мешает dhclinet'у слушать на ipv6. Кроме того, для управления ipv6 может использоваться и другая утилита, не ifconfig(?). Во всяком случае, я на таком однажды накололся: iptables показывает, что никакого ipv6 нету, а реально ipv6 рулится ip6tables'ом, про который мало кто знает. Вдруг и с другими утилитами также...
Это добавляет ряд удобств, а об их следствиях для анонимности мало кто думает. Можно, кстати, отметить, что во всяких embedded Linux никакого UDEV'а естественно нет (а, может, и DBUS'а). Т.е. нет всего этого чисто Linux'ового, к чему уже все привыкли, и чего ещё нет во многих BSD. С другой стороны, в стандартных дистрах UDEV и DBUS настолько тесно связаны со всем и вся, что дёшево оттуда его уже не выпилить (разве что только с помощью LFS если).