| |
| |
| |
| |
| |
| |
| |
| 7.64, пох, 16:36, 20/06/2017 [^] [ответить] [смотреть все]
| +/– | |
тут я не уверен, что оно a) вообще нужно в libc (любое добавление кода ломает совместимость) b) все чисто с лицензией. Проблема явно может быть решена вне libc, отдельной libopenbsdgoodfeature.so
btw, интересно, сложно ли сделать в ядре для suid-files аналог "link if owner match" - позволило бы перекрыть класс эксплойтов а-ля sudo (в которой и аналогичных бинарниках, по-моему, вообще имело бы смысл проверять собственное имячко, и сегфолтиться при любом его отличии от %PREFIX/sudo) - я вот не могу представить себе ситуации, когда легитимному пользователю понадобился бы линк на сетуиденый бинарь, хоть символический, хоть хард. (разьве что где-нибудь в треш-окрестностях user namespaces, но там пусть у их изобретателей голова болит)
|  | | |
| |
| 8.66, добрый, 17:16, 20/06/2017 [^] [ответить] [смотреть все]
| +/– |
> тут я не уверен, что оно a) вообще нужно в libc (любое
> добавление кода ломает совместимость) b) все чисто с лицензией. Проблема явно
> может быть решена вне libc, отдельной libopenbsdgoodfeature.so
Если не в libc, то никак не в библиотеке, которая будет подгружаться уже после обработки части переменных окружения в раннем коде ld.so, где уже были уязвимости: http://seclists.org/fulldisclosure/2010/Oct/257
> btw, интересно, сложно ли сделать в ядре для suid-files аналог "link if
> owner match" - позволило бы перекрыть класс эксплойтов а-ля sudo (в
fs.protected_hardlinks?
| | | |
| |
| 9.67, пох, 17:42, 20/06/2017 [^] [ответить] [смотреть все]
| +/– | |
> fs.protected_hardlinks?
эта фича, в том виде в котором была обнаружена в rhel, не проверяет su/gid биты (зато, зачем-то, write access) - и в таком виде, очевидно, небезвредная. В результате именно на системе с многими локальными пользователями рано или поздно тебе ее придется отключить.
с симлинками она вообще нечто непонятное делает (в смысле, непонятно, зачем такое нужно), совершенно не мешая сделать симлинк на sudo.
ненене, не надо нам такой уличной магии.
| | | |
| 9.68, пох, 17:50, 20/06/2017 [^] [ответить] [смотреть все]
| +/– |
> Если не в libc, то никак не в библиотеке, которая будет подгружаться
> уже после обработки части переменных окружения в раннем коде ld.so, где
это мы уже о другой фиче, ld.so она перпендикулярна, просто новая функциональность в libc, с тем же успехом могущая жить в любой другой (и статически слинкованной в том числе).
А если ее воткнуть в libc - первая же использующая эту фичу программа станет несовместима со всеми старыми системами.
> уже были уязвимости: http://seclists.org/fulldisclosure/2010/Oct/257
вот почему его до сих пор не переписали руками нормально - загадка, подумаешь, динамический линкер...
| | | |
|
|
|
|
|
|
|
|
| 1.13, key, 22:41, 19/06/2017 [ответить] [смотреть все]
| +/– |
Я правильно понимаю что, стек можно определить двумя адресами - начало и конец.
Также и с кучей(наверное можно обойдись только началом?).
Почему нельзя просто проверять границы?
if((operation == new and Addr < HeapStartAddr) or
(operation == stack and StackStartAddr < Addr < StackEndAddr)
) cout << "Error";
Там же неверняка накладные расходы на реализацию защищенной страницы не меньше?
Объясните, а то для моих скудных познаний stack guard-page выглядит слишком костыльно.
|  | | |
| |
| |
| |
| |
| 5.61, Tim, 16:03, 20/06/2017 [^] [ответить] [смотреть все]
| +1 +/– | |
При переключении контекста задач, требуется подгрузить таблицу трансляции адресов для каждого сегмента. Это вызывает шоковую нагрузку на кэш процессора.
В AMD64 шина адреса 48 бит, при этом, мнимальный размер страницы 4kB, т.е. отбрасываем 12 бит и получаем 2^36 записей в таблице трансляции. Это много, даже для иерархического представления MMU x86.
Избавились поспешно, но осмотрительно. ;)
| | | |
| |
| 6.65, добрый, 16:48, 20/06/2017 [^] [ответить] [смотреть все]
| +/– |
> При переключении контекста задач, требуется подгрузить таблицу трансляции адресов для
> каждого сегмента.
Нет, не требуется. Страничные таблицы никогда не подгружаются в кэш заранее целиком.
> Это вызывает шоковую нагрузку на кэш процессора.
Нет, не вызывает. Единственная "шоковая" нагрузка - это сброс TLB, который при переключении контекста (не режима) происходит в любом случае, будь там хоть один сегмент, хоть несколько.
> В AMD64 шина адреса 48 бит, при этом, мнимальный размер страницы 4kB,
> т.е. отбрасываем 12 бит и получаем 2^36 записей в таблице трансляции.
> Это много, даже для иерархического представления MMU x86.
Это всё к делу совершенно не относится.
> Избавились поспешно, но осмотрительно. ;)
По совершенно другим причинам. Осмотрительно или не - спорить не вижу смысла.
| | | |
| |
| 7.70, J.L., 18:48, 20/06/2017 [^] [ответить] [смотреть все]
| +/– |
>> Избавились поспешно, но осмотрительно. ;)
>По совершенно другим причинам.
можно узнать по каким ? мне сильно не понятен этот вопрос и почему вообще отказались от сегментной модели памяти типа 486х ?
|  | | |
| |
| 8.72, добрый, 21:21, 20/06/2017 [^] [ответить] [смотреть все]
| +/– |
> можно узнать по каким ? мне сильно не понятен этот вопрос и
> почему вообще отказались от сегментной модели памяти типа 486х ?
Моральное устаревание. На тот момент сегменты кода, данных и стека с разными адресами базы нигде как самостоятельные не использовались и считались, как и сейчас, пережитком прошлого.
| | | |
| |
| 9.74, J.L., 13:32, 22/06/2017 [^] [ответить] [смотреть все] [к модератору]
| +/– |
>> можно узнать по каким ? мне сильно не понятен этот вопрос и
>> почему вообще отказались от сегментной модели памяти типа 486х ?
> Моральное устаревание. На тот момент сегменты кода, данных и стека с разными
> адресами базы нигде как самостоятельные не использовались и считались, как и
> сейчас, пережитком прошлого.
и сейчас нет в современном процессоре механизма на запрет чтение/запись/исполнение в зависимости от сегмента кода/аналога ?
| | | |
|
|
|
|
|
|
|
|
|
|
