ЕМ>Подход "отдельный процесс для каждой вкладки" (как и в варианте "для каждого домена") подразумевает заявление разработчиков, типа "мы совершенно не в состоянии обеспечить сколько-нибудь вменяемую защиту вкладок друг от друга, поэтому умываем руки и отдаем всю безопасность на откуп ОС".

ЕМ>Это ж, по сути, уже до неприличия убого. Я еще понимаю, если б код для HTML писался на ассемблере, C/C++, паскале или подобных языках, где практически нет ограничений на доступ в память и выполнение операций. Но, блин, насколько ж нужно все просрать, чтоб не суметь обеспечить изоляцию для жабаскрипта???

А что, собственно, плохого в том, что по назначению используется тот инструментарий, который уже есть в системе? Not invented here? Надо обязательно своё нагородить и потом отлаживать и поддерживать? Я понимаю, если бы там интенсивный IPC был и эффективнее было бы в одном процессе, но так ведь вкладки должны быть полностью изолированы друг от друга идеологически. Накладные расходы на несколько десятков процессов в 2023 году мне кажутся незначительными.

Здравствуйте, Евгений Музыченко, Вы писали:

C>>Так ведь макросы на Visual Basic тоже небезопасны. Почти такая же ситуация как с JS.

ЕМ>Не такая же. В отношении макросов на VB никогда не возникало даже мысли о том, что в разных окнах офиса будут работать макросы из доверенных и недоверенных источников. Там подход примитивный: не доверяешь — не запускай, и все тут. Коли уж браузер берет на себя задачу исполнения кода из недоверенного источника, ему следует позаботиться об обеспечении безопасности. Иначе можно докатиться до "на кой проверять правильность входных данных — ну грохнется процесс, и всего делов...".

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

Здравствуйте, Евгений Музыченко, Вы писали:


ЕМ>Этому есть внятные объяснения? Сколько ни читал — везде что-то мямлят, но неубедительно.

Безопасность. Сейчас уже редко находят, но после появления v8 было найдено много уязвимостей. То есть некоторые скрипты на js приводили к выполнению произвольного кода. Даже если права на системные вызовы ограничены, то произвольный код в браузере может вытащить куки из соседних вкладок, а следовательно получить аутентификацию в интернет-банке например.

Сейчас таких ошибок стало меньше, но нет никаких гарантий что их нет. И собственно гарантировать что их не будет невозможно.

Здравствуйте, Евгений Музыченко, Вы писали:

ЕМ>Для чего в браузеры _навязчиво_ тянут многопроцессность?

15 лет уже, с разморозкой.

Здравствуйте, gandjustas, Вы писали:

G>Безопасность. Сейчас уже редко находят, но после появления v8 было найдено много уязвимостей. То есть некоторые скрипты на js приводили к выполнению произвольного кода. Даже если права на системные вызовы ограничены, то произвольный код в браузере может вытащить куки из соседних вкладок, а следовательно получить аутентификацию в интернет-банке например.

Больше всего меня разозлило невозможность запустить Chrome под отдельным пользователем через runas под виндой, когда Chrome только начал свою многопроцессорность. У меня всегда под браузер были отдельные пользователи, для разных задач — разные, банк — отдельно.

Только недавно я нашёл ключ командной строки, который вроде бы позволяет это сделать.

Здравствуйте, cserg, Вы писали:

C>Вот разработчики и позаботились посредством разделения по разным процессам. Другие варианты либо менее надежные, либо более сложные и затратные.

JavaScript используется почти тридцать лет, а идея изоляции вкладок в процессах стала применяться лишь несколько лет назад. Однако, разработчики браузеров с самого начала уверяли, что их реализации виртуальных машин безопасны. Все это время они беззастенчиво врали? А если так, то какие основания доверять им в том, что изоляцию с помощью выноса в процессы они сделали не криво?

C>И пусть лучше грохнется одна вкладка в браузере чем весь браузер.

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

Здравствуйте, rudzuk, Вы писали:

R>Браузер на чем написан? Кто может дать гарантию, что в этом коде нет ошибок приводящих к приколам, типа переполнения буфера и т.п.?

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

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

R>В 19 и 20 годах были продемонстрированы атаки на VirtualBox и VMware приводящие к побегу из ВМ.

И сколько известно таких успешных атак, на фоне известных успешных атак на браузеры?

R>2. Кто может дать гарантию, что во всем коде браузер нет ошибок?

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

Здравствуйте, Pauel, Вы писали:

P>15 лет уже

Еще несколько лет назад это явление подавалось главным образом как "ускорение", и легко поддавалось контролю. Теперь это "стало обязательным".

Здравствуйте, ltc, Вы писали:

ltc>А что, собственно, плохого в том, что по назначению используется тот инструментарий, который уже есть в системе?

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

Здравствуйте, gandjustas, Вы писали:

G>Сейчас таких ошибок стало меньше, но нет никаких гарантий что их нет. И собственно гарантировать что их не будет невозможно.

А гарантировать, что их не будет после "изоляции" вкладок в процессах — можно?

Здравствуйте, Евгений Музыченко, Вы писали:

ЕМ>Здравствуйте, gandjustas, Вы писали:

G>>Сейчас таких ошибок стало меньше, но нет никаких гарантий что их нет. И собственно гарантировать что их не будет невозможно.

ЕМ>А гарантировать, что их не будет после "изоляции" вкладок в процессах — можно?
Нет. Но придумать изоляцию сильнее чем процессами вряд ли получится.

1. Изоляция. Чтобы баг в одной вкладке не влиял на другие вкладки.

2. Безопасность. Изоляция процессов даёт дополнительные гарантии. А уж после открытия возможности читать не свою память через тайминги — тут вообще не завидую разработчикам браузеров.

Разработчики браузеров взвалили на себя титаническую задачу выполнять произвольный код из интернета и не допускать уязвимостей. Многопроцессность это тут вообще ерунда. Я не удивлюсь, если каждую страницу будут в отдельной виртуальной машине запускать. Старый Edge свой процесс так и запускал — в отдельной виртуальной машине (но не каждую вкладку), насчёт нового не знаю.

С>Больше всего меня разозлило невозможность запустить Chrome под отдельным пользователем через runas под виндой, когда Chrome только начал свою многопроцессорность. У меня всегда под браузер были отдельные пользователи, для разных задач — разные, банк — отдельно.

С>Только недавно я нашёл ключ командной строки, который вроде бы позволяет это сделать.

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

Здравствуйте, gandjustas, Вы писали:

G>Но придумать изоляцию сильнее чем процессами вряд ли получится.

Легко — создавать каждый процесс от имени отдельного пользователя. Без этого процессы свободно имеют доступ к памяти друг друга.

Следующий этап — создание каждого процесса в отдельной виртуальной машине. Далее — запуск этих виртуальных машин от имени разных пользователей.

Здравствуйте, Евгений Музыченко, Вы писали:

ЕМ>Здравствуйте, gandjustas, Вы писали:

G>>Но придумать изоляцию сильнее чем процессами вряд ли получится.

ЕМ>Легко — создавать каждый процесс от имени отдельного пользователя. Без этого процессы свободно имеют доступ к памяти друг друга.
В windows можно ограничить права дочернего процесса. В Linux вроде тоже.


ЕМ>Следующий этап — создание каждого процесса в отдельной виртуальной машине. Далее — запуск этих виртуальных машин от имени разных пользователей.
Виртуальные машины пока что слишком дорогие.

Здравствуйте, vsb, Вы писали:

vsb>А уж после открытия возможности читать не свою память через тайминги

Я еще с того момента, как все встали на уши, пытаюсь найти пример кода, демонстрирующего эту возможность. Пока не преуспел. А Вы?

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

Если б они выполняли произвольный двоичный код, в котором могут встречаться произвольные команды и обращения к произвольным адресам памяти, ее можно было бы считать "титанической". А задача безопасного выполнения кода на JS — вполне себе рутинная, такие языки для того и придуманы, чтобы обеспечение безопасности не являлось непосильной задачей. Но разработчики браузеров, судя по всему, хотят выглядеть героическими борцами со вселенским злом, причем как можно дольше.

Здравствуйте, m2user, Вы писали:

M>А в чем там проблема была?
M>По идее все дочерние процессы должны под правильной учеткой запуститься..

Я не смог выяснить, но предполагаю, что runas использует job object, Chrome тоже запускает дочерние процессы внутри джоба, а винда вплоть до какой-то версии не поддерживала вложенные джобы.

Здравствуйте, Евгений Музыченко, Вы писали:

R>>Браузер на чем написан? Кто может дать гарантию, что в этом коде нет ошибок приводящих к приколам, типа переполнения буфера и т.п.?

ЕМ>Не понял, как это может быть связано с попытками изоляции посредством выноса вкладок в другие процессы. Даже если "страничный" код в дочерних процессах общается с родительским процессом исключительно посредством сообщений, остается масса возможностей эксплуатации подобных уязвимостей. Ну и в дочерние процессы (по крайней мере, в винде) загружены десятки системных DLL, к которым "страничный" код тоже можно получить доступ через исполняющий код браузера, находящийся в этих процессах. Очевидно, усложнение доступа к коду/данным соседних вкладок считается приоритетным над сохранением возможности читать/писать файлы, реестр, отправлять данные по сети и т.п.

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

R>>В 19 и 20 годах были продемонстрированы атаки на VirtualBox и VMware приводящие к побегу из ВМ.

ЕМ>И сколько известно таких успешных атак, на фоне известных успешных атак на браузеры?

Ну ты сравнил... В гипервизоре xen, чуть больше полумиллиона строк кода, тогда, как в лисе их 21 миллион. Разница в 40 раз, однако.

R>>2. Кто может дать гарантию, что во всем коде браузер нет ошибок?

ЕМ>А кто может мало-мальски убедительно показать, что "изоляция" в отдельных процессах действительно повышает безопасность?

Системные механизмы обеспечивающие безопасность.

Здравствуйте, Евгений Музыченко, Вы писали:

ЕМ> Без этого процессы свободно имеют доступ к памяти друг друга.
Штоа?!
Вообще, огненный тред! Столько некомпетентности и воодушевления одновремнно!

Здравствуйте, Евгений Музыченко, Вы писали:

ltc>>А что, собственно, плохого в том, что по назначению используется тот инструментарий, который уже есть в системе?

ЕМ>Как минимум, то, что в системе он был и тридцать лет назад, но чрезмерно активное внедрение почему-то наблюдается в последние лет пять.

Странное объяснение. За 30 лет многое поменялось. 30 лет назад безопасность в интернете была совсем не так актуальна как сегодня, а аппаратные ресурсы куда скромнее. Сейчас, когда процессоры выросли "вширь" многоядерностью, а требования по памяти почти любой веб-страницы многократно превышают накладные расходы на отдельный процесс — не вижу причины, почему использование отдельных процессов это плохо.