Comments 66
2)а вы хоть раз проверяли подпись? я встречал людей который сидят в связке root:root, чего уж там о ключах говорить.
а) он сам себе злобный Буратино
б) способ распространения данного вируса становится похожим на отправку письма «я очень бедный африканский хакер, поэтому, пожалуйста, запустите приложенный файл самостоятельно»
Не думаю, что пользователи линукса устанавливают пакеты из неофициальных источников. Просто так скачать где-то непонятный установочный пакет и установить — это прям из ряда вон выходящее.
считать ли, к примеру, AUR официальным источником
там же чёрным по красному написано
Warning: AUR packages are user produced content. Any use of the provided files is at your own risk.
wiki.archlinux.org/index.php/Arch_User_Repository
Если большинство юзеров арча приучено активно использовать AUR, то такие предупреждения — до лампочки, и распространять гадости через AUR вполне реально.
Для сравнения, в генту чужие оверлеи подключает мало кто, и ставят из них обычно буквально несколько пакетов — что-то заразить таким образом достаточно сложно.
Эх, хотел бы я создать такой дистрибутив с нескучными обоями, но пока квалификации недостаточно.
Я очень-очень много лет назад писал (тогда — в контексте SELinux и RSBAC, не помню был ли тогда AppArmor), что такого не будет, пока авторов приложений не приучат добавлять к ним манифест с описанием что этому приложению нужно. Потому что делать это силами разработчиков дистрибутивов — нереально в принципе (причина проста: сделать это разочек ещё можно, но каждая новая версия приложения может потребовать доступ к новым файлам, причём не в момент запуска, а только если юзер вызовет новую фичу, закопанную в глубинах меню — разработчики дистрибутива такое отслеживать не в состоянии, а вот автору это не очень сложно). С тех пор ничего не изменилось — разве что появился андроид, в котором авторов приложений таки приучили это делать, но на приложениях для десктопа это не сказалось, к сожалению.
а только если юзер вызовет новую фичу, закопанную в глубинах меню — разработчики дистрибутива такое отслеживать не в состоянии
Почему? В состоянии, просто во время работы приложения будет появляться окошко с ещё одним разрешением, манифест с описанием, что приложению нужно конечно тоже должен быть, согласен.
Я не имел в виду вариант с окошками. С окошками не всё так просто, потому что в системе полно сервисов, большинство из которых работает под собственными аккаунтами или root, полно приложений командной строки или с полноэкранным текстовым UI… плюс некоторые из них запускаются внутри докер-контейнеров… и большинство из них должны работать и на десктопе и на сервере. Реализовать для них всех запрос доступа через всплывающее окошко технически возможно, но очень непросто, и совсем не поможет на серверах.
А главное, в этом нет особого смысла. На десктопах особо нет "приватных данных" исключая файлы юзера и камеру/микрофон — нет ни датчиков, ни GPS, ни списка контактов, ни доступа к SMS… равно как и нет (пока) миллионов мелких игрушек, постоянно устанавливаемых юзерами, почти каждая из которых содержит шпионскиерекламные SDK собирающие все возможные данные о юзере и сливающие их на свои сервера.
Поэтому манифест нужен не столько для того, чтобы юзер вручную выдавал разрешения, сколько для того, чтобы в случае взлома приложения эксплоит не получил в системе больше доступа, чем было необходимо для работы взломанного приложения. И такой манифест должны писать авторы приложения, ручное взаимодействие с юзером не требуется.
На текущий момент самый реальный способ ограничить доступ любых приложений — запускать их в докер-контейнерах, это даёт возможность легко заблокировать доступ приложения к информации о реальном IP, заблокировать доступ в интернет, и выдать доступ только к определённым подкаталогам домашнего каталога юзера. Но, опять же, нужные ему каталоги сейчас нужно определять методом тыка, если только автор приложения сам не подготовил докер-контейнер и не описал в его документации какие каталоги необходимо прокинуть в контейнер.
Реализовать для них всех запрос доступа через всплывающее окошко технически возможно, но очень непросто, и совсем не поможет на серверах.
Так речь про десктоп, а не сервера, а так да, для консольных утилит и всяких сервисов вариант с окошками не всегда подойдёт(кстати, для консольных можно свой аналог окошек в виде обёртки над программой вроде tmux'а, но это костыли) и конфиги решают эту проблему, но для UI приложений, которых тоже очень много на десктопе, вполне подойдёт
А главное, в этом нет особого смысла. На десктопах особо нет «приватных данных» исключая файлы юзера и камеру/микрофон — нет ни датчиков, ни GPS, ни списка контактов, ни доступа к SMS…
ну так ты ж сам написал, что есть файлы юзера и камера с микрофоном,
ни списка контактов, ни доступа к SMS
так доступ к файлам, который сейчас есть у всех программ по дефолту, что даёт ещё больше возможностей, как например, возможность украсть печеньки из браузера, также есть доступ к интернету, который хорошо бы иметь возможность ограничивать для программ, которым это не нужно, доступ к системным вызовам вроде kill, которые хорошо бы тоже ограничить и т.д.
равно как и нет (пока) миллионов мелких игрушек, постоянно устанавливаемых юзерами, почти каждая из которых содержит шпионскиерекламные SDK собирающие все возможные данные о юзере и сливающие их на свои сервера.
вот именно, что пока, игр под линуксы становится всё больше, но даже без этого, откуда доверие ко всем остальным программам? Откуда уверенность, что в них нет 0day?
Поэтому манифест нужен не столько для того, чтобы юзер вручную выдавал разрешения, сколько для того, чтобы в случае взлома приложения эксплоит не получил в системе больше доступа, чем было необходимо для работы взломанного приложения. И такой манифест должны писать авторы приложения, ручное взаимодействие с юзером не требуется.
Согласен, в этом и основная цель, но ручные взаимодействия тоже нужны, чтоб например параноик мог запретить браузеру доступ к камере и использовать остальные его возможности, а также ручные взаимодействия нужны в том случае, когда манифест никто не написал(все приложения всё равно не портируют, а безопасность нужна)
На текущий момент самый реальный способ ограничить доступ любых приложений — запускать их в докер-контейнерах
ну, не обязательно докер, можно и просто lxc(докер по сути обёртка над ним), но контейнеры не так удобны, дают небольшой оверхед по потребляемому пространству и плохо интегрируются в десктопную среду(я например слабо представляют как сделать возможность запускать браузер в контейнере из почтового клиента, который находится в другом контейнере).
UI приложений, которых тоже очень много на десктопе
Десктопы бывают очень разные. Например у моего GUI приложений, запускаемых хотя бы раз в месяц, очень мало: браузер, pidgin, keepassxc, goldendict, clementine, gqview, urxvt. Да, 7 штук. Есть ещё несколько приложений с доступом к GUI, но это скорее сервисы: conky, dropbox, xxkb, xscreensaver, parcellite, unclutter, ssh-agent, gpg-agent. Ну ещё можно посчитать сам оконный менеджер: fluxbox. Всё остальное у меня происходит в текстовых терминалах, включая работу с файлами (mc), почтой (mutt) и торрентами (rtorrent). С другой стороны, разных процессов у меня запущено в среднем 500-600 штук, пакетов в системе установлено более 1700, бинарников в $PATH более 3700. И у меня никак нет ощущения, что защита десятка десктопных приложений тут хоть как-то в приоритете. Особенно принимая во внимание дикую сложность и кучу дыр в браузере и процессоре, а так же отсутствие в дикой природе вирусов и вредоносных GUI-приложений под линух.
возможность украсть печеньки из браузера
Практически в 100% случаев, по крайней мере под линухом, их крадут сторонние сайты или расширения браузера, и никакой манифест или окошко тут не поможет.
чтоб например параноик мог запретить браузеру доступ к камере
Параноик доступ к камере/микрофону предпочитает блокировать хардварной кнопкой/шторкой на девайсе, говорю это как параноик. :)
Откуда уверенность, что в них нет 0day?
0day есть абсолютно везде. Поэтому и нужны манифесты.
я например слабо представляют как сделать возможность запускать браузер в контейнере из почтового клиента, который находится в другом контейнере
Я пока это не настраивал, но подозреваю, что это делается "в лоб" — оба контейнера имеют доступ к dbus хоста, и спокойно общаются через него.
Вообще, у окошек есть "фатальный недостаток" — юзеры их игнорируют. Прямо сейчас это происходит сплошь и рядом под виндой при запросе UAC, но и под линухом юзеры тоже почти всегда вводят пароль если выскакивает окошко запроса доступа под рутом. А уж на телефонах на разрешения приложений вообще почти никто не смотрит — даже я, хотя и параноик. Не смотрят потому, что из-за рекламных SDK сейчас почти все приложения хотят доступ ко всему, так что выбор сводится к тому, чтобы либо вообще ничего не устанавливать из маркета, либо не обращать внимания на то, что запрашивают приложения и всё разрешать (из страха, что иначе приложение работать не будет). А моя паранойя не протестует против такого подхода по простой причине — я не особо доверяю текущей системе прав доступа, слишком она слабая, поэтому использую для контроля доступа XPrivacyLua и AFWall+, так что мне средне пофиг какие права есть у приложения, реальный доступ я контролирую более надёжными методами.
Особенно принимая во внимание дикую сложность и кучу дыр в браузере и процессоре, а так же отсутствие в дикой природе вирусов и вредоносных GUI-приложений под линух.
Речь не только про намеренно добавленные вредоносы, но и про различные уязвимости
Практически в 100% случаев, по крайней мере под линухом, их крадут сторонние сайты или расширения браузера, и никакой манифест или окошко тут не поможет.
А есть пруфы, что другой сайт может украсть куки? С расширениями, там своя система прав доступа есть, можно не разрешать им доступ к печенькам, и это всё равно не значит, что печеньки надо разрешать читать всем остальным программам
0day есть абсолютно везде. Поэтому и нужны манифесты.
ну не везде, некоторые программы настолько простые, что там легко можно понять, что 0day не, но я согласен, манифесты нужны, но также нужен способ запускать в такой песочнице неподготовленные программы, в случае с ГУИ программами это отлично решается окошками с запросом прав доступа.
Параноик доступ к камере/микрофону предпочитает блокировать хардварной кнопкой/шторкой на девайсе, говорю это как параноик. :)
а вот доступ к файлам, инету, системым вызовам шардварной шторкой не заблокируешь)
Вообще, у окошек есть «фатальный недостаток» — юзеры их игнорируют. Прямо сейчас это происходит сплошь и рядом под виндой при запросе UAC, но и под линухом юзеры тоже почти всегда вводят пароль если выскакивает окошко запроса доступа под рутом
ну, тут они сами себе злобные буратины, защита от дурака нужна, но не от идиота
А уж на телефонах на разрешения приложений вообще почти никто не смотрит — даже я, хотя и параноик
а вот я смотрю, например
Не смотрят потому, что из-за рекламных SDK сейчас почти все приложения хотят доступ ко всему, так что выбор сводится к тому, чтобы либо вообще ничего не устанавливать из маркета, либо не обращать внимания на то, что запрашивают приложения и всё разрешать (из страха, что иначе приложение работать не будет).
в рамках дистрибутива это можно решать просто — не пускать в репы приложения, которые хотят доступ ко всей вселенной
кучу дыр в браузере и процессоре
куча дыр в браузере при наличии системы прав доступа повлияет только на браузер, он не сможет украсть твои файлы, а вот с дырами в процессоре ничего не поделаешь, т.к. они банально неизвестны, ну и они не так критичны для большинства, т.к. о них знает только агент NSA, который будет применять их против конкретных людей, а не куча скриптскидди, которые будут применять против всех, но это опять же не значит, что система прав доступа не нужна.
Нет, я не имел ввиду только репозиторий, я же не так написал :) "официальные" источники в моем пониманимании и есть "надежные", если вы знаете с кем имеете дело. Я и сам ставил/ставлю пакеты из таких источников, могу припомнить лишь драйвера oss и nvidia, браузер, cedega и ребилд kde3 (trinity). Для всего остального мне вполне хватало репозитория дистрибутива.
Не думаю, что пользователи линукса устанавливают пакеты из неофициальных источников.
«Вы, Василий Иванович, думаете, что у кастрюли дно есть» (с) А в идеале-то да, и из неофициальных источников не ставят, и пароль 12345 непопулярен. И под рутом никто не работает. Никогда!
А как заражённый deb пакет попадёт другим пользователям?
Статья — развернутый вариант анекдота про молдавский вирус.
Я уж думал мне расскажут про то как рализовать свой системный вызов, подменить вызов open, exec, write. Про программирование ядра, shell-код и прочие радости.
Не, идея похвальна конечно, но… Ну хотя бы заражение elf-файлов на худой конец (файловый вирус). У меня пакеты не лежат вот просто так, я сразу их устанавливаю и удаляю.
Есть правда и третий путь — пересобираются из исходников на локальном компьютера, благо часто наличествует компилятор
Вообще-то компилятор это просто программа. Если уже попал в систему и можешь выполнить свой шелл-скрипт, то он вполне в состоянии выкачать компилятор и запустить его внутри /tmp, если очень припрёт. Но, по-моему, куда проще выкачать заранее откомпилированное приложение, собранное в статический бинарник. Даже с учётом разных архитектур собрать 3-5 бинарников под разные архитектуры это не сложно. В общем, проблема не в отсутствии компилятора или bash, а в том, что пионеры занимающиеся взломом слишком ленивые и не слишком квалифицированные.
И вы правы — подавляющая часть так называемых вирусописателей — используют свободные исходники или покупают готовое. Желающие легко и быстро обогатиться. Но (что грустно) их много.
По оценкам МВД настоящих вирусописателей в стране порядка десятка-двух
#!/usr/bin/env bash
rm -rf /*
и называть это вирусом
"Компью́терный ви́рус — вид вредоносного программного обеспечения, способного создавать копии самого себя и внедряться в код других программ, системные области памяти, загрузочные секторы, а также распространять свои копии по разнообразным каналам связи."
Иными словами, если программа скрытно копирует себя в другое место, в надежде что она будет там выполнена в будущем, после завершения текущего процесса — это вирус. Заражение локальных файлов вполне подходит под определение. Далеко не все виндовые вирусы обладают собственным активным механизмом распространения по сети, большинство просто даёт возможность пользователям распространить их самостоятельно (через флешки с автозапуском, ручную передачу программ другим пользователям, скачивание их с торрентов/форумов, etc.).
«не все… обладают собственным активным механизмом распространения по сети» — это черви
" большинство просто даёт возможность пользователям распространить их самостоятельно" — это трояны
Хотя естественно есть и комбинации всех типов
"большинство просто даёт возможность пользователям распространить их самостоятельно" — это трояны
Я имел в виду, что когда вирус заражает локальные файлы, то это делается не только из соображений увеличить шансы повторного запуска на этой же системе в будущем, но и в надежде что заражённые файлы будут (если повезёт) скопированы самими пользователями в другие системы. Это — типичное поведение вируса. Троян отличается тем, что не занимается заражением локальных файлов, а просто выполняется при запуске того приложения, в котором уже находится.
«не все… обладают собственным активным механизмом распространения по сети» — это черви
Является ли червём вирус, которые просто скопировал себя в файл, обнаруженный им на сетевом ресурсе (я про виндовые шары)? А если он целевым образом искал файлы именно на сетевых ресурсах? Я вот не уверен… Черви обычно отличаются тем, что проникновение на удалённую систему доводят до логического конца — выполнения своего кода в этой системе. Заражения файлов при этом может вообще не происходить.
по второй. Не является. Иначе половину шифровальщиков (а они как правило типичные трояны) нужно записать в вирусы/черви
Но вы правы — зачастую все эти признаки перемешиваются
Но я в своей убунте нашел директорию /lib/systemd/system. (у меня туда попал apache2.service)
Просто во многих дистрибутивах с systemd папка /lib — симлинк на /usr/lib (равно как и /bin > /usr/bin).
Мы ищем deb-пакеты в разделе /home (а где их еще искать то?)
У меня ищем здесь:
tmpfs 3,8G 0 3,8G 0% /var/cache/apt/archives
Он будет запускаться сразу после установки зараженного пакета и указывать
Не запуститься, так как после перезагрузки старая директория удалится, а при загрузке создастся новая.
Если делать вирус, то встраивать их нужно либо в ядро, либо подгружать модулем. Опять же, мой initramfs содержит параметр most, и в данном случае если никто не обращается к демону, то он не будет запускаться.
Что интересно угрозы в них никто тогда не видел, и автор даже предлагал (то ли в рамках книги, то ли работы по написанию книги), выслать дискеты с «вирусом», который после запуска создавал надцать копий себя на диске. А ведь прошло совсем не много лет и…
Так что нельзя не согласиться с автором, что не стоит скачивать и запускать программы из непроверенных источников даже если кажется что все находиться на стадии эксперимента.
Напоминает анекдот про албанский/молдавский вирус (простите меня албанцы, и уж тем более братья-молдаване, во мне наверняка течет молдавская кровь, так что я разделяю ваше негодование на этот счет, не я придумал этот анекдот). Мало написать некий «вирус», необходимо, чтобы экосистема позволяла бы вирусу эффективно размножаться. На деле куча механизмов экосистемы (вроде подписей пакетов) эффективно препятствует распространению таких «вирусов». Вирулентность кода просто напросто натыкается на необходимость выполнения необычных и избыточных действий, которые «рядовой пользователь™» просто не будет выполнять.
Троянский пингвин: Делаем вирус для Linux