|
| |
| 2.7, tux2002 (ok), 16:52, 29/10/2010 [^] [^^] [^^^] [ответить]
| +/– |
 > помятуя о звуке, а вообще не запретят ?
Я не знаю о чём Вы про запреты, но рут достаточно перегружен обязанностями на десктоп системах. Мне вообще кажется сегодняшнее положение - это натягивание остатков многопользовательской системы на десктоп.
| | |
| |
| 3.25, Michael Shigorin (ok), 22:45, 29/10/2010 [^] [^^] [^^^] [ответить]
| +2 +/– |
 > натягивание остатков многопользовательской системы на десктоп.
Хм, то есть однопользовательская win95 Вам как десктоп ближе?
| | |
| |
| 4.33, НеДобрый Аноним (?), 04:26, 30/10/2010 [^] [^^] [^^^] [ответить]
| +/– |
а там разве хоть что-то работает в контексте пользователя? и вообще есть ли там отличие: пользователь - суперпользователь?
| | |
| 4.39, tux2002 (ok), 20:33, 30/10/2010 [^] [^^] [^^^] [ответить]
| +/– |
>> натягивание остатков многопользовательской системы на десктоп.
> Хм, то есть однопользовательская win95 Вам как десктоп ближе?
Я хотел сказать, что по моему мнению Linux немного не для этого.
| | |
|
|
|
| 1.6, KERNEL_PANIC (ok), 16:51, 29/10/2010 [ответить] [﹢﹢﹢] [ · · · ]
| –1 +/– |
 Ну отлично! Когдато находил в интернете пару трюков взлома через suid. Интересно, на новой технологии действительно безопасно?
| | |
| |
| 2.8, www2 (??), 17:05, 29/10/2010 [^] [^^] [^^^] [ответить]
| +/– |
Надо полагать, что в определённой степени безопаснее, но не безопасно полностью. Например, если раньше, найдя уязвимость в ping, можно было бы получить полный доступ к системе, то теперь можно будет получить только полный доступ к сетевой подсистеме (генерировать любые пакеты и ловить любые пакеты, я так понимаю).
| | |
| |
| 3.9, tux2002 (ok), 17:29, 29/10/2010 [^] [^^] [^^^] [ответить]
| +/– |
Это да. Но я ещё в этом виижу всё таки уход от модели одного суперпользователя к модели с распределением обязанностей. И такие тенденции и попытки в области использования Linux прослеживаются у некоторых людей в Internet.
| | |
| |
| 4.12, Аноним (-), 18:01, 29/10/2010 [^] [^^] [^^^] [ответить]
| +2 +/– |
наконец-то кто-то начал вспоминать о модели безопастности реализованой в Netware-3 :)
| | |
| |
| 5.16, tux2002 (ok), 19:38, 29/10/2010 [^] [^^] [^^^] [ответить]
| +/– | |
> наконец-то кто-то начал вспоминать о модели безопастности реализованой в Netware-3 :)
Я незнаком с NetWare.
Отучение exim от setuid протрахало мне мозг на два месяца.
| | |
| |
| 6.17, tux2002 (ok), 19:45, 29/10/2010 [^] [^^] [^^^] [ответить]
| –1 +/– | |
И теперь наконец я знаю, что настоящий mbox имеет разрешения 602. 2 - щёлочка куда кидает письмо почтальон. 6 - пользователь открывает ключиком. Ну да вы все у себя в подъезде можете посмотреть. exin такое не умеет :(.
Шютка :)!
К чему это я? Ну setuid, работа в группе и т.д. и т.п. это так сзать unix way, хотя кому это нафих нужно, к чему это я?.
| | |
| |
| 7.26, Michael Shigorin (ok), 22:47, 29/10/2010 [^] [^^] [^^^] [ответить]
| –3 +/– |
> И теперь наконец я знаю, что настоящий mbox имеет разрешения 602.
> 2 - щёлочка куда кидает письмо почтальон.
Не 2 (read), а 4 (write).
> 6 - пользователь открывает ключиком.
7, поскольку можно и заглянуть, и взять, и забросить.
> Ну да вы все у себя в подъезде можете посмотреть. exin такое не умеет :(.
Ну посмотрите наконец на postfix и непривилегированный procmail в альте :)
> к чему это я?.
Хороший вопрос.
| | |
| |
| |
| 9.29, ананим (?), 00:47, 30/10/2010 [^] [^^] [^^^] [ответить] | +1 +/– | это не почтальён, а извращенец какой-то любитель подглядывать в щёлочку, но не ... текст свёрнут, показать | | |
|
|
|
|
|
| 4.40, leonid.ko (?), 20:50, 30/10/2010 [^] [^^] [^^^] [ответить]
| +/– |
Вы что-то перепутали тёплое с мягким. Программы не будут иметь возможности использовать ВСЕ права суперпользователя. Сама концепция суперпользователя не изменилась.
| | |
|
|
|
| |
| 2.18, tux2002 (ok), 19:59, 29/10/2010 [^] [^^] [^^^] [ответить]
| +/– | |
> Подскажите, кто знает, а что с pppd они сделали?
Ты прикинь !!! Они дали разрешение группе netdev rw на /dev/ppp!!!!!
| | |
| |
| 3.19, tux2002 (ok), 20:00, 29/10/2010 [^] [^^] [^^^] [ответить]
| +/– |
>> Подскажите, кто знает, а что с pppd они сделали?
> Ты прикинь !!! Они дали разрешение группе netdev rw на /dev/ppp!!!!!
Так грустноооо, что хочется куууурить!
PS я не проверял, но это должно быть около этого.....
| | |
|
| 2.20, tux2002 (ok), 20:02, 29/10/2010 [^] [^^] [^^^] [ответить]
| +/– | |
> Подскажите, кто знает, а что с pppd они сделали?
Вы провоцируете :?) Дак я пьян :)
| | |
|
| 1.13, solardiz (ok), 18:11, 29/10/2010 [ответить] [﹢﹢﹢] [ · · · ]
| +7 +/– |
 В целом, правильно делают. Но первое время это скорее приведет даже к проблемам с безопасностью, чем к их устранению. Дело в том, что SUID-программы, по идее, должны быть написаны с учетом своего такого статуса, но без учета возможных capabilities.
Например, ping сбрасывает root'а как только получит raw socket - даже до анализа опций командной строки. Если же ему вместо root'а дать CAP_NET_RAW, он ее не сбросит, а так и будет с ней работать дальше. В результате возможная уязвимость на этапе после возможного/бывшего сброса root'а приведет не к утечке одного raw socket'а определенного типа (как было раньше), а к утечке всего CAP_NET_RAW (создание произвольных raw sockets, а они бывают разные, и еще кое-что). Т.е. станет чуточку хуже. Это надо исправлять патчем. И так с каждым пакетом. Думаю, они это исправят постепенно.
Да, последствия уязвимостей до бывшего сброса root'а сократятся, но это важно только если SUID-root программ не останется вообще ни одной, т.к. такие уязвимости следует ожидать в ld-linux.so, libc, и ядре, а не в нескольких строках кода в ping.c, которые там шли до сброса root'а. Если же в дистрибутиве все равно оставлять su, sudo и т.п., это теряет смысл. Кстати, традиционный сисадминский подход с заходом под пользователем и использованием su/sudo не выдерживает анализа и критики:
http://www.openwall.com/lists/owl-users/2004/10/20/6
Еще одна проблема - часть capabilities почти эквивалентны root'у. Например,
policycoreutils_setuid.patch на который есть ссылка с Features/RemoveSETUID, раздает cap_setuid,cap_dac_override,cap_sys_admin - ну и чем это отличается от root'а? Тем, что до него надо будет сделать еще один шаг? Впрочем, в случае некоторых уязвимостей, которые не позволяют прям сразу выполнить произвольный код, разница может быть более существенной.
...А еще им надо будет перейти на tcb и отказаться от SUID'а на passwd. :-)
| | |
| |
| 2.15, НеДобрый Аноним (?), 19:07, 29/10/2010 [^] [^^] [^^^] [ответить]
| +/– |
Я думаю что он руководствуются простым принципом: меньше кода - меньше дыр.
Если, например, посмотреть на sendmail, то у него стоит sgid, а дыр в нем находили не мало...
| | |
| 2.24, Аноним (-), 22:22, 29/10/2010 [^] [^^] [^^^] [ответить]
| +/– |
> Еще одна проблема - часть capabilities почти эквивалентны root'у. Например,
> policycoreutils_setuid.patch на который есть ссылка с Features/RemoveSETUID, раздает cap_setuid,cap_dac_override,cap_sys_admin - ну и чем это отличается от root'а? Тем, что до него надо будет сделать еще один шаг? Впрочем, в случае некоторых уязвимостей, которые не позволяют прям сразу выполнить произвольный код, разница может быть более существенной.
это набор capabilites - практически 98% возможностей рута, самое главное хватит что бы загрузить модуль с руткитом в ядро (insmod контролируется cap_sys_admin).
| | |
| 2.35, paxuser (ok), 07:47, 30/10/2010 [^] [^^] [^^^] [ответить]
| +1 +/– |
 > теряет смысл. Кстати, традиционный сисадминский подход с заходом под пользователем и
> использованием su/sudo не выдерживает анализа и критики:
Тут на мой взгляд беда в том, что пользователи (да и многие разработчики) питают симпатии к своим любимым системам и не готовы расстаться со сладкими заблуждениями о безопасности - слишком уж правда горька. И потому по сути бесполезные в плане безопасности ритуалы с sudo и su будут продолжаться.
> http://www.openwall.com/lists/owl-users/2004/10/20/6
Кстати, с тех пор в sudo появилась опция env_reset.
| | |
| 2.38, szh (ok), 14:43, 30/10/2010 [^] [^^] [^^^] [ответить]
| +/– |
 > Если же в дистрибутиве все равно оставлять su, sudo и т.п., это теряет смысл.
ими можно не пользоватся, а в это время capabilities будут делать свою работу.
> часть capabilities почти эквивалентны root'у.
непонятно почему не сделали большее кол-во capabilities, кто мешал сделать 128 штук, кому нужна обратная совместимость если ими все равно никто не пользовался.
| | |
| |
| 3.42, Аноним (-), 10:34, 31/10/2010 [^] [^^] [^^^] [ответить]
| +1 +/– | |
потому что до 2.6.24 на это выделялся ровно один unsigned int (32bit) - позже сделали больше их, но все равно расширенными фик кто пользуется..
в этом отношении более оптимально поступили в FreeBSD - когда rwatson@ закомитил свой аналог capabilites - их сразу было больше 30 и они более равномерно покрывали возможности супер пользователя.
| | |
|
|
| 1.14, Аноним (-), 18:47, 29/10/2010 [ответить] [﹢﹢﹢] [ · · · ]
| +1 +/– | |
Не прошло и 15 лет с внедрения capabilities в ядро, как их начали использовать для полной замены suid'а.
В целом, конечно, очень позитивная новость, жаль только, что для её появления жареному петуху пришлось целый месяц долбить всех по темени. И да, на переносимости скажется :(
| | |
| 1.21, Etch (?), 21:24, 29/10/2010 [ответить] [﹢﹢﹢] [ · · · ]
| +/– | |
> например, делает невозможным эксплуатацию уязвимости в glibc
А вот и нифига, вместо ping в этой уязвимости можно юзать что угодно - sudo в том числе.
| | |
| |
| 2.44, Frank (??), 11:55, 31/10/2010 [^] [^^] [^^^] [ответить]
| +/– |
 Если уязвимость в коде ping, то как вы будете юзать её в sudo? Вот если уявзимость будет в sudo, тогда пожалуйста. Впрочем, сокращение suid'ных файлов ведь уменьшает поле деятельности хакеров, не так ли?
| | |
| |
| 3.47, Etch (?), 08:33, 01/11/2010 [^] [^^] [^^^] [ответить]
| +1 +/– |
Читайте новость по уязвимостям в glibc - там достаточно наличия в системе любой суидной программы, наличие уязвимости в этой программе не требуется.
| | |
|
|
| 1.23, User294 (ok), 22:14, 29/10/2010 [ответить] [﹢﹢﹢] [ · · · ]
| –2 +/– |
 Выглядит неплохо. Только вот какие гарантии что новых дыр не налепят с этими Capabilities? Это они ожегшись на дырах в libc решили так подтянуть гайки?
| | |
| 1.34, paxuser (ok), 07:26, 30/10/2010 [ответить] [﹢﹢﹢] [ · · · ]
| +3 +/– | |
Тенденция хоть и похвальна, но проблему с безопасностью самого ядра дистростроители по-прежнему обходят стороной, а ведь она стоит очень остро. Например, последняя уязвимость в RDS гораздо опаснее уязвимостей в glibc (хотя последние и нагляднее в эксплуатации), поскольку позволяет не только переписать *uid/*gid процесса, но и вернуть его из chroot, из любых namespace'ов, вернуть любые отнятые capabilities, отключить LSM, включая распиаренный SELinux, извлечь криптоключи из памяти ядра так далее. При этом адреса объектов ядра (kallsyms) для заранее собранных ядер известны, а работа со структурами, описывающими процесс, достаточно проста и практически не создаёт рисков обрушения ядра. И таких уязвимостей, по мнение экспертов (включая Дэна Розенберга), в ядре очень много.
Можно стремиться довести безопасность юзерленда до совершенства, и это очень хорошо, но ограничиваясь только юзерлендом, защитить систему на должном уровне не удастся, и это факт.
| | |
| 1.41, ghosthunter (?), 03:58, 31/10/2010 [ответить] [﹢﹢﹢] [ · · · ]
| –1 +/– |
 Читайте пропатченный копипаст этой же новости на ЛОРе, там намного правдоподобнее получилось, это я вам гарантирую ;)
| | |
| 1.43, СуперАноним (?), 11:07, 31/10/2010 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
А, может, не стоило городить в ядре переключение видеорежимов, а X серверу вместо SUID дать CAP_SYS_RAWIO ?
| | |
| |
| 2.45, tux2002 (ok), 17:48, 31/10/2010 [^] [^^] [^^^] [ответить]
| +/– |
> А, может, не стоило городить в ядре переключение видеорежимов, а X серверу
> вместо SUID дать CAP_SYS_RAWIO ?
Я смог запустить X сервер c capabilities только с драйвером vesa. Какие capabilities точно не помню но rawio и что-то с доступом к /dev/kmem и т.п. Сами драйвера требуют чего то большего, я уже не стал разбираться....
| | |
|
|
