id: Гость   вход   регистрация
текущее время 17:14 28/03/2024
Автор темы: Гость, тема открыта 19/03/2015 02:22 Печать
Категории: анонимность, операционные системы
https://www.pgpru.com/Форум/UnixLike/ПопыткаПересестьНаLinuxПервыеГрабли
создать
просмотр
ссылки

Попытка пересесть на Linux, первые грабли


В связи с пониманием, что в Виндоуз трудно достичь сколько-нибудь вменяемой безопасности, из-за закрытости кода и возможных закладок, осуществлена попытка пересесть на линукс. Первые грабли не заставили себя ждать. Выяснилось, что я попал в чудный новый мир. Оказывается нельзя просто так взять с сайта и поставить какую-нибудь программу. Необходимо подождать, пока её добавят в репозитарий моего дистрибутива, и после этого установить командой apt-get install. Возник вопрос, можно ли как-то скачивать программу нужной версии вместе с необходимыми ей библиотеками необходимых версий, ставить в нужную мне папку, и запускать оттуда? Такое меня вполне устраивает. А не заморачиваться, есть ли новая версия в репозитарии, нет ли конфликта с какими-то устаревшими библиотеками, и так далее.
Далее, для обновлений рекомендуется прописать сервер ftp.debian.org в /etc/apt/sources.list. Соединение устанавливается назащищенное, соответственно сведения об устанавливаемых приложениях передаются в открытую. Не является ли это "дырой" и ущербом для анонимности? И как это можно обойти?



 
Комментарии
— Гость (19/03/2015 04:34)   <#>

Можно, если готовы вручную всё компилить, включая все зависимости. Stand-alone-программы в Linux непопулярны, TBB — редкое исключение. Даже если кто-то сделал готовый deb-пакет нужной вам версии, вас это не спасёт, т.к. он, скорей всего, слинкован не с теми версиями библиотек, какие установлены в системе по умолчанию, поэтому все недостающие библиотеки нужных версий тоже придётся откуда-то брать. Короче, забейте на это. Даже автокомпиляция из портов (там версии фиксированы, но могут отличаться от системных, быть свежее) — дело не для слабонервных [1], а самостоятельно компилировать всё из исходников будет ещё сложнее.

Насчёт «ставить в нужную папку» — это если только для каждого приложения делать своё дерево портов, т.е. полный анреал. Это полностью противоречит всей сути и духу UNIX'а. В Gentoo Linux вроде можно работать паралельно с деревьями разных версий и выбирать, какую хотите поставить (в широких рамках), но и там всё ставится в /usr, а не в персонально выбранную директорию.


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


Является.


Установить системный Tor [2], закрыть трафик в обход Tor'а файерволлом [3] и торифицировать apt-get [4]. Ну, т.е., на вашем уровне знаний пока проще забить.
— unknown (19/03/2015 09:42)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664

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


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


Название темы неинформативно, нытьё — неконструктивно.


Главное, не устраивать и не поддерживать нытик-треды :).
— Гость (19/03/2015 10:39)   <#>
Возник вопрос, можно ли как-то скачивать программу нужной версии вместе с необходимыми ей библиотеками необходимых версий, ставить в нужную мне папку, и запускать оттуда?

Скачивать можно. Для этого надо всего-то зайти на сайт производителя и скачать. Разумеется, если производитель такую сборку сделал ;)
— Гость (19/03/2015 11:24)   <#>



Можно предложить простое временное решение:

1. Запустите TBB
2. В консоли:
# sudo torsocks apt-get update

А потом установить tor в систему и настроить как предложено
— Гость (20/03/2015 02:41)   <#>

Не заработает. Порт torsocks умолчанию — 9050, а порт TBB — 9150, так что придётся или править /etc/tor/torsocks.conf или менять порт в TBB.
— Линукс_нуб (20/03/2015 02:57)   <#>
Спасибо за советы, хотя полной картины и подоплеки я так для себя и не уяснил. Мне казалось, что "первые грабли" и "чудный новый мир" может выглядеть скорее смешно, но взгляд с другой стороны ответил что ничего забавного :) И это интересно. Ну в конце концов, представьте мое недоумение, когда оказалось, что в силу непонятных мне идеологических или технических причин нельзя просто взять и запустить программу необходимой версии, это же чудо какое-то :)
И эту тему мне хотелось бы развить.

> Попытка пересесть на Linux, первые грабли

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


Название темы неинформативно, нытьё — неконструктивно.


Главное, не устраивать и не поддерживать нытик-треды :).


Тут ответ выше, но спрятать недоумение у меня видимо не получилось.

Можно, если готовы вручную всё компилить, включая все зависимости. Stand-alone-программы в Linux непопулярны, TBB — редкое исключение. Даже если кто-то сделал готовый deb-пакет нужной вам версии, вас это не спасёт, т.к. он, скорей всего, слинкован не с теми версиями библиотек, какие установлены в системе по умолчанию, поэтому все недостающие библиотеки нужных версий тоже придётся откуда-то брать. Короче, забейте на это. Даже автокомпиляция из портов (там версии фиксированы, но могут отличаться от системных, быть свежее) — дело не для слабонервных [1], а самостоятельно компилировать всё из исходников будет ещё сложнее.

Скажите, вот есть Винда. Я ставлю какую-то программу, она ставится вместе со своими библиотеками, после этого работает. Если я поставлю какую-то еще программу, зависимую от этих библиотек, то насколько я понимаю у меня не возникнет конфликта зависимостей. А что в таком случае происходит в Линуксе? Есть какое-то чисто техническое отличие в реализации, или это просто идеологическая парадигма, одна библотека, в определенной папке, и все новые программы с другими требованиями к библиотекам автоматически не работают. В чем отличие, почему это as is работает в Винде и не работает в Линуксе?

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

Вот это я и не понимаю, почему в Винде я не портирую программу чтобы её запустить, а в Линуксе и должен хз что сделать, чтобы запустить программу с большим количеством зависимостей. Тому есть какие-то технические причины и отличия в реализации операционной системы, или просто некая идеология построения библиотек и их зависимостей, в которой мне ничего не положено. Просто по-моему, это очень просто и рационально, скачать и запустить программу, и какие причины могли побудить отказаться от подобного подхода.

Скачивать можно. Для этого надо всего-то зайти на сайт производителя и скачать. Разумеется, если производитель такую сборку сделал ;)

То есть сам разработчик конкретной программы может без проблем слинковать её с нужными библиотеками и распространять в таком "пакете", и тогда она просто будет работать, без возни с зависимостями, но не делает этого по историческим и идеологическим причинам относительно распространения Linux программ?

Я понимаю, что вопросы эти могут быть чайниковыми, для людей хорошо понимающих что, как, и почему, делается в Unix-like системах.

А насчет apt-get, хотелось бы простого шифрования сеанса обновления с сервером. В конце концов все приложения и обновления скачиваются из одного источника (а качать откуда угодно я не могу, ибо пакеты, зависимости :) ) И пусть сервер может посмотреть что обновил и установил, но простой наблюдатель не сможет.
И большего не нужно. А вот если идти дальше, быть анонимным и для сервера, в таком случае уже apt-get через Tor. Как мне кажется (и если я правильно понимаю) в случае с Тором атака человека по середине более вероятна, соответственно при работе со сторонними репозитариями надо будет как-то в ручном режиме проверять аутентичность пакетов.
— Гость (20/03/2015 04:00)   <#>
Не, ну, на самом деле, вопросы правильные, серьёзные и, вообще говоря, не простые. С другой стороны, они ламерские в том смысле, что ответ на них есть, и всё это много где и когда обсуждалось. В стандартных книжках для Linux/UNIX эти вопросы тоже обсуждаются.


На эту тему можно написать обстоятельную статью, но я не так много знаю и не настолько квалифицирован. Можно поставить вопрос, откуда так пошло, почему так сложилось исторически и т.д. — всё это по-своему интересные вопросы, но всё-таки приземлимся до уровня status quo на текущий момент.

Представьте, что у вас есть много всякого разного софта. Вы хотите им оптимально управлять. К примеру, множество софтин зависят от библиотеки libjpeg. Вы можете включить эту библиотеку в каждую софтину, где она нужна, получив, таким образом, сотни её вариантов и версий на ПК, являющихся частью того или иного софта. Однако, можно поступить иначе: поставить одну бибилиотеку одной конкретной версии, а потом весь софт заставить её юзать. Первый способ — Windows, второй — Linux/UNIX.

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

Теперь о плюсах и минусах. Представьте, что в libjpeg нашлась уязвимость. Что нужно сделать на винде? Правильно, переустановить весь софт, выкачав повторно (в общем случае) гигабайты данных. А что нужно сделать в Linux? Обновить один-единственный маленький пакет libjpeg, на который завязано в системе всё и вся. Если вы хотите сделать кастомную, компактную или ещё какую-то специфическую ОС, подход Linux'а также даёт вам свободу в плане достижения оптимума «в системе нет ничего лишнего». Минусы тоже очевидны, вы на них сами указали, трудность инсталляции. На самом деле, это предельные случаи, а в реальности в Linux-методе есть элементы винды, а в винде — элементы Linux'а, так что, например, зависимости в винде у некоторых софтин тоже имеются (как и конфликты с зависимостями), но они обычно немногочисленны.

Вы можете подойти к этому вопросу и иначе. Если кто-то ради вас собрал stand-alone бинарь со всеми вкомпиленными зависимостями (как в TBB), вы его прекрасно запустите в любом Linux, проблем нет. Просто это мало кому нужно, потому что все свой софт пропихивают через пакеты/порты в официальных репозиториях. Представьте на секунду ту же ситуацию под винду: есть исходники нужной версии вашей софтины, а бинаря нет. Ну, вот не сделал его автор для винды, и всё, а сделал только, допустим, для мака. И как вы тогда этот софт на винду поставите? Вам придётся его вручную компилить, попутно устанавливая все необходимые инструменты и библиотеки, которые, в свою очередь, будут тянуть другие инструменты и библиотеки, которые, в свою очередь... ну, вы поняли. Вместо одного проекта вам придётся в итоге установить из исходников их несколько десятков. И, я вам скажу, что эта процедура сборки под виндой будет ещё сложнее, чем аналогичная на Linux.

На самом деле, там всё ещё сложней (как в плане идеологии, так и в плане её реализации), но я вам очертил общие контуры того, откуда берётся различие. Скажем так, в Mac OS X, насколько я знаю, всё точно так же, как в Linux-дистрах: почти все установки идут с официальных репов, а там те версии, какие положили.


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

Есть и обратные примеры, со временем их становится всё больше: какой-то софт создаётся и разрабатывается под Linux. С существенным геморроем его ещё можно как-то водрузить на Mac OS X, пользуясь тем, что последнее — хоть какой-то, но тоже Linux, а вот на винду его установка если возможна, то лишь только теоретически. Инструкции по сборке, компиляции и пр. тоже идут под Linux. Попробуйте по ним сделать аналогично на винде, я на вас посмотрел бы.

Кстати, был проект Lindows или какой-то другой, где пытались то ли сделать отдельные пути для хранения всех файлов каждой софтины в одной директории, то ли отказаться от завязывания всего на одну версию библиотек (сделать всё stand alone)... уже не помню.


Есть «просто для юзера», а есть «просто для разработчика». UNIX никогда не был системой «для людей» — это ОС, «написанная программстами для программистов» ©, поэтому программисты себя в ней чувствуют комфортно и естественно. Вообще, есть UNIX way и его критика, а также принцип «worse is better» и его критика. Делая в UNIX софт и инструменты простыми, вся сложность выдавливается на уровень пользователя, их использующего, а можно было бы делать наоборот, как винде: софт очень умным, чтобы наружу торчало только самое простое. Плюсы и минусы есть у обоих подходов. Например, минус второго подхода (винда) в том, что программа пытается быть умнее пользователя не там, где нужно, из-за чего ему приходится воевать с этой умной автоматикой, которая как нарочно пытается сделать всё по-своему и наоборот. А плюс первого подхода (линукс) в том, что если нужно что-то исправить под свой случай, сделать это проще, т.е. внутренняя логика простая, а поведение компонентов системы легко предсказуемо.


Может, но для него это не будет простым. Есть такое понятие, как среда, в которой разрабатывается софт. Допустим, он пишет под Linux и сам пользуется Linux'ом, тогда он, чтобы протестировать свой же софт, напрягётся и соберёт его под Linux в stand alone (если вдруг ему такой подход близок). Но тут к нему приходит пользователь и просит аналогичный продукт, к примеру, под FreeBSD. А оно разработчику надо — теперь разбираться с этой системой и делать всю аналогичную работу под ней? Возьмите распространённые массовые продукты: TBB под Linux и винду есть, а под BSD нет; stand alone-версии Skype под Linux нет (поэтому хрен запустишь порой), она только под винду; браузер Opera был как под винду с Linux'ом, так и под FreeBSD (разработчики почему-то не поленились это сделать). Бывает, что крупный разработчик заявляет, что та или иная платформа в процентном отношении небольшая (хотя большая в абсолютном), поэтому её поддержку он прекращает, и новые версии под неё выкладываться не будут. По-моему, Adobe что-то такое в отношении Linux недавно сделала.


Самое простое — запускайте его только после запуска VPN.


Я, кстати, не знаю, что apt-get передаёт серверу при обновлении, есть ли там локальный IP-адрес, и как велико количество уникальной информации, позволяющей серверу различать клиентов.


Аутентичность пакетов перед их установкой проверяет сама система по имеющимся PGP-подписям, так что на этот счёт переживать не стоит. Пакеты могут скачиваться откуда угодно, хоть у вашего противника.
— unknown (20/03/2015 10:18, исправлен 20/03/2015 10:19)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664

Хороший пример.


Это кстати, одно из основных преимуществ: браузеры, офисные и графические редакторы, смотрелки файлов, масса всего. В коммерческих системах никто из пользователей выяснять, где эта библиотека используется — не будет. Да там это и достаточно сложно сделать. Также и кто-то из производителей софта может просто на это забить. И дырка останется открытой.


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


Если вы ставите в Linux-систему то, чего в ней нет, то вся ответственность и затраты времени/сил на поддержку этого ложится на вас. В обычном случае — обновился пакет и мэнтейнеры дистра поправили всё от него зависящее. А ваш самосборный пакет может прекратить работать, пока вы не выясните, в чём там дело, сами не исправите или не скачаете новую версию.


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

— Гость (20/03/2015 10:45)   <#>
Собрать и установить пакет из исходников – checkinstall
# ./configure
# make
# checkinstall
— unknown (20/03/2015 11:16)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664
Можно и так.
— Гость (21/03/2015 03:30)   <#>

Пример, кстати, хрестоматийный (как и с libpng) по двум причинам. Первая — в нём действительно нередко находили критические уязвимости, из-за чего его приходилось обновлять. Вторая — на него слишком много завязано. Если кто-то пользуется или пользовался портами, может вспомнить про эпопею «я решил-таки обновить libjpeg с 7-ой до 8-ой версии», из-за чего ему приходится перекомпилить почти весь прикладной софт — занятие на очень много часов, многие пакеты не компилятся, падают с ошибками, требуется ручное вмешательство и т.д.


На этой стадии вылезет туева хуча ошибок о ненайденных зависимостях, о несовместимых версиях, не той версии компилятора и хрен знает чем ещё. Часть из этого бардака будет решаться установкой нужных версий библиотек и инструментов, другая часть — отключением опций configure, так что готовьтесь внимательно его читать. На самом деле, если знать и понимать, как оно там внутри всё устроено, будет понятно, что нет у этой проблемы простого решения. Опрос очень нагляден, кстати.


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


И в итоге собранный пакет не работает, а вы даже не знаете, почему.
— Гость (21/03/2015 03:37)   <#>

Нормальные autotools должны включать в себя ИИ как составную часть:

The idea is that the configure script performs approximately 200 automated tests, so that the user is not burdened with configuring libtool manually. This is a horribly bad idea, already much criticized back in the 1980s when it appeared, as it allows source code to pretend to be portable behind the veneer of the configure script, rather than actually having the quality of portability to begin with. It is a travesty that the configure idea survived.
Ваша оценка документа [показать результаты]
-3-2-1 0+1+2+3