id: Гость   вход   регистрация
текущее время 16:29 28/03/2024
Автор темы: Гость, тема открыта 23/07/2013 01:13 Печать
Категории: софт, сайт проекта, свободный софт, закрытый софт
http://www.pgpru.com/Форум/UnixLike/СписокСледящегоПОбезопаснаяУстановкаDebian
создать
просмотр
ссылки

Список следящего ПО (безопасная установка Debian)


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


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


Прим. модер.: поскольку тема ожидаемо превратилась в местный филиал ЛОР, то следящие программы в следящих ОС можно обсудить где-то отдельно. В разделе оффтопик, например ;)


 
На страницу: 1, 2, 3, 4, 5, ... , 18, 19, 20, 21, 22 След.
Комментарии
— Гость (03/04/2015 00:54)   <#>
посмотрел тут на досуге netstat -nr и чудо чудное:
169.254.0.0 0.0.0.0 255.255.0.0 U 0 0 0 ethX

Толи после какого обновления, то ли еще после чего появилась эта запись, а точнее стал определяться zeroconf.
Есть у кого опыт коректно отрубить, ибо не имею такого опыта. Наткнулся на кривые предложения по удалению/отключению.
— Гость (05/04/2015 17:52)   <#>

   Стандартный адрес то ли для каких-то броадкастов, то ли ещё чего, уже не помню. Это винда в основном такими адресами страдала, в Linux'ы только недавно добавили. Вывод надо делать netstat -apn — тогда будет видно, какой процесс это запускает, и дальше уже удалять этот процесс из авторстарта.


   Если используется удобный и искоробочный keychain, то дела обстоят так: он при запуске проверяет агенты (ssh- и gpg-), и, если один из них не обнаружен, то запускает их. Есть опция --agents, где можно принудительно указать, что запускать, но работает она, похоже иначе: это принудительный запуск чего-то помимо уже запущенного, а не запуск «этого и только этого, что указано в опции». Ну, т.е., если ssh-agent уже запущен, и keychain определило его наличие, то запускать не будет; а если укажем --agents ssh, то оно запустит ещё один лишний ssh-agent поверх имеющегося. Это первая проблема. Её можно было бы решить, убивая в каком-нибудь скрипте ненужные агенты сразу после запуска keychain.
   Вторая проблема состоит в том, что при запуске ssh-agent'а с завязкой на сокет (опция -a), процесс не висит: он создаётся, пишет переменные среды в терминал и тут же умирает, в списке процессов его больше нет. Переменные среды в текущем шелле остаются. Нормально ли такое поведение — не знаю, но keychain его никак не видит, поэтому при запуске само запускает ssh-agent. Я пытался поизвращаться как-то типа
$ ssh-agent -a /path/to/ssh-socket-name keychain ~/.ssh/*.ssh
но это тоже ничего не дало. После некоторых экспериментов создалось впечатление, что keychain в принципе не улавливает те агенты, которые зацеплены на сокеты (впрочем, раз для тех и процессов нет, то, может быть, дело всё-таки не в keychain). Скажем так, при --use-standard-socket gpg-agent запускается и висит в процессах, а тут даже процесс не висит. Возможно, это всё опять же из-за тонкостей реализации SSH-тулзов в Debian, как на это в man'ах намекают.
   По итогам этих изысканий складывается впечатление неразрешимости проблемы. Надо либо терпеть то, что временные SSH-файлы будут складываться напрямую в /tmp, либо полностью отказываться от запуска каких-либо агентов для SSH (к примеру, снять пароли с SSH-ключей и каждый раз указывать их параметром к ssh-командам).
— Гость (28/04/2015 19:00)   <#>
Леннарт как-то сказал, что баги системд теперь должны исправлять мейнтейнеры тех дистров, в которых они были обнаружены. Лол. Апстрим системд, похоже, теперь только разрабатывает фичи...

Это правда? ☺ Правда:

Я не могу отрицать, что мы, как команда разработчиков [широкоиспользуемого] апстрима, получили порядочную степень влияния. Тем не менее, не мы занимались интеграцией systemd в дистрибутивы; это делали их разработчики. Мы даём базовые рекомендации о том, как следует поставлять и использовать компоненты systemd, но вообще это не наше дело. Дистрибутивы регулярно многое переделывают или вносят изменения в код, и это абсолютно нормальная ситуация. В самом деле, даже Fedora и RHEL иногда делают некоторые вещи по-другому, при том что я сам участвую в сборке systemd для этих дистрибутивов! Мы предоставляем основу, а дистрибутивы затем адаптируют её к своим нуждам.

Мы стараемся обеспечить разнообразие в команде разработчиков systemd; сделать так, чтобы она отражала мнение сообщества в целом. Среди нас есть люди из Debian, Canonical, Mageia и Tizen (о Fedora/RHEL вы наверняка уже догадались). Вообще говоря, одна из наших задач — это плавно прекратить управлять происходящим.

Хорошо поржал на подчёркнутой фразе... ☺

поттеринг принципиально скидывает это на дистростроителей, он открыто говорит, что "мне пох, их возня"
— unknown (28/04/2015 21:25)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664
Вообще-то, такое отношение апстримеров у большинства проектов. Например, как в OpenSSL.
— Гость (28/04/2015 21:36)   <#>
Да, но я так понял по ваше ссылке, что это всё же не то, что есть гут.
— unknown (28/04/2015 21:43, исправлен 28/04/2015 21:44)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664

А всё этим не гут и закончится. Другое дело, что systemd, похоже, неизбежен. Несмотря на то, что он — такой же кошмар как и OpenSSL. Его неподдержка, частичная поддержка, возможность выпиливания — чисто формальная.

— Гость (28/04/2015 22:19)   <#>
Почему чисто формальная? При выпиливании от systemd остаются только либы.
— SATtva (29/04/2015 07:33)   профиль/связь   <#>
комментариев: 11558   документов: 1036   редакций: 4118

Переходите на Gentoo.
— unknown (29/04/2015 09:44, исправлен 29/04/2015 09:46)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664

И работоспособность официально не гарантируется. Пока мы оказываемся в положении выбора самого плохого из двух зол одновременно: что-то уже может не работать без systemd, а что-то — ещё быть не допиленным для работы с ним.



LFS, дистросрач. Сильно подозреваю, что много чего будет на него завязано почти намертво и Gentoo это не разрулит. Первый кандидат — SELinux. Затем, могут быть всякие штуки, связанные со звуком. В своё время все также шарахались от LVM или от GRUB. В принципе, можно до сих пор ими не пользоваться.

— Гость (29/04/2015 11:42)   <#>

Я предполагал, что по ссылкам вы не ходите, но не до такой же степени, как оказалось... Ссылка [5] в комментарии ведёт на:

"With jessie, it will become /easier/ to choose the init system, because neither init system is essential now. Instead, there is an essential meta-package "init", which requires you to install one of systemd-sysv | sysvinit-core | upstart. In other words, you have more choice than ever before."

This statement is actually correct; until this change it was not possible to completely replace sysvinit with another init system without running dpkg-divert commands to divert the init away.

When, in fact, there IS no way to prevent systemd from being installed during installation (except for upgrades).

That preseeding doesn't do this is a bug, it's filed (#668001), and the patch for it was just written on Friday the 17th. Because Debian is going to freeze in less than three weeks, the maintainers are wary of applying this patch this close to release without extensive testing.

Furthermore, the effect of this patch is trivially obtained by using a late_command to remove systemd-sysv and install sysvinit-core.

If you actually want to see this patch applied to the version of the Debian installer that Jessie will release with, you should coordinate with the nice people in #debian-boot to see what type of testing they would want to see before they are willing to vet the patch.

Нужно перевести на русский или так понятно? Один релиз живёт примерно два года. Даже если всё так плохо, и они не будут поддерживать совместимость с обеими системами, пару релизов SysV ещё переживёт, IMHO. Т.е. года четыре в запасе есть, а там видно будет.


Вот и именно. Можете хоть сейчас lilo выбрать при установке. Плохо то, что SysV они не включили штатной опцией в инсталлятор, поэтому будет мало её юзеров. Мало юзеров — хуже тестинг, меньше внимания к неработающим вещам.
— unknown (29/04/2015 12:36, исправлен 29/04/2015 12:54)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664

У меня есть свои:


Caution
Be advised that some packages may have degraded behavior or may be lacking features under a non-default init system.
— Гость (29/04/2015 17:11)   <#>

По моим ссылкам были предупреждения, что это касается только тяжеловесных десктопных пакетов типа GNOME и KDE. Если вы этим не страдаете (а вы этим не страдаете), думаю, можете смело забить на это предупреждение. Это GUI'шным приблудам для администрирования системы, может быть, очень важно, что там, systemd или SysV, а консоли-то что с того?

А я по вашей классификации вообще «самый экстремал», так что, тем более...
— Гость (29/04/2015 17:13)   <#>
Точней, всё ещё хуже: я стал самым экстремалом как раз после прочтения того вашего комментария. ☺
— pgprubot (09/08/2015 20:46, исправлен 09/08/2015 20:51)   профиль/связь   <#>
комментариев: 511   документов: 2   редакций: 70

Файл ~/.zcompdump, вроде как создаваемый командой compinit, можно отправить туда же, заменив в ~/.zshrc

compinit
на
compinit -d $TMP/.zcompdump.$USER
Теоретически в новых версиях zsh для этих целей должно работать что-то типа
ANTIGEN_COMPDUMPFILE=$TMP/.zcompdump.$USER


К удивлению обнаружилось, что ~/.xsession-errors не так безобиден, как казалось раньше. Например, туда попадает выхлоп из управления музыкальным демоном mpd со списком проигрываемых композиций, чего явно не ожидалось. По всей видимости, это лечится только грязными хаками. Самое простое — заменить строчку

ERRFILE=$HOME/.xsession-errors
в /etc/X11/Xsession на
ERRFILE=/tmp/$USER/.xsession-errors
USERTMPDIR=/tmp/$USER
if ! [ -d $USERTMPDIR ] ; then
    mkdir -p $USERTMPDIR
    chmod go-rwx $USERTMPDIR
fi

— pgprubot (28/08/2015 15:55)   профиль/связь   <#>
комментариев: 511   документов: 2   редакций: 70
Можно подойти к проблеме ещё радикальней: чем бороться со всеми «умными» приложениями, которые загаживают $HOME опасными данными, проще располагать $HOME где-то в /tmp, т.е. сделать /tmp/USERNAME_HOME домашней директорией юзера, контент которой восстанавливается перед логином в этого юзера из чистого бэкапа. Сами файлы, с которыми юзер работает, могут по-прежнему располагаться где-то в /home. Т.е., все статические конфиги должны быть в бэкапе и фикситься вручную, когда это нужно, а не так, что запустил прогу — и она тебе испохабила конфиги (содержимое ~/.local, ~/.cache и др. директорий).
На страницу: 1, 2, 3, 4, 5, ... , 18, 19, 20, 21, 22 След.
Ваша оценка документа [показать результаты]
-3-2-1 0+1+2+3