Ответ на »сообщение 2356« (Руслан Богатырев)
___________________________

Я говорю о служебной для ОС ("бортовой") СУБД. Думаю, многим давно уже очевидно, что UNIX многие вещи свела к низкоуровневой работе (процессы -- это один пример, файлы -- другой).

Файл как базовая сущность ОС стал создавать все большие проблемы. Я не говорю о том, чтобы отказаться от этого понятия вовсе, но для многих вещей имеет смысл подниматься по абстрагированию выше -- над файлами (сохраняя их для низкоуровневых задач). Служебная СУБД новой ОС -- это один из шагов (не единственный). Разрабатывать придется самим. Но для нее могут быть заданы вполне приемлемые ограничения (специфика), которые позволят значительно сократить объем работ, чем если бы это было при создании полноценной промышленной универсальной СУБД.

1. А будет ли позволено надстроить служебную СУБД до уровня полноценной промышленной универсальной СУБД? Бывают ситуации, когда какую-то информацию можно хранить как в форме файлов, так и в форме полей БД.

2. Смогут ли прикладные приложения использовать служебную СУБД?

И теперь не связанные с СУБД вопросы:

3. Будет ли организован статический (буфер обмена, импорт-экспорт данных) и динамический (связи с таблицами СУБД, электронными таблицами, встроенные объекты и т.п.) обмен данными между приложениями (включая аплеты), работающими под разными ОС?

4. Будет ли возможно нескольким приложениям новой ОС одновременно работать с одним документом?

Господа,безопасность в современных ОС вопрос очень существенный и конечно существуют стандарты, классификации и наборы формальных требований и стандаротов.
И конечно не плохо было бы из изучить, или просто почитать.
В частности есть так называемая Оранжевая книга (Orange Book)
http://en.wikipedia.org/wiki/Orange_Book

Ответ на »сообщение 2352« (panda)
___________________________

Ответ на »сообщение 2348« (Сергей Прохоренко)
___________________________

А Вы себе представьте десятки тысяч ОС, неправильно настроенных кривыми или хитрыми ручками сисадминов, если только над ними нет солидного штата высокооплачиваемых сотрудников службы безопасности. Для Банка что воровство, что их зарплата - всё расходы.
А Вы, простите, откуда знаете, что эти расходы эквивалентны? Вы же сами сказали, что банки замалчивают огромные потери из-за проблем безопасности.
Кроме того, многие объекты безопасности реализуются в прикладных системах. И Вы легко можете купить у производителя или консалтинговой компании внедрение и правильную настройку системы, что значительно минимизирует возможности администраторов по краже данных.

N-ое проявление закона Паркинсона: расходы на безопасность растут в геометрической прогрессии, пока не сравняются с матожиданием предполагаемого ущерба от преступлений. (автор - я)

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

Ответ на »сообщение 2351« (Денис Зайцев)
___________________________

Ответ на »сообщение 2347« (Сергей Прохоренко)
___________________________

Ответ на »сообщение 2340« (Димыч)
___________________________


Безусловно, инсайдеры опасны, но это вопрос не ОС, это вопрос т.н. социальной инженерии. По большому счету, к ОС это имеет отношение опосредованное.


Ну конечно! Это не у нас замки и сигнализация хилые, а у вас воры нечестные.


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

Вот, например, типичный запрос начальника: "Вася, дай мне такие-то данные по таким-то клиентам". Что, начальник не имеет права выдать такой приказ, если ему действительно нужны какие-то данные?
А коль скоро начальник может, то значит, и Вася может получить к ним доступ. И если Вася нечист на руку, то ничто не сможет спасти конфиденциальную информацию от разглашения.

А как ОС сможет проконтролировать доступ, например, к распечатанному ею только что документу?

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

Ответ на »сообщение 2349« (Руслан Богатырев)
___________________________
Не все так просто. :) Но раз затронули этот вопрос, давайте немного порассуждаем.
Это надо помозговать хотя бы. Не сразу могу отреагировать...
Буду пытаться найти в приведенной аргументации стереотипы профессионала, которые не дают сделать шаг в необычном направлении. Если получится.

Ответ на »сообщение 2355« (Денис Зайцев)
___________________________

Правда насчёт БД есть сомнения. Если файловую систему ОС ещё может проконтролировать, то сомневаюсь, что ребята из РЕЛЭКСа согласятся встроить такие (зависимые от архитектуры одной будущей ОС) средства в ЛИНТЕР. Я уже не заикаюсь про остальные СУБД. И что тогда? Самим разрабатывать?

Я говорю о служебной для ОС ("бортовой") СУБД. Думаю, многим давно уже очевидно, что UNIX многие вещи свела к низкоуровневой работе (процессы -- это один пример, файлы -- другой).

Файл как базовая сущность ОС стал создавать все большие проблемы. Я не говорю о том, чтобы отказаться от этого понятия вовсе, но для многих вещей имеет смысл подниматься по абстрагированию выше -- над файлами (сохраняя их для низкоуровневых задач). Служебная СУБД новой ОС -- это один из шагов (не единственный). Разрабатывать придется самим. Но для нее могут быть заданы вполне приемлемые ограничения (специфика), которые позволят значительно сократить объем работ, чем если бы это было при создании полноценной промышленной универсальной СУБД.

Ответ на »сообщение 2354« (Руслан Богатырев)
___________________________

Думаю, если ОС сможет проконтролировать исполнение "своего" и "не своего" ПО (а также сопутствующей информации в файлах, БД, реестрах и т.п.), отследить нарушение своей целостности, знать, при каких условиях, до какой степени и как она может осуществлять функциональную деградацию -- это уже будет неплохо. Или я не прав?
Согласен. Уже этого одного достаточно, чтобы проект можно было считать успешным. Правда насчёт БД есть сомнения. Если файловую систему ОС ещё может проконтролировать, то сомневаюсь, что ребята из РЕЛЭКСа согласятся встроить такие (зависимые от архитектуры одной будущей ОС) средства в ЛИНТЕР. Я уже не заикаюсь про остальные СУБД. И что тогда? Самим разрабатывать?
Хм... хотя можно, конечно, на уровне ОС ввести понятие "запись" (record) с возможностью настраивать различные атрибуты доступа для разных записей одного и того же файла. Но это будет всё равно защита на уровне кортежей, а если нужна будет на уровне атрибута... на этом мысль останавливается.

Ответ на »сообщение 2351« (Денис Зайцев)
___________________________


А как ОС сможет проконтролировать доступ, например, к распечатанному ею только что документу?

Думаю, если ОС сможет проконтролировать исполнение "своего" и "не своего" ПО (а также сопутствующей информации в файлах, БД, реестрах и т.п.), отследить нарушение своей целостности, знать, при каких условиях, до какой степени и как она может осуществлять функциональную деградацию -- это уже будет неплохо. Или я не прав?

Что касается бурной дискуссии вокруг банков и др. -- давайте не будем мешать в кучу организационные вещи и технические особенности ОС (это призыв ко все участникам обсуждения).

Ответ на »сообщение 2350« (___)
___________________________

а на русском языке есть вариант?

К сожалению, мне он не встречался.