LINUX.ORG.RU
ФорумTalks

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

 , ,


0

3

В продолжение недавней темы Урезаешь ли ты $PATH для обычного юзера, $USER? .

В той теме почему-то никто не угадал почему не стоит расширять $PATH обычного юзера. И я тоже не угадал. И это двойка по информационной безопасности всем нам.

Так вот, из $PATH обычного юзера вырезают /sbin, /usr/sbin и /usr/local/sbin чтобы сильно усложнить жизнь потенциальному взломщику. Если он взломает обычного юзера и повысит привилегии... у него может быть даже обзор системы сильно ограничен при таких настройках. Не говоря уже о том, что ему будет сложнее выполнять бинарники из sbin'ов с уже повышенными им привилегиями.

А чем вредно для секурности sudo? Например, этим:

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

Поэтому su лучше чем sudo, а отсутствие /sbin, /usr/sbin и /usr/local/sbin в $PATH обычного юзера лучше чем их наличие там. Такова серьёзная секурность.

★★★★★

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

сильно

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

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

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

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

saahriktu

как всегда

t184256 ★★★★★
()
Ответ на: комментарий от voltmod

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

saahriktu ★★★★★
() автор топика
Ответ на: комментарий от Dimez

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

saahriktu ★★★★★
() автор топика

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

Классика.

Говорят

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

token_polyak ★★★★
()
Ответ на: комментарий от firkax

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

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

<keybind key="W-F">
  <action name="Execute">
    <command>xsudo -u me-librewolf /usr/bin/librewolf</command>
  </action>
</keybind>
dimgel ★★★★★
()
Ответ на: комментарий от token_polyak

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

saahriktu ★★★★★
() автор топика
Ответ на: комментарий от token_polyak

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

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

saahriktu ★★★★★
() автор топика
Ответ на: комментарий от token_polyak

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

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

?

saahriktu ★★★★★
() автор топика
Ответ на: комментарий от saahriktu

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

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

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

cumvillain
()
Ответ на: комментарий от saahriktu

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

token_polyak ★★★★
()

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

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

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

urxvt ★★★★★
()

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

leave ★★★★★
()
Ответ на: комментарий от snizovtsev

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

saahriktu ★★★★★
() автор топика

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

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

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

MKuznetsov ★★★★★
()
Ответ на: комментарий от MKuznetsov

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

saahriktu ★★★★★
() автор топика
Ответ на: комментарий от saahriktu

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

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

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

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

MKuznetsov ★★★★★
()

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

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

sergej ★★★★★
()
Ответ на: комментарий от MKuznetsov

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

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

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

saahriktu ★★★★★
() автор топика
Ответ на: комментарий от saahriktu

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

Как ? пример

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

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

MKuznetsov ★★★★★
()
Ответ на: комментарий от MKuznetsov

Как ? пример

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

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

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

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

saahriktu ★★★★★
() автор топика
Ответ на: комментарий от saahriktu

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

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

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

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

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

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

MKuznetsov ★★★★★
()
Ответ на: комментарий от MKuznetsov

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

saahriktu ★★★★★
() автор топика
Ответ на: комментарий от bugfixer

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

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

saahriktu ★★★★★
() автор топика
Ответ на: комментарий от bugfixer

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

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

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

saahriktu ★★★★★
() автор топика
Ответ на: комментарий от saahriktu

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

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

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

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

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

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

bugfixer ★★★★★
()
Последнее исправление: bugfixer (всего исправлений: 2)
Ответ на: комментарий от bugfixer

А её и нет.

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

saahriktu ★★★★★
() автор топика
Ответ на: комментарий от saahriktu

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

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

bugfixer ★★★★★
()
Ответ на: комментарий от saahriktu

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

snizovtsev ★★★★★
()
Ответ на: комментарий от snizovtsev

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

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

snizovtsev ★★★★★
()

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

Daedalus
()
Ответ на: комментарий от Daedalus

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

altwazar ★★★★
()
Последнее исправление: altwazar (всего исправлений: 1)

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

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

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

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

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

[hr]

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

CrX ★★★★
()
Ответ на: комментарий от snizovtsev

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

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

CrX ★★★★
()
Ответ на: комментарий от saahriktu

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

CrX ★★★★
()
Ответ на: комментарий от CrX

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

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

bugfixer ★★★★★
()

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

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

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

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

Aceler ★★★★★
()

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

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

Aceler ★★★★★
()
Закрыто добавление комментариев для недавно зарегистрированных пользователей (со score < 50)