Оказывается, sudo и расширенный $PATH юзера - потенциальные уязвимости

из $PATH обычного юзера вырезают /sbin, /usr/sbin и /usr/local/sbin чтобы сильно усложнить жизнь потенциальному взломщику

сильно

Как Орбит Надувная Гантеля. Может записать в /usr/local/bin? Может и в /usr/bin.

существует временной отрезок, в течение которого повторное выполнение команды sudo не требует пароль (что удобно для взлома вашего компьютера со стороны rootkits и хакерских атак).

Поэтому su лучше чем sudo

Если sudo пользоваться, то безопасность sudo с паролем и таймером == безопасность sudo с паролем и без таймера == безопасность sudo вообще без пароля. Поломан судоер — поломано все.

saahriktu

как всегда

export PATH=/sbin:/usr/sbin:/usr/local/sbin:$PATH вот и конец всей твоей секурности

Ну так до этого-то секурность выше. А до понижения секурности таким способом дело может и не дойти по разным причинам. Если взломает человек, то он, конечно, может догадаться так сделать. А если взломает какой-нибудь скрипт? Он может и поломаться на том, что какая-нибудь команда не выполнится как предполагалось его автором.

Не понял каким боком оно добавит уязвимостей для sudo, но sudo в любом случае не нужно.

Аргументы, честно говоря, сильно высосаны из пальца.

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

После выполнения sudo существует временной отрезок, в течение которого повторное выполнение команды sudo не требует пароль (что удобно для взлома вашего компьютера со стороны rootkits и хакерских атак).

Классика.

Говорят

Пусть говорят. А тебе зачем ретранслировать этот бред?

sudo в любом случае не нужно.

$ vi ~/.config/openbox/rc.xml

<keybind key="W-F">
  <action name="Execute">
    <command>xsudo -u me-librewolf /usr/bin/librewolf</command>
  </action>
</keybind>

Говорят серьёзные наследники стандартов Openwall. Участники той команды, где они теперь работают.

Очнись, какие ещё «стандарты» у наколенной поделки 3,5 админа.

Патчи и расширения безопасности Openwall были включены во многие основные дистрибутивы Linux. ... LWN.net рассмотрел Openwall Linux 3.0[5]. Здесь было написано:

Первый вопрос, который будет у большинства людей — это: «Что такое «усиленная безопасность» о Owl? Не являются ли основные дистрибутивы Linux, такие как Red Hat Enterprise Linux, Ubuntu, openSUSE и т. д. безопасными? Конечно, они постоянно исправляют известные уязвимости безопасности, а некоторые из них (в частности, Red Hat) реализуют функции безопасности для снижения воздействия уязвимостей, но ни одна из них не направлена прежде всего на то, чтобы предотвратить попадание уязвимого программного обеспечения в дистрибутив.

Не всем нужен дроч на чье-то (не)былое величие.

Дык если они были великими, значит у них были хорошие стандарты. Ну и вот.

Так не были ведь.

А почему тогда

Патчи и расширения безопасности Openwall были включены во многие основные дистрибутивы Linux.

?

А почему тогда

Патчи и расширения безопасности Openwall были включены во многие основные дистрибутивы Linux.

Потому что засунуть патчи в Linux kernel это не то чтобы большая сложность.

Потому что в дистрибутиве Openwall они никому не сдались 8-)

Сначала я ничего не понял.

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

А потом как понял...

В чём усложнение взломщику то? Лишние 10 символов полного пути писать?

У меня ощущение, что я прочитал статью из журнала ксакеп образца года эдак 2003

Ну давай позовем solardiz и спросим его мнение

Я не против.

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

root машины типичного пользователя не интересен «взломщикам» и прочим злодеям.

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

а всё что скрывается в /sbin /usr/sbin носят с собой, в одном busybox, чтобы не отсвечивать по журналам.

В том и суть, что на машине в /usr/sbin может быть что-то ещё помимо того, что входит в busybox'ы. И, да, тема больше про корпоративные стандарты информационной безопасности. И юзер, конечно, может выбрать не соответствовать им. Но если мы говорим про серьёзную секурность, то вот.

на машине в /usr/sbin может быть что-то ещё помимо того, что входит в busybox

например ? что такого нужного может быть в /usr/sbin чего не может быть в busybox … если только очень забывчивый хакир попадётся. Или он не знает зачем пришёл.

в busybox может входить всё. Он-же расширяемый :-) И точно есть tcc - си-компилер.

И на всех современных машинах уже есть Python…вот это вот дырищща: на 99.999% машин стоят средства разработки.

Меж тем The LINUX File System Standard явно пишет

Запрещение /sbin для пользователей не дает никакого преимущества с точки зрения безопасности.

что такого нужного может быть в /usr/sbin чего не может быть в busybox

Например, https://httpd.apache.org/docs/2.4/en/programs/apachectl.html .

Тем более, что могут быть ситуации, когда взломщик не знает точно что именно установлено на машине.

Тем более, что могут быть ситуации, когда взломщик не знает точно что именно установлено на машине.

Как ? пример

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

Их(полномочия) вообще повышать ненадо, современный Linux - де-факто однопользовательская машина. Всё что может потребоваться злодею, он вполне может делать под твоей учёткой не трогая sudo.

Как ? пример

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

Я не знаю как именно, я не настолько специалист по информационной безопасности.

с командной строкой

Взломы бывают разные. Взломщик может и не получить доступ к полноценному терминалу, только возможность выполнять команды через system().

Про PATH и безопасность - откровенный бред.

выполнять команды через system().

это типа конкурс - за сколько минут админ средней подготовки получит полноценный комманд промпт ? :-)

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

но вот только есть /sbin в путях, нету ли его, никак не влияет; его убирали для :

a) чтобы рядовому пользователю было чуть сложнее отстрелить себе пятку. Принуждали вдумчиво вбивать /sbin

b) чтобы сложнее было отснифить пароль рута - чтобы команды требующие ввода пароля можно было запускать только по абсолютному пути. Иначе если в $PATH первым попадёт /home/vasyan/bin/su он может прикинуться штатным su

Одни меры по безопасности не отменяют другие.

Про PATH и безопасность - откровенный бред.

Какие курсы по безопасности кода Вы заканчивали?

Какие курсы по безопасности кода Вы заканчивали?

Жизненные (долгие и долгие годы практики, так скажем).

У меня тоже такие же. Я тоже прямую связь не очень-то и вижу. Но более опытные и образованные люди говорят, что она есть. Что потенциального взломщика это всё же ограничит.

Вообще, судя по теме, люди дальше взлома последствия не особо-то и оценивают. Типа, если взлом состоялся, то уже всё равно.

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

Я тоже прямую связь не очень-то и вижу

А её и нет. Спасёт максимум от «мамкиных кулхацкеров». Я сильно больше одного способа вижу как это обойти, начиная с того что ничего не мешает выставить свой PATH.

Вообще, судя по теме, люди дальше взлома последствия не особо-то и оценивают.

Я не уверен что у Вас в принципе выработалась адекватная оценка рисков уже.

Но на этих самых курсах

Хех. Без комментариев.

А её и нет.

Суть такова, что /bin, /usr/bin и /usr/local/bin - стул обычного юзера, а /sbin, /usr/sbin и /usr/local/sbin - стул root'а. Если они вместе в $PATH обычного юзера, то он сидит на двух стульях, и на этих же двух стульях сразу же окажется взломщик. А если там нет /sbin, /usr/sbin и /usr/local/sbin, то этот самый стул root'а ему ещё потребуется добыть. Да, полные пути никто не отменял, но, по ходу, не всё так просто как кажется на первый взгляд.

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

Господи, Боже мой. Что Вы курите? Я тоже такое хочу…

Мне кажется суть лишь в том, чтобы tab completion юзера не показывал лишнего. Может быть ещё удобно для написания каких-нибудь политик apparmor/selinux.

И на всех современных машинах уже есть Python

У Iron_Bug не стоит. :)

Хотя, кажется, понял как это можно связать с безопасностью.

Типа sudo должен изменить PATH=/usr/sbin:$PATH, чтобы админские утилиты шли первыми, и не подменялись левыми из каких-нибудь пользовательских virtualenv. А если сделать PATH=/usr/bin:$PATH, то слишком много бинарей поменяют порядок и может сломаться какая-нибудь полезная логика.

Видел такое в Debian и сам полез исправлять это, прописав «export PATH=$PATH:/usr/sbin» в ~/.bashrc. А то у меня много команд не работало нормально без прописывания полного пути к бинарнику, что дико не удобно и не привычно мне показалось.

Скоро везде всё будет в одной бин директории и проблема с PATH отпадёт сама собой.

Это полнейший бред, и никакой уязвимости тут нет. $PATH контроллируется юзером, поэтому если потенциальный злоумышленик получил доступ к юзеру, ничто, совершенно ничто не мешает ему добавить в $PATH всё, что ему хочется, включая /sbin. Нет, ему не будет сложнее выполнять бинарники из sbin’ов, ничуть.

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

Поэтому su лучше чем sudo

Нет. Эта фича опциональна и при необходимости (например комп на работе с доступом других людей, если отлучился) её можно отключить.

Пароль там не требуется не для sudo вообще, а в текущей сессии шелла (запусти второй терминал, уже будет требовать. хотя в том, где ввёл, не требует, не говоря уж об ssh).

[hr]

Короче, учи матчасть и не надо больше 4.2

В чём усложнение взломщику то? Лишние 10 символов полного пути писать?

он, пока будет писать export PATH="/usr/sbin:/sbin:$PATH", переутомится, напьётся и забудет, что хотел хакать. На это надежда у автора походу.

Это не стандарты безопасности, это псевдобезопасность курам на смех. К реальной безопасности этот цирк имеет столько же отношения, как закрывание глаз, чтобы человек, идущий на тебя с ножом «пропал». Хотя наверное для запудривание мозгов начальству подойдёт. Только вот опасная это тема — играться с иллюзиями безопасности. Лучше, когда ничего не делается (и соответственно есть какое-то ощущение, что может быть небезопасно), чем когда делаются бесполезные ритуалы, вызывающие ложное чувство безопасности и усыпляющие бдительность, но на практике ничего не дающие.

он, пока будет писать export PATH=«/usr/sbin:/sbin:$PATH», переутомится, напьётся и забудет, что хотел хакать. На это надежда у автора походу.

Как же Вы могли про «курсы» забыть?? Там же наверняка много ещё чего интересного рассказывают… А за кровно заработанные - так особенно ;))

Не говоря уже о том, что ему будет сложнее выполнять бинарники из sbin’ов с уже повышенными им привилегиями.

Да, без /sbin в $PATH выполнять бинарники через sudo с повышенными привилегиями намного сложнее. Очень намного. Аж прямо почти невозможно. Хакер плачет и уходит домой.

Такова серьёзная секурность.

Ты вообще зачем этот бред написал? sudo никогда не пользовался, да?

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

Только вот беда, надо сидеть на том же терминале.