LINUX.ORG.RU

В Fedora 15 уже не будет suid-программ

 , , , ,


0

1

Разработчики популярного дистрибутива Fedora приняли концепцию, согласно которой все последующие дистрибутивы их разработки не будут содержать ПО с установленным флагом смены пользовательского идентификатора (suid). По мнению разработчиков, это должно значительно повысить безопасность системы, особенно учитывая уязвимости в glibc. Благодаря отказу от suid эти уязвимости будет невозможно использовать. Планируется, что уже в Fedora 15 таких программ не будет.

Для программ, которым требуются повышенные права для нормальной работы вместо suid будут задействованы capabilities, которые более гибко позволяют выполнять требуемые действия с высокими привилегиями в системе.

Разработчики уже лишили suid для 11 пакетов, на очереди еще 24. Пакеты su, sudo, ksu и userhelper, которые служат для предоставления полных прав пользователю останутся без изменений.

>>> Подробности

> ksu
Ксю — это название пакета? А я думал, это имя такое...

KevinDetry ()

Если они это сделают и пакетов будет достаточно, уйду на федору.

anonymous_sama ★★★★★ ()

> Для программ, которым требуются повышенные права для нормальной работы вместо suid будут задействованы capabilities, которые более гибко позволяют выполнять требуемые действия с высокими приведениями в системе.

Позитивно, снимаю шляпу перед ней же.

n01r ★★ ()

А что за capabilities такие, и чем они лучше suid?

Legioner ★★★★★ ()

Очень правильное направление! Глядишь, и другие подхватят. Молодцы федоровцы.

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

>А что за capabilities такие

Это воооот такенный баян. Но до сих пор нигде толком не применяется.

Zenom ★★★ ()

Пакеты su, sudo, ksu и userhelper, которые служат для предоставления полных прав пользователю останутся без изменений.

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

да и название новости некорректно

wmd ()

Скажем так. Если при suid ядро не проводит вообще никаких проверок - как сказал так и сделал. То capabilities это своего рода настройки уровня доступа к функциям ядра.

Это в двух словах. man capabilities для полного счастья.

fjfalcon ★★★ ()

Ладно насчет suid-бита для рута, а как насчет для пользователя или групп? Как будут решаться проблемы запуска программ, работающих с «железом»? Или эти «capabilities» позволят пользователю nobody работать с конкретным «железом», при этом не давая ему более широких возможностей?

Eddy_Em ☆☆☆☆☆ ()

Давайте еще копипаст про wayland сюда. Вот уж где еды немеряно.

P.S. новости от игнорируемых - это баг или фича?

aidaho ★★★★★ ()

судо и су трогать не будут, а другим я явно и не пользуюсь.

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

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

Eddy_Em ☆☆☆☆☆ ()
Ответ на: комментарий от aidaho

> P.S. новости от игнорируемых - это баг или фича?

После Проверено: anonymous_incognito (31.10.2010 0:39:11)
новость считается освященной, и ее можно увидеть.

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

И как отказ от suid в пользу capabilities помешает сменить пароль?

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

man длинный, лень читать :) А насчет «сменить пароль» - посмотрите права на passwd :)

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

suid на /bin/passwd стоит чтобы можно было писать в /etc/passwd и /etc/shadow. Все остальные права root для этого не нужны. Снимаем suid с /bin/passwd и устанавливаем ему capability «пиливать на владельца файла», не помню как оно точно называется. Получаем то же, что и раньше, но безопаснее.

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

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

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

а чтобы поставить кому-нить capability нужны права root'a?

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

Либо права рута, либо CAP_SETFCAP и быть владельцем файла, либо CAP_SETFCAP и CAP_FOWNER.

Zenom ★★★ ()

Что такое «высокими приведениями в системе»?
Что за приведения?

AnDoR ★★★★★ ()

So ducking what?

KDE/Gnome/X.org/OpenOffice have thousands of bugs.

They duckingly solve least important problems.

tempuser002 ()

>гибко позволяют выполнять требуемые действия с высокими приведениями в системе.

Лишь бы от нас не требовали совершать с привидениями действия сексуального характера. Они слишком высокие для этого и мануала человеческого на эту тему нет, есть только по shadow, но это не то. Кстати, не мудрено, что в Linux ВП завелись: в коде ядра есть код, который убивает детей!

DRVTiny ★★★★★ ()

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

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

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

В hlfs часть файлов была переведена на эти разрешения. Правда, пооваривают что без адаптации могут вылезти новые баги. Убунтовцам, наверное, снова ждать пока нужные патчики примут в апстим)

wyldrodney ()

«Разработчики уже лишили suid для 11 пакетов» - поправь.

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

Можно сделать интереснее - разбить /etc/passwd, /etc/shadow и прочие такие файлы на много маленьких - по файлу на каждого юзера, например /etc/shadow.d/{root,vasya,petya}, и хранить хеши их паролей в этих файлах. Причём владельцем файла /etc/shadow.d/$USER будет пользователь $USER. Тогда можно будет менять свой пароль вообще без повышения привелегий.

Или ещё хитрее - владелец такого файла будет root, а группой - группа из одного соответствующего пользователя, права доступа - 0620.

kmeaw ★★ ()

suid механизм пока что не имеет альтернатив в ряде случаев. Полностью от него не уйти. Разумно сократить - это очевидно нужно.

Hokum ☆☆☆☆ ()

Опять лечат симптомы вместо причины. Надо глибц фиксить, а не от суидов избавляться.

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

> suid механизм пока что не имеет альтернатив в ряде случаев.

Ну-ка, ну-ка, хотелось бы услышать примеры ситуаций, в которых suid root нельзя заменить на file caps.

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

масса legacy, которая, например, тупо проверяет наличие бита и без него работать отказывается

Hokum ☆☆☆☆ ()

Лучше бы они с дебианом высрали один стандартный пакет и сделали утилиту которая собирает его под конфиги ОС. Сколько человеко часов бы спасли.

Andaril ()

Идея конечно правильная но прозреваю огромный гемор для админов. Осталось сюда только роли прикрутить и будет RBAC в чистом виде.

A-234 ★★★★★ ()
Ответ на: комментарий от kmeaw

> Можно сделать интереснее - разбить /etc/passwd, /etc/shadow и прочие такие файлы на много маленьких - по файлу на каждого юзера, например /etc/shadow.d/{root,vasya,petya}, и хранить хеши их паролей в этих файлах.

Поздравляю, вы изобрели http://www.openwall.com/tcb/

Правда, изобретение запоздало лет на 9, но всё равно неплохо :)

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

> Ну-ка, ну-ка, хотелось бы услышать примеры ситуаций, в которых suid root нельзя заменить на file caps.

Рискну предположить: file caps настолько хороши, что с успехом заменят suid даже в вопросе уязвимостей и эксплоитов.

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

>>Рискну предположить: file caps настолько хороши, что с успехом заменят suid даже в вопросе уязвимостей и эксплоитов.

оно конечно так, но получить полный доступ к системе будет несколько проблематичней

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

>масса legacy, которая, например, тупо проверяет наличие бита и без него работать отказывается

Ох, ну просто непреодолимое препятствие. Исходников-то нигде нет.

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

> например /etc/shadow.d/{root,vasya,petya}, и хранить хеши их паролей в этих файлах. Причём владельцем файла /etc/shadow.d/$USER будет пользователь $USER

Не лучшая идея: тогда любой софт, запущенный от имени этого пользователя, сможет выслать хэш его пароля чему-нибудь весьма мощному, и это весьма мощное его расшифрует. Учитывая то, что отдельный пароль на каждую систему придумывать заколебёшься, полученный декодированный пароль скорее всего можно будет использовать не только для входа на скопрометированную систему (что не так уж актуально по сути: для этого достаточно временно поменять пароль юзеру, зайти и сразу поменять его обратно), но и ещё для каких-то хостов. Да, ломать UNIX'овые пароли сложно, но при современных мощностях всё-таки теоретически (?) можно.

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

>что не так уж актуально по сути: для этого достаточно временно поменять пароль юзеру, зайти и сразу поменять его обратно
Сорри, последняя часть про «поменять» явно не канает :)

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

> Думаю, хеши паролей они будут в домашних директориях хранить (как частные ключи ssh).

Не знаю, как в случае с Blowfish, но для MD5 подберу коллизию за 15 минут.

northerner ★★★ ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.