The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]

форумы
правила/FAQ
поиск
регистрация
вход
слежка
RSS


Вариант для распечатки  
Пред. тема | След. тема 
Форум Разговоры, обсуждение новостей
Режим отображения отдельной подветви беседы [ Отслеживать ]

Оглавление

В ядро Linux 5.4 приняты патчи для ограничения доступа root ..., opennews (ok), 30-Сен-19, (0) [смотреть все]

Сообщения [Сортировка по времени | RSS]


47. "В ядро Linux 5.4 приняты патчи для ограничения доступа root ..."  +7 +/–
Сообщение от Аноним (47), 30-Сен-19, 11:15 
> Наиболее очевидным следствием подобной активности может стать обход UEFI Secure Boot или извлечение конфиденциальных данных, хранящихся на уровне ядра.

UEFI сделает вашу жизнь лучше говорили они.

напомните мне пожалуйста еще раз о преимуществах UEFI а то я размагнитился

Ответить | Правка | Наверх | Cообщить модератору

53. "В ядро Linux 5.4 приняты патчи для ограничения доступа root ..."  –2 +/–
Сообщение от DerRoteBaron (ok), 30-Сен-19, 11:34 
Установка нескольких ОС мультибутом без расстрела одного загрузчика другим.
Возможность обеспечения цепи загрузки, взломать которую могут только Штеуд и АНБ, а не любой мимо крокодил с локальным доступом.
Ответить | Правка | Наверх | Cообщить модератору

58. "В ядро Linux 5.4 приняты патчи для ограничения доступа root ..."  +/–
Сообщение от Аноним (47), 30-Сен-19, 12:03 
> Установка нескольких ОС мультибутом без расстрела одного загрузчика другим.

основные страдания происходят из за винды, а так ничто не мешает установить свой любимый загрузчик на отдельно выделенный раздел и грузить столько ОС сколько нужно
> Возможность обеспечения цепи загрузки, взломать которую могут только Штеуд и АНБ, а не любой мимо крокодил с локальным доступом.

так что получается, `набор патчей "lockdown"` которые Линус принял на грудь это в назидание АНБ ?

Ответить | Правка | Наверх | Cообщить модератору

106. "В ядро Linux 5.4 приняты патчи для ограничения доступа root ..."  +1 +/–
Сообщение от Аноним (75), 30-Сен-19, 15:24 
> так что получается, `набор патчей "lockdown"` которые Линус принял на грудь это в назидание АНБ ?

Вы точно распарсили предложение, на которое отвечали?
Для АНБ ничего не поменялось, у них бэкдоры в Intel ME/AMD PSP, которые клали на все программные защиты.

Ответить | Правка | Наверх | Cообщить модератору

96. "В ядро Linux 5.4 приняты патчи для ограничения доступа root ..."  +1 +/–
Сообщение от Аноним (-), 30-Сен-19, 15:04 
> Установка нескольких ОС мультибутом без расстрела одного загрузчика другим.

это проблемы конкретных ОС и их инсталлеров (и тех локалхостоадминов, кто эти ОС инсталлирует - тоже).

http://freebsd.org/cgi/man.cgi?apropos=0&query=boot0cfg придумали очень, очень давно, и если устанавливаемая ОС пишет свой загрузчик в СВОЙ раздел, а не в чужие области диска - всё работает автоматически. Иначе - пишите баг-репорты, требуйте. А EFI не нужен от слова совсем.

Ответить | Правка | К родителю #53 | Наверх | Cообщить модератору

183. "В ядро Linux 5.4 приняты патчи для ограничения доступа root ..."  –3 +/–
Сообщение от Аноним (176), 30-Сен-19, 23:04 
Если на пека есть ефи фат32 раздел, в него будут копировать ефи файлы загрузчика инсталляторы, по крайней мере бубунты так делают. А кто так не умеет в 2019 то дистр. этого васяна и нафиг не нужен. По видимому ваша Фрибзд так не умеет, ну вот собственно никому она и не нужна.
Ответить | Правка | Наверх | Cообщить модератору

194. "В ядро Linux 5.4 приняты патчи для ограничения доступа root ..."  +1 +/–
Сообщение от Аноним (194), 01-Окт-19, 00:24 
Вы не поняли.

Во-первых FreeBSD поддерживает как EFI, так и EFIFAT и прочее сопутствующее [censored].

Во-вторых, сам EFI не нужен - аналогичная (по результату) функциональность в контексте этого разговора была доступна за много-много лет до EFI, на машинах с BIOS, при чём с меньшими затратами.

В третьих, по теме новости - аналогичная функциональность была доступна в FreeBSD за много лет до версии LINUX 5.4, и это факты.

Ответить | Правка | Наверх | Cообщить модератору

197. "В ядро Linux 5.4 приняты патчи для ограничения доступа root ..."  +/–
Сообщение от artenox (?), 01-Окт-19, 00:29 
"Установка нескольких ОС мультибутом без расстрела одного загрузчика другим"
У меня только один загрузчик в убунте. А при установке осей в дуалбут, я установку grub в них отключаю. Но позволяет это только Debian и openSUSE. Еще есть хак - подсунуть под grub ненужную флешку.
Ответить | Правка | К родителю #53 | Наверх | Cообщить модератору

198. "В ядро Linux 5.4 приняты патчи для ограничения доступа root ..."  +/–
Сообщение от artenox (?), 01-Окт-19, 00:31 
И тоже не все дистры позволяют выбрать куда ставить grub. Например, Fedora не позволяет.
Ответить | Правка | Наверх | Cообщить модератору

199. "В ядро Linux 5.4 приняты патчи для ограничения доступа root ..."  +/–
Сообщение от Michael Shigorinemail (ok), 01-Окт-19, 00:40 
> А при установке осей в дуалбут, я установку grub в них отключаю.
> Но позволяет это только Debian и openSUSE.

Да ладно, alterator-grub тоже позволяет :-)

Ответить | Правка | К родителю #197 | Наверх | Cообщить модератору

65. "В ядро Linux 5.4 приняты патчи для ограничения доступа root ..."  +2 +/–
Сообщение от Armagor (ok), 30-Сен-19, 12:35 
А мне, пожалуйста, напомните, от какого вектора атаки защищает Secure Boot?
Ответить | Правка | К родителю #47 | Наверх | Cообщить модератору

68. "В ядро Linux 5.4 приняты патчи для ограничения доступа..."  +9 +/–
Сообщение от arisu (ok), 30-Сен-19, 12:48 
> А мне, пожалуйста, напомните, от какого вектора атаки защищает Secure Boot?

ну как же: от пользователя, который желает поставить Неправильную ОС.

Ответить | Правка | Наверх | Cообщить модератору

72. "В ядро Linux 5.4 приняты патчи для ограничения доступа..."  +/–
Сообщение от Armagor (ok), 30-Сен-19, 13:01 
Это вывод, который невольно напрашивается сам собой. На вики дебиана пишут:
>SB is a security measure to protect against malware during early system boot

а есть вообще какие-нибудь примеры руткитов, которые так делают?

Ответить | Правка | Наверх | Cообщить модератору

91. "В ядро Linux 5.4 приняты патчи для ограничения доступа..."  +1 +/–
Сообщение от Аноним84701 (ok), 30-Сен-19, 14:27 
> Это вывод, который невольно напрашивается сам собой. На вики дебиана пишут:
>>SB is a security measure to protect against malware during early system boot
>  а есть вообще какие-нибудь примеры руткитов, которые так делают?

Ключевое слово тут "bootkit":
Stoned Bootkit -> Whistler
https://habr.com/ru/post/96850/

Правда, если просто исключить возможность менять очередность бута "всем кому не лень", то тот же самый  эффект "сикурбута" эмулируется и в старом добром BIOS с помощью загрузки с флешки или CD (да хоть перфокарт) и проверки хеша незашифрованного блока загрузчика на диске – но это если бы действительно была такая цель, а не просто "отмазка" ;-)


Ответить | Правка | Наверх | Cообщить модератору

152. "В ядро Linux 5.4 приняты патчи для ограничения доступа..."  +/–
Сообщение от Armagor (ok), 30-Сен-19, 17:21 
О, большое спасибо за наводку и ссылку.
Whistler - это самое близкое к оправданию существования секьюрбута, что я видел. Жаль, не известен инфектор буткита.
Ответить | Правка | Наверх | Cообщить модератору

157. "В ядро Linux 5.4 приняты патчи для ограничения доступа..."  +2 +/–
Сообщение от Аноним84701 (ok), 30-Сен-19, 17:32 
> О, большое спасибо за наводку и ссылку.
> Whistler - это самое близкое к оправданию существования секьюрбута, что я видел.
> Жаль, не известен инфектор буткита.

Stoned, хоть и был больше PoC, но ЕМНИП, PoC красивый -  прописывался в MBR c помощью сплойта в PDF :)
Ну и нашумело оно немного в СМИ как "расшифровщик" ТруЪКрипта (хотя по факту перехватывался вводиммый пользователем пароль).
А так подмена загрузчика малварщикам (тогда) особо никуда не уперлось.

Но таки что-то было:
https://www.ghacks.net/2010/09/01/how-to-detect-a-64-bit-alu.../
>  new variant of Alureon that infects the Master Boot Record (MBR) instead of an infected driver.
> While this new variant did not affect 64-bit machines, it had an inert file called ldr64 as part of its virtual file system.
> More recently, we discovered an updated variant that successfully infected 64-bit machines running Windows Vista or
> higher, while rendering 64-bit Windows XP and Server 2003 machines unbootable.

Ответить | Правка | Наверх | Cообщить модератору

189. "В ядро Linux 5.4 приняты патчи для ограничения доступа..."  +/–
Сообщение от Аноним (9), 30-Сен-19, 23:43 
>то тот же самый  эффект "сикурбута" эмулируется и в старом добром BIOS с помощью загрузки с флешки или CD (да хоть перфокарт) и проверки хеша незашифрованного блока загрузчика на диске

Всё гораздо проще. Есть SMM-модуль для биоса, запрещающий запись в загрузочный сектор вообще. Но граб в с ним активированным не обновите.

Ответить | Правка | К родителю #91 | Наверх | Cообщить модератору

88. "В ядро Linux 5.4 приняты патчи для ограничения доступа..."  +/–
Сообщение от Michael Shigorinemail (ok), 30-Сен-19, 14:15 
> ну как же: от пользователя, который желает поставить Неправильную ОС.

В первую очередь -- именно от этой.  Причём то, как нагорбатили 32-битный UEFI, меня в этом наблюдении только утвердило.

Ответить | Правка | К родителю #68 | Наверх | Cообщить модератору

238. "В ядро Linux 5.4 приняты патчи для ограничения доступа..."  +/–
Сообщение от microsoft (?), 02-Окт-19, 11:52 
>> ну как же: от пользователя, который желает поставить Неправильную ОС.
> В первую очередь -- именно от этой.  Причём то, как нагорбатили
> 32-битный UEFI, меня в этом наблюдении только утвердило.

а мы тут причем? У нас 32битная система стоит ровно столько же, сколько 64 - $0 если в составе oem сборки компьютера.

Мы на этом ничего не приобрели. А загружать 64битную систему uefi32 - извините, вы тоже не очень-то умеете, те смешные костыли и подпорки у вас и работают-то только при отключенном secboot.

Так что зачем и по чьей просьбе интел такое наколбасил - мы тоже не в курсе. Подозреваем что ни по чьей - просто их разработчики справились с задачей "поддерживать еще и 32битную версию" - ну вот так, как шмагли.
Нас, в принципе, устроило - для китайских планшетов и так сойдет, нам три копейки за наклейку всяко отчисляют. А ваш линoops им как корове седло.


Ответить | Правка | Наверх | Cообщить модератору

77. "В ядро Linux 5.4 приняты патчи для ограничения доступа root ..."  +/–
Сообщение от Stax (ok), 30-Сен-19, 13:17 
К примеру, от атаки Evil Maid https://en.wikipedia.org/wiki/Evil_maid_attack
Ответить | Правка | К родителю #65 | Наверх | Cообщить модератору

80. "В ядро Linux 5.4 приняты патчи для ограничения доступа root ..."  +/–
Сообщение от DerRoteBaron (ok), 30-Сен-19, 13:31 
А еще осложняет cold boot (в особенности при запаянной памяти)
Ответить | Правка | Наверх | Cообщить модератору

90. "В ядро Linux 5.4 приняты патчи для ограничения доступа root ..."  +1 +/–
Сообщение от Аноним (90), 30-Сен-19, 14:17 
Мне кажется, что угроза cold boot из разряда страшилок, имеющих небольшую практическую угрозу в реальных условиях. Для нее практически надо, чтобы в руки атакующего попал невыключенный компьютер, и даже при этом без гарантий успеха.  Для защиты тут проще сделать задержку с подачей напряжений на память при reset. Впрочем она и так есть, вероятность, что в памяти что-то сохранилось после включения невелика.
Ответить | Правка | Наверх | Cообщить модератору

86. "В ядро Linux 5.4 приняты патчи для ограничения доступа root ..."  +3 +/–
Сообщение от Аноним (90), 30-Сен-19, 14:09 
Чтобы от этой атаки появилась хотя бы что-то чуть более, чем иллюзия защищенности, надо из UEFI удалить ВСЕ ключи, кроме собственноручно сгенерированных.  Вопрос, многие ли системы позволяют это сделать?

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

Ответить | Правка | К родителю #77 | Наверх | Cообщить модератору

142. "В ядро Linux 5.4 приняты патчи для ограничения доступа root ..."  +1 +/–
Сообщение от Stax (ok), 30-Сен-19, 16:47 
> Чтобы от этой атаки появилась хотя бы что-то чуть более, чем иллюзия
> защищенности, надо из UEFI удалить ВСЕ ключи, кроме собственноручно сгенерированных.  
> Вопрос, многие ли системы позволяют это сделать?

Погодите, а это почему?
Наличие ключа MS при условии, что приватным ключом MS кого попало не подписывает - не нарушает безопасность.

А своим ключом MS вроде как кого попало и не подписывает. Свои загрузчики, ну и еще некоторые конкретные сборки shim (которые попросили у них подписать) и еще некоторые вполне конкретные *бинарные* загрузчики. Собрать свой загрузчик-зловред и подписать его сборку у MS - хоть возможно в теории, но на практике из разряда фантазий, не настолько же они идиоты, что попало подписывать.

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

Строго говоря, правильное взаимодействие ядра и TPM решило бы эту проблему. Но его нет.

Кстати, сама винда тут весьма правильно делает: она проверяет всю цепочку загрузчиков (*всю* цепочку тех, кто ее загружал - т.е. например конкретный UEFI + конкретный bootmgfw.efi, или же цепочку UEFI + shim + grub + bootmgfw). И если что-то серьезное изменилось в настройках UEFI (к примеру, выключили Secure Boot) или загрузили по другой цепочке (например раньше грузили без grub, а теперь его вставили в цепочку) или же изменился конкретный бинарник shim, она тут же навостряет уши и требует ввести длинный ключ Bitlocker, который сообщался при шифровании диска. При этом это не имеет отношения собственно к пассфразе или отпечатку пальца или другому методу аутентификации, который потом будет использоваться для расшифровки. И это работает в т.ч. при выключенном Secure Boot.

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

Ответить | Правка | Наверх | Cообщить модератору

166. "В ядро Linux 5.4 приняты патчи для ограничения доступа root ..."  +/–
Сообщение от Аноним (90), 30-Сен-19, 19:08 
> Наличие ключа MS при условии, что приватным ключом MS кого попало не подписывает - не нарушает безопасность.

Что знают двое - то знает и свинья (c) "17 мгновений весны".

Нет уж, если действительно безопасность, то дайте мне возможность всё (включая винду, если ее использую) подписать своим и только своим ключом, который кроме меня вообще никто не знает.  А кому там MS дает, кому не дает  в таком случае не волнует совершенно.

Ответить | Правка | Наверх | Cообщить модератору

182. "В ядро Linux 5.4 приняты патчи для ограничения доступа root ..."  +/–
Сообщение от Stax (ok), 30-Сен-19, 23:03 
Ну, возможность у вас есть.
Ответить | Правка | Наверх | Cообщить модератору

167. "В ядро Linux 5.4 приняты патчи для ограничения доступа root ..."  +/–
Сообщение от AlexYeCu_not_logged (?), 30-Сен-19, 19:26 
>Наличие ключа MS при условии, что приватным ключом MS кого попало не подписывает - не нарушает безопасность.

Собственно, это условие и не соблюдается. И, кстати говоря, не может быть соблюдено.

Ответить | Правка | К родителю #142 | Наверх | Cообщить модератору

185. "В ядро Linux 5.4 приняты патчи для ограничения доступа root ..."  +/–
Сообщение от Анонимный этот (?), 30-Сен-19, 23:22 
> Это очень правильная идея, на самом деле, и обидно что линуксу глубоко
> безразлично, что там происходило до его загрузки - вот какое-то ядро
> загрузилось, теперь вводи пассфразу от luks и пожалуйста, открыт полный доступ
> к системе.

А чем это хуже этого вашего "ключа Bitlocker"? И не полный доступ.

Ответить | Правка | К родителю #142 | Наверх | Cообщить модератору

186. "В ядро Linux 5.4 приняты патчи для ограничения доступа root ..."  +/–
Сообщение от Stax (ok), 30-Сен-19, 23:25 
Есть разница между короткой пассфразой, выбранной пользователем и вводимой каждую загрузку и длинной специализированной, которая требуется только если произошло что-то подозрительное и изменилась цепочка загрузчика.
Ответить | Правка | Наверх | Cообщить модератору

190. "В ядро Linux 5.4 приняты патчи для ограничения доступа root ..."  +/–
Сообщение от Анонимный этот (?), 30-Сен-19, 23:54 
Что-то эта ваша "длинная специализированная" смахивает на очередное плацебо, потому что не требуется...
Ответить | Правка | Наверх | Cообщить модератору

191. "В ядро Linux 5.4 приняты патчи для ограничения доступа root ..."  +/–
Сообщение от Stax (ok), 30-Сен-19, 23:59 
> Что-то эта ваша "длинная специализированная" смахивает на очередное плацебо, потому что
> не требуется...

В каком смысле не требуется?

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

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

Ответить | Правка | Наверх | Cообщить модератору

239. "В ядро Linux 5.4 приняты патчи для ограничения доступа root ..."  +/–
Сообщение от microsoft (?), 02-Окт-19, 11:56 
> А своим ключом MS вроде как кого попало и не подписывает. Свои
> загрузчики, ну и еще некоторые конкретные сборки shim (которые попросили у

на минуточку - у нас не один ключ!
И ваши шимы мы подписываем _другим_ ключом. Что и позволило огрызку их не загружать. В отличие от б-жественной десяточки.

> них подписать) и еще некоторые вполне конкретные *бинарные* загрузчики. Собрать свой
> загрузчик-зловред и подписать его сборку у MS - хоть возможно в

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

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

> Это очень правильная идея, на самом деле, и обидно что линуксу глубоко
> безразлично, что там происходило до его загрузки - вот какое-то ядро

потому что вашего Линуса - мак!

Ответить | Правка | К родителю #142 | Наверх | Cообщить модератору

180. "В ядро Linux 5.4 приняты патчи для ограничения доступа root ..."  +/–
Сообщение от Анонимный этот (?), 30-Сен-19, 22:56 
> он не сможет, например, просто всю материнскую плату подменить или некоторые
> микросхемки с uefi перепаять на ней.

Ага. Не сможет. В ряде случаев.
В других случаях проще будет изъять так сказать диск. А там своя защита работающая в паре с UEFI... Правда сейчас в том что в широкой так сказать продаже не очень работающая, но...
Короче придётся атаккеру паять свою плату к своему компу... >:-)

Ответить | Правка | К родителю #86 | Наверх | Cообщить модератору

133. "В ядро Linux 5.4 приняты патчи для ограничения доступа root ..."  +/–
Сообщение от Armagor (ok), 30-Сен-19, 16:22 
Спасибо за ссылку.
>An evil maid attack is an attack on an unattended device

И чтобы защититься от такой атаки, мы делаем SB с Microsoft в качестве Certification Authority. Что бы могло пойти не так?

Ответить | Правка | К родителю #77 | Наверх | Cообщить модератору

188. "В ядро Linux 5.4 приняты патчи для ограничения доступа root ..."  +2 +/–
Сообщение от Аноним84701 (ok), 30-Сен-19, 23:34 
> Спасибо за ссылку.
>>An evil maid attack is an attack on an unattended device
> И чтобы защититься от такой атаки, мы делаем SB с Microsoft в
> качестве Certification Authority. Что бы могло пойти не так?

https://www.opennet.ru/opennews/art.shtml?num=44950
> Утечка мастер-ключа Microsoft скомпрометировала защиту Secure Boot
> 11.08.2016 19:22
> [...] ключ был найден в составе отладочного инструментария, который был забыт на одном из устройств.

[...]
> По сути, все устройства с верифицированной загрузкой Windows скомпрометированы и решить проблему выпуском обычного обновления не получается

[...]
> Устранить проблему просто не получится, так как загрузчик уже поставляется в установочных носителях, а отзыв связанного с ним ключа повлечёт за собой неработоспособность установочных образов, разделов для восстановления и резервных копий.

И правда, что? :)

Ответить | Правка | Наверх | Cообщить модератору

192. "В ядро Linux 5.4 приняты патчи для ограничения доступа root ..."  +/–
Сообщение от Stax (ok), 01-Окт-19, 00:01 
>> Спасибо за ссылку.
>>>An evil maid attack is an attack on an unattended device
>> И чтобы защититься от такой атаки, мы делаем SB с Microsoft в
>> качестве Certification Authority. Что бы могло пойти не так?
> https://www.opennet.ru/opennews/art.shtml?num=44950
>> Утечка мастер-ключа Microsoft скомпрометировала защиту Secure Boot
>> 11.08.2016 19:22
>> [...] ключ был найден в составе отладочного инструментария, который был забыт на одном из устройств.
> [...]
>> По сути, все устройства с верифицированной загрузкой Windows скомпрометированы и решить проблему выпуском обычного обновления не получается

А почитать внимательнее не судьба, да?

> Важно подчеркнуть, что это не PKI-ключ, применяемый для формирования цифровых подписей к исполняемым файлам, а ключ для отключения проверки в загрузчике, не влияющий на надёжность работы прошивок UEFI

Тем, что утекло - свой зловредный загрузчик вы не подпишете.

Ответить | Правка | Наверх | Cообщить модератору

195. "В ядро Linux 5.4 приняты патчи для ограничения доступа root ..."  +/–
Сообщение от Аноним84701 (ok), 01-Окт-19, 00:28 
> А почитать внимательнее не судьба, да?
>> Важно подчеркнуть, что это не PKI-ключ, применяемый для формирования цифровых подписей к исполняемым файлам, а ключ для отключения проверки в загрузчике, не влияющий на надёжность работы прошивок UEFI
> Тем, что утекло - свой зловредный загрузчик вы не подпишете.

Читать внимательно желательно оригинал:
https://gist.github.com/anonymous/c94cadade3a8b87dcdc52c639f...

> The "supplemental" policy does NOT contain a DeviceID. And, because they were meant to be merged into a base policy, they don't contain any BCD rules either,
> which means that if they are loaded, you can enable testsigning. Not just for windows (to load unsigned driver, ie rootkit), but for the {bootmgr} element as well, which allows bootmgr to run what is effectively an unsigned .efi (ie bootkit)!!! (In practise, the .efi file must be signed, but it can be self-signed)   You can see how this is very bad!! A backdoor, which MS put in to secure boot because they decided to not let the user turn it off in certain devices, allows for secure boot to be disabled everywhere!
>  You can see the irony. Also the irony in that MS themselves provided us several
> nice "golden keys" (as the FBI would say ;) for us to use for that purpose :)
>

Ответить | Правка | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей 		Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру