Сообщение Re[15]: Безопасность ОС. Можно ли решить кардинально? от 29.09.2014 11:57
Изменено 29.09.2014 12:08 ononim
S>Здравствуйте, ononim, Вы писали:
O>>До сих пор вы задавали вопросы с очевидными ответами, тем не менее делая вид что не видите этих ответов.
S>Пока что вы ни на один из них толком не ответили.
Да нет, я как раз таки ответил. А этот ваш комментарий-ярлык ровным счетом ничего не меняет.
S>Как я и полагал, у вас хорошо продуман нижний уровень, но нет ни малейшего представления о том, как из этого нижнего уровня собрать решение для пользовательских сценариев. Я сам таким изобретательством занимался в 19 лет
Это многое объясняет
O>>Просто текущие системы безопасности NT/Unix тащат свои корни с лохматых времен с мэйнфреймами, на которых сидели различные пользователи, и каждый пользователь делал какую нибудь одну, но очень важную для него вещь. В таком окружении та модель замечательно работает: там пользователь == защищаемые данные. Проблема в том что сейчас ее пытаются натянуть на однопользовательское окружение, в котором куча разных данных, совершенно различными "степенями секретности", но все они варятся в едином котле одного уровня привилегий.
S>Проблема вовсе не в этом. Проблема, конечно же, в том, что в юниксовые времена пользователь == программам, с которыми он работает. Ситуацию, когда пользователь выполняет под своими привилегиями потенциально враждебную программу, авторы этих систем безопасности не рассматривали вообще.
S>Как раз всякие степени секретности по отношению к данным прекрасно моделируются в модели NT — она ж недаром проходила военную сертификацию.
O>>А разделить уровни — непонятно как, потому что просто нет прямого и естественного пути их перегруппировать, причем так чтоб потом еще и можно было шарить друг с другом. Опять же старая модель безопасности предполагала наличие админа, который бы всем настроил пермишены и сказал кому что можно, а кому что нельзя. В нынешней же солянке информации на типичной системе никакой админ не разберется, кроме того она постоянно меняется. Для защиты данных нужна новая модель безопасности, которая защищает именно данные, а не какието произвольные сущности которые с конкретными данными однозначно и на словах увязать то сложно, а не то что формально описать и запрограммировать.
S>Модель безопасности NT построена вокруг того, что было доступно на момент разработки. То есть вокруг securable object. Её легко расширить на произвольные securable objects.
Дело не в том что они моделируются или не моделируются, дело в том что разработчики софта — ленивые люди по умолчанию, о безопасности они думают в последнюю очередь. С какой палкой над ними не стой — никто не станет создавать сэндбокс для каждого документа/сайта и парится о том чтоб его данные не утекли кудато не туда (в соседний документ например). Даже браузеры особо с этим не парятся, не говоря уж про всякие стимы из соседнего листа, которым лишь бы работало. Эта модель безопасности работает когда все участники ею правильно пользуются. Можно привести аналогию из прошлого — то появления вытесняющей многозадачности была кооперативная, которая работала только когда все ею правильно пользовались. Но было одно но — если ктото ею неверно пользовался — это было видно сразу, в отличии от системы безопасности, проблем в которой не видно пока банк не пришлет стейтмент с нулевым счетом. Поэтому я считаю что текущая модель безопасности устарела, как и устарела когда-то вытесняющая многозадачность, и будущее за ОС которая будет прозрачно защищать _данные_, прозрачно — это значит без требования к программеру описывать секурити дескрипторы к каждому мутексу и файлмэпингу в своей программе. Эта самая моя предложенная модель — она как раз такая.
S>Плохо моделируются степени секретности по отношению к коду.
S>Да, ваше решение сильно поможет авторам DRM и DLP — в нём тупой пользователь не сможет нечаянно переслать секретный документ получателю с более низким уровнем доступа.
S>При условии, естественно, что классификация документа выполнена правильно. В этом и состоит основная проблема — данных возникает очень много.
Именно. Много данных, еще больше данных которые из них получается, граф взаимосвязи дико запутанный и никто за ним не следит вообще. ОС говорит — 'вот вам абстракции SD/token — накладывайте их на все ваши контейнеры данные', программеры — 'да ну нафиг, я лучше еще вот этот прочитанный вчера перед сном паттерн вверну и кнопочки сделаю в метрошном стиле'. Ни у кого нет конкретной ответственности — в результате бардак.
O>>До сих пор вы задавали вопросы с очевидными ответами, тем не менее делая вид что не видите этих ответов.
S>Пока что вы ни на один из них толком не ответили.
Да нет, я как раз таки ответил. А этот ваш комментарий-ярлык ровным счетом ничего не меняет.
S>Как я и полагал, у вас хорошо продуман нижний уровень, но нет ни малейшего представления о том, как из этого нижнего уровня собрать решение для пользовательских сценариев. Я сам таким изобретательством занимался в 19 лет
Это многое объясняет
O>>Просто текущие системы безопасности NT/Unix тащат свои корни с лохматых времен с мэйнфреймами, на которых сидели различные пользователи, и каждый пользователь делал какую нибудь одну, но очень важную для него вещь. В таком окружении та модель замечательно работает: там пользователь == защищаемые данные. Проблема в том что сейчас ее пытаются натянуть на однопользовательское окружение, в котором куча разных данных, совершенно различными "степенями секретности", но все они варятся в едином котле одного уровня привилегий.
S>Проблема вовсе не в этом. Проблема, конечно же, в том, что в юниксовые времена пользователь == программам, с которыми он работает. Ситуацию, когда пользователь выполняет под своими привилегиями потенциально враждебную программу, авторы этих систем безопасности не рассматривали вообще.
S>Как раз всякие степени секретности по отношению к данным прекрасно моделируются в модели NT — она ж недаром проходила военную сертификацию.
O>>А разделить уровни — непонятно как, потому что просто нет прямого и естественного пути их перегруппировать, причем так чтоб потом еще и можно было шарить друг с другом. Опять же старая модель безопасности предполагала наличие админа, который бы всем настроил пермишены и сказал кому что можно, а кому что нельзя. В нынешней же солянке информации на типичной системе никакой админ не разберется, кроме того она постоянно меняется. Для защиты данных нужна новая модель безопасности, которая защищает именно данные, а не какието произвольные сущности которые с конкретными данными однозначно и на словах увязать то сложно, а не то что формально описать и запрограммировать.
S>Модель безопасности NT построена вокруг того, что было доступно на момент разработки. То есть вокруг securable object. Её легко расширить на произвольные securable objects.
Дело не в том что они моделируются или не моделируются, дело в том что разработчики софта — ленивые люди по умолчанию, о безопасности они думают в последнюю очередь. С какой палкой над ними не стой — никто не станет создавать сэндбокс для каждого документа/сайта и парится о том чтоб его данные не утекли кудато не туда (в соседний документ например). Даже браузеры особо с этим не парятся, не говоря уж про всякие стимы из соседнего листа, которым лишь бы работало. Эта модель безопасности работает когда все участники ею правильно пользуются. Можно привести аналогию из прошлого — то появления вытесняющей многозадачности была кооперативная, которая работала только когда все ею правильно пользовались. Но было одно но — если ктото ею неверно пользовался — это было видно сразу, в отличии от системы безопасности, проблем в которой не видно пока банк не пришлет стейтмент с нулевым счетом. Поэтому я считаю что текущая модель безопасности устарела, как и устарела когда-то вытесняющая многозадачность, и будущее за ОС которая будет прозрачно защищать _данные_, прозрачно — это значит без требования к программеру описывать секурити дескрипторы к каждому мутексу и файлмэпингу в своей программе. Эта самая моя предложенная модель — она как раз такая.
S>Плохо моделируются степени секретности по отношению к коду.
S>Да, ваше решение сильно поможет авторам DRM и DLP — в нём тупой пользователь не сможет нечаянно переслать секретный документ получателю с более низким уровнем доступа.
S>При условии, естественно, что классификация документа выполнена правильно. В этом и состоит основная проблема — данных возникает очень много.
Именно. Много данных, еще больше данных которые из них получается, граф взаимосвязи дико запутанный и никто за ним не следит вообще. ОС говорит — 'вот вам абстракции SD/token — накладывайте их на все ваши контейнеры данные', программеры — 'да ну нафиг, я лучше еще вот этот прочитанный вчера перед сном паттерн вверну и кнопочки сделаю в метрошном стиле'. Ни у кого нет конкретной ответственности — в результате бардак.
Re[15]: Безопасность ОС. Можно ли решить кардинально?
S>Здравствуйте, ononim, Вы писали:
O>>До сих пор вы задавали вопросы с очевидными ответами, тем не менее делая вид что не видите этих ответов.
S>Пока что вы ни на один из них толком не ответили.
Да нет, я как раз таки ответил. А этот ваш комментарий-ярлык ровным счетом ничего не меняет.
S>Как я и полагал, у вас хорошо продуман нижний уровень, но нет ни малейшего представления о том, как из этого нижнего уровня собрать решение для пользовательских сценариев. Я сам таким изобретательством занимался в 19 лет
Это многое объясняет
O>>Просто текущие системы безопасности NT/Unix тащат свои корни с лохматых времен с мэйнфреймами, на которых сидели различные пользователи, и каждый пользователь делал какую нибудь одну, но очень важную для него вещь. В таком окружении та модель замечательно работает: там пользователь == защищаемые данные. Проблема в том что сейчас ее пытаются натянуть на однопользовательское окружение, в котором куча разных данных, совершенно различными "степенями секретности", но все они варятся в едином котле одного уровня привилегий.
S>Проблема вовсе не в этом. Проблема, конечно же, в том, что в юниксовые времена пользователь == программам, с которыми он работает. Ситуацию, когда пользователь выполняет под своими привилегиями потенциально враждебную программу, авторы этих систем безопасности не рассматривали вообще.
S>Как раз всякие степени секретности по отношению к данным прекрасно моделируются в модели NT — она ж недаром проходила военную сертификацию.
O>>А разделить уровни — непонятно как, потому что просто нет прямого и естественного пути их перегруппировать, причем так чтоб потом еще и можно было шарить друг с другом. Опять же старая модель безопасности предполагала наличие админа, который бы всем настроил пермишены и сказал кому что можно, а кому что нельзя. В нынешней же солянке информации на типичной системе никакой админ не разберется, кроме того она постоянно меняется. Для защиты данных нужна новая модель безопасности, которая защищает именно данные, а не какието произвольные сущности которые с конкретными данными однозначно и на словах увязать то сложно, а не то что формально описать и запрограммировать.
S>Модель безопасности NT построена вокруг того, что было доступно на момент разработки. То есть вокруг securable object. Её легко расширить на произвольные securable objects.
Дело не в том что они моделируются или не моделируются, дело в том что разработчики софта — ленивые люди по умолчанию, о безопасности они думают в последнюю очередь. С какой палкой над ними не стой — никто не станет создавать сэндбокс для каждого документа/сайта и парится о том чтоб его данные не утекли кудато не туда (в соседний документ например). Даже браузеры особо с этим не парятся, не говоря уж про всякие стимы из соседнего листа, которым лишь бы работало. Эта модель безопасности работает когда все участники ею правильно пользуются. Можно привести аналогию из прошлого — до появления вытесняющей многозадачности была кооперативная, которая работала только когда все ею правильно пользовались. Но было одно но — если ктото ею неверно пользовался — это было видно сразу, в отличии от системы безопасности, проблем в которой не видно пока банк не пришлет стейтмент с нулевым счетом. Поэтому я считаю что текущая модель безопасности устарела, как и устарела когда-то кооперативная многозадачность, и будущее за ОС которая будет прозрачно защищать _данные_, прозрачно — это значит без требования к программеру описывать секурити дескрипторы к каждому мутексу и файлмэпингу в своей программе. Эта самая моя предложенная модель — она как раз такая.
S>Плохо моделируются степени секретности по отношению к коду.
S>Да, ваше решение сильно поможет авторам DRM и DLP — в нём тупой пользователь не сможет нечаянно переслать секретный документ получателю с более низким уровнем доступа.
S>При условии, естественно, что классификация документа выполнена правильно. В этом и состоит основная проблема — данных возникает очень много.
Именно. Много данных, еще больше данных которые из них получается, граф взаимосвязи дико запутанный и никто за ним не следит вообще. ОС говорит — 'вот вам абстракции SD/token — накладывайте их на все ваши контейнеры данные', программеры — 'да ну нафиг, я лучше еще вот этот прочитанный вчера перед сном паттерн вверну и кнопочки сделаю в метрошном стиле'. Ни у кого нет конкретной ответственности — в результате бардак.
O>>До сих пор вы задавали вопросы с очевидными ответами, тем не менее делая вид что не видите этих ответов.
S>Пока что вы ни на один из них толком не ответили.
Да нет, я как раз таки ответил. А этот ваш комментарий-ярлык ровным счетом ничего не меняет.
S>Как я и полагал, у вас хорошо продуман нижний уровень, но нет ни малейшего представления о том, как из этого нижнего уровня собрать решение для пользовательских сценариев. Я сам таким изобретательством занимался в 19 лет
Это многое объясняет
O>>Просто текущие системы безопасности NT/Unix тащат свои корни с лохматых времен с мэйнфреймами, на которых сидели различные пользователи, и каждый пользователь делал какую нибудь одну, но очень важную для него вещь. В таком окружении та модель замечательно работает: там пользователь == защищаемые данные. Проблема в том что сейчас ее пытаются натянуть на однопользовательское окружение, в котором куча разных данных, совершенно различными "степенями секретности", но все они варятся в едином котле одного уровня привилегий.
S>Проблема вовсе не в этом. Проблема, конечно же, в том, что в юниксовые времена пользователь == программам, с которыми он работает. Ситуацию, когда пользователь выполняет под своими привилегиями потенциально враждебную программу, авторы этих систем безопасности не рассматривали вообще.
S>Как раз всякие степени секретности по отношению к данным прекрасно моделируются в модели NT — она ж недаром проходила военную сертификацию.
O>>А разделить уровни — непонятно как, потому что просто нет прямого и естественного пути их перегруппировать, причем так чтоб потом еще и можно было шарить друг с другом. Опять же старая модель безопасности предполагала наличие админа, который бы всем настроил пермишены и сказал кому что можно, а кому что нельзя. В нынешней же солянке информации на типичной системе никакой админ не разберется, кроме того она постоянно меняется. Для защиты данных нужна новая модель безопасности, которая защищает именно данные, а не какието произвольные сущности которые с конкретными данными однозначно и на словах увязать то сложно, а не то что формально описать и запрограммировать.
S>Модель безопасности NT построена вокруг того, что было доступно на момент разработки. То есть вокруг securable object. Её легко расширить на произвольные securable objects.
Дело не в том что они моделируются или не моделируются, дело в том что разработчики софта — ленивые люди по умолчанию, о безопасности они думают в последнюю очередь. С какой палкой над ними не стой — никто не станет создавать сэндбокс для каждого документа/сайта и парится о том чтоб его данные не утекли кудато не туда (в соседний документ например). Даже браузеры особо с этим не парятся, не говоря уж про всякие стимы из соседнего листа, которым лишь бы работало. Эта модель безопасности работает когда все участники ею правильно пользуются. Можно привести аналогию из прошлого — до появления вытесняющей многозадачности была кооперативная, которая работала только когда все ею правильно пользовались. Но было одно но — если ктото ею неверно пользовался — это было видно сразу, в отличии от системы безопасности, проблем в которой не видно пока банк не пришлет стейтмент с нулевым счетом. Поэтому я считаю что текущая модель безопасности устарела, как и устарела когда-то кооперативная многозадачность, и будущее за ОС которая будет прозрачно защищать _данные_, прозрачно — это значит без требования к программеру описывать секурити дескрипторы к каждому мутексу и файлмэпингу в своей программе. Эта самая моя предложенная модель — она как раз такая.
S>Плохо моделируются степени секретности по отношению к коду.
S>Да, ваше решение сильно поможет авторам DRM и DLP — в нём тупой пользователь не сможет нечаянно переслать секретный документ получателю с более низким уровнем доступа.
S>При условии, естественно, что классификация документа выполнена правильно. В этом и состоит основная проблема — данных возникает очень много.
Именно. Много данных, еще больше данных которые из них получается, граф взаимосвязи дико запутанный и никто за ним не следит вообще. ОС говорит — 'вот вам абстракции SD/token — накладывайте их на все ваши контейнеры данные', программеры — 'да ну нафиг, я лучше еще вот этот прочитанный вчера перед сном паттерн вверну и кнопочки сделаю в метрошном стиле'. Ни у кого нет конкретной ответственности — в результате бардак.