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

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

FR>>Тут все будет очень объективно, программ станет меньше, они станут сложнее в использовании, и стоить существенно дороже. При этом разница в качестве для простого пользователя будет почти незаметна

CU>Программ станет меньше — да.

CU>Сложнее в использовании — с чего? В написании — да. В сопровождении — да. В использовании — почему? Конкуренты не дремлют...

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

CU>Стоить дороже — да.

CU>Для простого пользователя? А может не надо его так сильно "упрощать". Я в своих дествиях на 80% (если не 95) могу себя отнести к "простым пользователям" — этого хватает чтобы очень часто вспоминать "незлым тихим словом" авторов программ и судорожно принимать выбор — лезть в инет за решением или "по быстрому" решить всё с copy&paste. К хорошему привыкаешь быстро — кого сейчас заставишь регулярно "перебирать движок 21-й", а когда-то водитель==автослесарь.

Так будет еще хуже, без "настройщика" ничего ни сможешь

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


CU>ну — с одеждой и едой уже рассудили

Угу мелочь живет в этой отрасли очень неплохо

CU>>>По крайней мере тонны варезников с мелкими утилитками по 5$ с громкими названиями и описаниями — жизни не хватит если доверится описаниям и начать пробовать... Ходят ведь в итоге практически все в однотипной одежде, ездят в ещё более однотипных машинах, жуют одно и тоже (специи не в счёт) — и ничего? Опять же, я не про музыку и литературу — я исключительно про производство

FR>>Тык большинство этих утилит как раз их области "музыки и литературы"

CU>Для авторов — да. Для пользователей — гербалайф и биодобавки...

Нет для авторов часто как раз часто наоборот, каторжный труд
А для пользователей скорей рюшечки и бантики а не гербалайф

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

FR>Для пользователей сложней так как будут поощрятся продукты-монстры "делающие все", так как по твоему предложению все "ненужные" программы не выпускаются, вот и впитают несколько монстров их функции.

И выходит несколько странное (мертворождённое?) явление — "эволюция без мутаций"

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

CU>>Сложнее в использовании — с чего? В написании — да. В сопровождении — да. В использовании — почему? Конкуренты не дремлют...

FR>Конкуренты уже все разорились

далеко не все. Только любители "безответственности" и "халявы"

FR>Для пользователей сложней так как будут поощрятся продукты-монстры "делающие все", так как по твоему предложению все "ненужные" программы не выпускаются, вот и впитают несколько монстров их функции.

Т.е. если бы вместо ОО было 48 маленьких программ (да ещё и каждая со своим а не унифицированным интерфейсам) никак друг с другом не взаимодействующие (разве что через потоки I/O) — было бы лучше и проще? Странные у вас понятия...

CU>>Для простого пользователя? А может не надо его так сильно "упрощать". Я в своих дествиях на 80% (если не 95) могу себя отнести к "простым пользователям" — этого хватает чтобы очень часто вспоминать "незлым тихим словом" авторов программ и судорожно принимать выбор — лезть в инет за решением или "по быстрому" решить всё с copy&paste. К хорошему привыкаешь быстро — кого сейчас заставишь регулярно "перебирать движок 21-й", а когда-то водитель==автослесарь.

FR>Так будет еще хуже, без "настройщика" ничего ни сможешь

1C-ника "дороже" обучить нежели кодера? Опять непонятки...

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

CU>>ну — с одеждой и едой уже рассудили

FR>Угу мелочь живет в этой отрасли очень неплохо

Угу, после того как "приняла" стандарты/правила.

CU>>Для авторов — да. Для пользователей — гербалайф и биодобавки...

FR>Нет для авторов часто как раз часто наоборот, каторжный труд

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

FR>А для пользователей скорей рюшечки и бантики а не гербалайф

То-же самое — хорошо если вреда нет, но пользы точно никакой.

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

FR>>Для пользователей сложней так как будут поощрятся продукты-монстры "делающие все", так как по твоему предложению все "ненужные" программы не выпускаются, вот и впитают несколько монстров их функции.

К>И выходит несколько странное (мертворождённое?) явление — "эволюция без мутаций"

Да нет — с мутациями. Только "выход годных" догнать бы хоть до совковой микроэлектроники, а то подозреваю он ещё на порядок меньше...

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

CU>Здравствуйте, Курилка, Вы писали:

FR>>>Для пользователей сложней так как будут поощрятся продукты-монстры "делающие все", так как по твоему предложению все "ненужные" программы не выпускаются, вот и впитают несколько монстров их функции.

К>>И выходит несколько странное (мертворождённое?) явление — "эволюция без мутаций"

CU>Да нет — с мутациями. Только "выход годных" догнать бы хоть до совковой микроэлектроники, а то подозреваю он ещё на порядок меньше...

Не знал, что в союзе микроэлектроннику методом генной инженерии развивали
В общем — я так и не услышал, где же в написании программ типовые приёмы, отточив которые можно штамповать хорошие программы. Только не надо про паттерны и иже с ними — практика уже по-моему достаточна показала, что остаётся справедливой поговорка про "заставь дурака богу молиться". В общем — ключевым инструментом разработчика считаю его мозг (иде и язык программирования по мне лишь для грубой обработки типа рашпиля). Ты же по сути получается призываешь стандартизировать человеческое мышление, причём по ходу дела получается чуть ли не во всех областях сразу. Для рутинных операций типа бухучёта, наверное, это отчасти справедливо, хотя и там фантазия законотворцов не даёт расслабиться Да и просто есть привычки/приёмы разных главбухов и т.п. (я в бух-ии почти 0, так что сильно серьёзно этот аргумент прошу не воспринимать). А есть и посложней отрасли...
Неэффективные системы отомрут сами собой, если будут вменяемые конкуренты, а по поводу вменяемых я не вижу смысла беспокоиться.
Ты же, получается, считаешь, что есть какая-то утопия, где всё решается идеальным образом. На это дело есть не один роман-антиутопия
В общем каких-то внятных предложений/идей о качестве и о том, как оно должно всю индустрию перелапатить, я не вижу пока
Так что непонятно, о чём вообще идёт разговор.

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

C>>Ну тогда это уже решили. Открываешь файл с помощью D-BUS, получаешь от него дескриптор и работаешь с ним как обычно.
CU>таки это нади писать
?

C>>Зачем? Смысл в том, чтобы посадить в клетку программу, которая выполняет опасные действия (такие как просмотр web-страничек). Программы из "доверяемого периметра" можно в клетку не сажать.
CU>Либо доверяемых программ будет слишком мало (и будет очень сложно регулировать уровни безопасности большинства программ) либо основная опасность так и останется в "доверенных" но дырявых прогах.
Нет. Опасны те программы, которые исполняют недоверяемые данные. Такие программы обычно можно достаточно неплохо изолировать.

Ну и про стандартные механизмы контроля в Юниксах не надо забывать. Например, простой пользователь не может поменять исполняемый файл вне пределов своего домашнего каталога, а исполнение файлов из него можно запретить. Т.е. для всяких вирусов жизнь будет существенно сложнее — для распространения им нужно получить права root'а. PolicyKit это уже существенно усложняет, так как полные права root'а остаются нужны разве что для выполнения нескольких программ.

CU>Имхо, контроль стека "гуардам" не противовес и не помеха, а доп. кирпич в "стенку безопасности", но и то и другое "2-й эшелон" по сравнению с качеством самих программ.
Stack guards и прочее — это дополнительная защита, но надеяться на нее ни в коем случае нельзя. Так как при желании она обходится.

CU>>>В IT области? Не слышал... И я уже писал — это должно быть "вершиной айсберга", а не его основой.
C>>ISO 9000 везде действует.
CU>Но везде ли применяется?
Нет, ибо нафиг не нужен. Возьми и прочти его, какие проблемы-то? По нему тонны литературы написаны.

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

CU>Угу, после того как "приняла" стандарты/правила.

И без них неплохо жила, да и сейчас умудряется не соблюдать и не только мелочь

CU>>>Для авторов — да. Для пользователей — гербалайф и биодобавки...

FR>>Нет для авторов часто как раз часто наоборот, каторжный труд

CU>"каторжный" — это когда завтра доделывать то, что не сделал сегодня. Многие пишут хоть с малейшим предположением дальнейшего сопровождения? Не смешите меня.

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

FR>>А для пользователей скорей рюшечки и бантики а не гербалайф

CU>То-же самое — хорошо если вреда нет, но пользы точно никакой.

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

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

FR>>Конкуренты уже все разорились

CU>далеко не все. Только любители "безответственности" и "халявы"

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

FR>>Для пользователей сложней так как будут поощрятся продукты-монстры "делающие все", так как по твоему предложению все "ненужные" программы не выпускаются, вот и впитают несколько монстров их функции.

CU>Т.е. если бы вместо ОО было 48 маленьких программ (да ещё и каждая со своим а не унифицированным интерфейсам) никак друг с другом не взаимодействующие (разве что через потоки I/O) — было бы лучше и проще? Странные у вас понятия...

Вместе с ОО сейчас существуют 1048 подобных программ и притом многие из них продаются и конкурируют с бесплатным ОО.
Так вот я за то чтобы они и дальше это делали, ты же хочешь чтобы эти 1048 функций добавили к существующим 48 из ОО.

CU>>>Для простого пользователя? А может не надо его так сильно "упрощать". Я в своих дествиях на 80% (если не 95) могу себя отнести к "простым пользователям" — этого хватает чтобы очень часто вспоминать "незлым тихим словом" авторов программ и судорожно принимать выбор — лезть в инет за решением или "по быстрому" решить всё с copy&paste. К хорошему привыкаешь быстро — кого сейчас заставишь регулярно "перебирать движок 21-й", а когда-то водитель==автослесарь.

FR>>Так будет еще хуже, без "настройщика" ничего ни сможешь

CU>1C-ника "дороже" обучить нежели кодера? Опять непонятки...

Тема в том что тебе чтобы полноценно пользоватся OO нужен будет настройщик

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

Какие-то велосипеды всё однако.

C>Эта штуковина позволяет делать почти полноценный code access security для обычных приложений. Если кратко, то оно работает так — есть шина обмена сообщениями D-BUS (это COM с человеческим лицом), на нее вешаются сервисы, выполняющие restricted-операции, они работают в контекстах безопасности, с достаточными правами.

А нафига? Если я буду писать шпиона, то точно не буду использовать D-BUS, чтобы мои операции не ограничили в правах...


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

Windows (начиная с NT 4.0): старая добрая COM-security, ограничивающая доступ к объекту. А в общем случае — это уже проблема конкретного сервиса проверить пользователя, который к нему постучался, на доступ к тому или иному ресурсу. А если ресурса нет, то и проверять нечего...


C>Кроме того, тут в дело вступает еще один компонент системы — AppArmor. Это ядерный модуль, который позволяет ограничить права одного конкретно взятого процесса. Например, можно сделать так, чтобы FireFox не имел доступа ни к каким файлам кроме своего каталога плугинов. Совместно с PolicyKit он может использоваться для изоляции опасных процессов.

Windows Server 2008: Integrity Levels, для сервисов — Service Security Identifier (можно явно ограничить права доступа сервиса к тому или иному ресурсу, не заводя для этого отдельного пользователя). Есть ещё Protected Processes — спорная технология и пока толком не понятная, но теоретически вполне юзабельная.


C>Если я нажимаю на кнопку "Unlock" — то у меня появляется окно, в котором я ввожу свой пароль, после чего приложение "Network Settings" получает права на работу с настройками сети, но ни с чем иным.

Windows Server 2008: UAC


C>В общем, как оказалось, для CAS совсем не нужно переписывать все на managed-код.

А при чём здесь managed-код?

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

C>>Эта штуковина позволяет делать почти полноценный code access security для обычных приложений. Если кратко, то оно работает так — есть шина обмена сообщениями D-BUS (это COM с человеческим лицом), на нее вешаются сервисы, выполняющие restricted-операции, они работают в контекстах безопасности, с достаточными правами.
MN>А нафига? Если я буду писать шпиона, то точно не буду использовать D-BUS, чтобы мои операции не ограничили в правах...
Если у тебя есть администраторский доступ к компьютеру — то ничего уже не защитит от твоих шпионов (хотя...). Смысл PolicyKit+AppArmor — защитить систему от атак или, в худшем случае, минимизировать ущерб от атаки.

C>>Процессы, которым нужно сделать какие-то запрещенные операции соединяется через PolicyKit с нужным сервисом и просит выполнить авторизацию. PolicyKit проверяет права текущего пользователя, может быть спрашивает пароль, и дает (или не дает) доступ вызывающему процессу к нужной службе.
MN>Windows (начиная с NT 4.0): старая добрая COM-security, ограничивающая доступ к объекту.
Так я же сказал, что DBUS — это COM с человеческим лицом В том смысле, что там вещи типа настроек безопасности используются легко и просто, в отличие от COM.

MN>А в общем случае — это уже проблема конкретного сервиса проверить пользователя, который к нему постучался, на доступ к тому или иному ресурсу. А если ресурса нет, то и проверять нечего...
Вот тебе задача — надо дать пользователю менять настройки TCP/IP (это административное действие). Причем только из одной программы (NetworkManager), чтобы вирус из FireFox не смог, например, поменять DNS на hackerdns.hacker.com

На PolicyKit+AppArmor решается все просто — делается служба по изменению адреса и вешается на D-BUS. У этой службы указывается, что нужен "IP Change Permission" у вызывающего процесса. Этот permission дан программе управления сетью, которая дополнительно защищена AppArmor'ом от поползновений в ее адресное пространство со стороны других программ.

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

В Vista сделано подобное с помощью UAC, но оно сделано ужасно криво — пользователи просто всегда нажимают "OK". В Линуксе это делают так, что пользователю никогда не надо будет смотреть что там написано в диалоге, так как пользователь будет сам явно иницировать нужное действие. Ну и кроме того, UAC поднимает привиллегии всего процесса целиком до админивского уровня. Это примерно то же самое, что УЖЕ есть в Linux'ах и от чего хотят избавиться — автоматическое выполнение sudo для административных программ.

MN>Windows Server 2008: Integrity Levels, для сервисов — Service Security Identifier (можно явно ограничить права доступа сервиса к тому или иному ресурсу, не заводя для этого отдельного пользователя). Есть ещё Protected Processes — спорная технология и пока толком не понятная, но теоретически вполне юзабельная.
Нет, даже близко по удобству не стоит. В Линуксе все просто — для исполняемого файла (ЛЮБОГО, не обязательнл сервиса) просто прописывается простой профиль типа:

#include <tunables/global>
/usr/lib/firefox/firefox flags=(complain) {
  #include <abstractions/base>
  #include <abstractions/nameservice>

  capability sys_ptrace,

  / r,
  /bin/dash ixr,
  /bin/grep ixr,
  /bin/ls ixr,
  /bin/ps ixr,
  /bin/pwd ixr,
  /bin/sed ixr,
  /bin/which ixr,
  /dev/snd/controlC0 rw,
...
  /var/tmp/ rw,
}

При запуске файла AppArmor сам подхватит нужный профиль, который ставится вместе с приложением.

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

C>>Если я нажимаю на кнопку "Unlock" — то у меня появляется окно, в котором я ввожу свой пароль, после чего приложение "Network Settings" получает права на работу с настройками сети, но ни с чем иным.
MN>Windows Server 2008: UAC
Выше написал уже

C>>В общем, как оказалось, для CAS совсем не нужно переписывать все на managed-код.
MN>А при чём здесь managed-код?
Так тут флеймы такие в свое время были.

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

FR>тот же Форд добился того, что используя более низкоквалифицированную рабочую силу смог поднять производительность труда (в том числе в расчете на человека) на порядки.

Мне кажется, вы увлеклись ложными аналогиями. Какие паровые двигатели? Какие конвейеры? Фордовский конвейер имеет отношение к тиражированию продукции, а не к исследованиям, разработке и проектированию — а софтверная индустрия — это одни только разработка и проектирование, не так ли? Тиражирование ПО тривиально.

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

C>Здравствуйте, Mr. None, Вы писали:

C>>>Эта штуковина позволяет делать почти полноценный code access security для обычных приложений. Если кратко, то оно работает так — есть шина обмена сообщениями D-BUS (это COM с человеческим лицом), на нее вешаются сервисы, выполняющие restricted-операции, они работают в контекстах безопасности, с достаточными правами.
MN>>А нафига? Если я буду писать шпиона, то точно не буду использовать D-BUS, чтобы мои операции не ограничили в правах...
C>Если у тебя есть администраторский доступ к компьютеру — то ничего уже не защитит от твоих шпионов (хотя...). Смысл PolicyKit+AppArmor — защитить систему от атак или, в худшем случае, минимизировать ущерб от атаки.

Мой коммент был у другом. Чтобы всё это заработало надо применять специальную технику управлению ресурсами. То есть не обычные системные вызовы, а плясать с бубном вокруг специального защищённого интерфейса. Где-нибудь да проколишься всё равно. Плюс, это не защищает от программ, которые будут использовать обычные системные интерфейсы, а не указанный безопасный... А теперь рассмотрим ситуацию — программа, использующая только указанный безопасный интерфейс, с широкими полномочиями, но где-то в ней косяк приводящий к выполнению построннего кода (хоть локальный, хоть удалённый). Мне, как автору этого зловредного кода, абсолютно по барабану, что уязвимая программа использует защищённый интерфейс — мой код будет использовать общесистемные не защищённые методы.... Последствия ясны.


C>>>Процессы, которым нужно сделать какие-то запрещенные операции соединяется через PolicyKit с нужным сервисом и просит выполнить авторизацию. PolicyKit проверяет права текущего пользователя, может быть спрашивает пароль, и дает (или не дает) доступ вызывающему процессу к нужной службе.
MN>>Windows (начиная с NT 4.0): старая добрая COM-security, ограничивающая доступ к объекту.
C>Так я же сказал, что DBUS — это COM с человеческим лицом В том смысле, что там вещи типа настроек безопасности используются легко и просто, в отличие от COM.

Я немного о другом, в данном случае речь об использовании COM`а для организации разграничения доступа к функциональности сервиса. Пишется COM-объект с контекстом запуска LOCAL_SERVER (точнее в данном случае это уже DCOM) либо с авто-запуском, либо живущий в некотором сервисе. И доступ к объекту ограничивается посредством обычного механизма COM-security. Получили сервис с разграничением доступа, интерфейсом к которому является COM. Если проводить аналоги между DBUS и PolicyKit, то это как раз DBUS с интегрированным PolicyKit и отдельно PolicyKit не нужен вообще.


MN>>А в общем случае — это уже проблема конкретного сервиса проверить пользователя, который к нему постучался, на доступ к тому или иному ресурсу. А если ресурса нет, то и проверять нечего...
C>Вот тебе задача — надо дать пользователю менять настройки TCP/IP (это административное действие). Причем только из одной программы (NetworkManager), чтобы вирус из FireFox не смог, например, поменять DNS на hackerdns.hacker.com

Вот тебе отдача:
при включенном UAC (а вы его что отключаете на сервере? нехорошо, нехорошо...) менять настройки TCP/IP вообще без подтверждения нельзя ни одному процессу. А FireFox вообще запускаем с Integrity Level`ом "Low Mandatory Level" чтобы он вообще ничего не мог менять и даже вопросов не задавал (настраивается с помощью стандартного UI). Так что вообще ничего писать не надо.


C>На PolicyKit+AppArmor решается все просто — делается служба по изменению адреса и вешается на D-BUS.

Ну уже всё не просто раз "делается служба" см. решение для Windows Server 2008...


C>Дополнительно, если в самой NetworkManager будут какие-то уязвимости, то в крайнем случае атакующий получит возможность менять настройки сети, но не получит полных прав root'а.

C>В Vista сделано подобное с помощью UAC, но оно сделано ужасно криво — пользователи просто всегда нажимают "OK". В Линуксе это делают так, что пользователю никогда не надо будет смотреть что там написано в диалоге, так как пользователь будет сам явно иницировать нужное действие. Ну и кроме того, UAC поднимает привиллегии всего процесса целиком до админивского уровня. Это примерно то же самое, что УЖЕ есть в Linux'ах и от чего хотят избавиться — автоматическое выполнение sudo для административных программ.

Во-первых, раз уж мы сравниваем серверные решения, то давайте говорить о Windows Server 2008, а не Vista... Ни один администратор на серверной системе в здравом уме и твёрдой памяти не щёлкнет на OK, не посмотрев, что же там сказано. Это было во-первых, теперь во-вторых. У вас не верные сведения о UAC. Диалог с предложением поднять привилегии, если вы залогинились под административным аккаунтом (AAM), или ввести логин/пароль, если вы обычный пользователь (OTS) выводятся только, если вы предприняли специальные действия в своей программе (добавили определённый атрибут в манифест), во всех остальных случаях в момент обращения к защищённым ресурсам появится другое окошко: "Access deny". И запустить такое приложение с поднятыми привилегиями можно только с помощью специальной кнопки в интерфейсе файл-менеджера (по сути сделать Run as). Так что и тут ничего писать не надо — кнопка уже есть... Ну и наконец, в-третьих, процессу не только поднимаются привилегии, но и меняется Integrity Level на "Hight Mandatory Level", это означает, что ни один процесс с меньшим Integrity Level`ом (а по сути просто ни один процесс, потому что по дефолту с "Hight Mandatory Level" выполняются только процессы AAM и OTS) не сможет ни прочитать, ни записать ни один объект или кусок памяти этого процесса.


MN>>Windows Server 2008: Integrity Levels, для сервисов — Service Security Identifier (можно явно ограничить права доступа сервиса к тому или иному ресурсу, не заводя для этого отдельного пользователя). Есть ещё Protected Processes — спорная технология и пока толком не понятная, но теоретически вполне юзабельная.
C>Нет, даже близко по удобству не стоит. В Линуксе все просто — для исполняемого файла (ЛЮБОГО, не обязательнл сервиса) просто прописывается простой профиль типа:
C>При запуске файла AppArmor сам подхватит нужный профиль, который ставится вместе с приложением.

Опять же совсем не просто . Обычному приложению это редко нужно, а для сервисов в Windows Server 2008 "сервисный аккаунт" создаётся автоматически при регистрации сервиса ничего писать не надо. Дальше права для этого "аккаунта" вы раздаёте как хотите, хоть руками, хоть через программу установки. Вы даже можете использовать эту возможность для сервисов, которые были написаны до выхода Windows Server 2008 и ничего не знали о "сервисных аккаунтах".


C>>>В общем, как оказалось, для CAS совсем не нужно переписывать все на managed-код.
MN>>А при чём здесь managed-код?
C>Так тут флеймы такие в свое время были.

О чём флэйм? Всё тоже самое есть в Windows Server 2008, даже больше, местами даже раньше, в большинстве случаев даже программить ничего не надо — всё есть автоматом, сиди и настраивай только... В случае огромных систем — это ой как полезно...

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

К>В общем — я так и не услышал, где же в написании программ типовые приёмы, отточив которые можно штамповать хорошие программы. Только не надо про паттерны и иже с ними — практика уже по-моему достаточна показала, что остаётся справедливой поговорка про "заставь дурака богу молиться".

Т.е. вроде как приёмы есть, но нет "приёмов" научить их правильно использовать любого? А я говорил — что надо? Всё что я говорю — вопрос качества перенести из области for-fun в правовую область. Всё остальное — это _вероятные_ следствия.

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

Не мышление, а результат его деятельности!!! Это наконец понятно?!

К>Неэффективные системы отомрут сами собой, если будут вменяемые конкуренты, а по поводу вменяемых я не вижу смысла беспокоиться.

Угу, оговорить в законодательстве "вменяемость" производителей и отменить нафиг все сертификации и лицензирование!

К>Ты же, получается, считаешь, что есть какая-то утопия, где всё решается идеальным образом. На это дело есть не один роман-антиутопия

Я считаю, что пора программистам начать "отвечать" за свои поделия и давать гарантии на их работу.

К>В общем каких-то внятных предложений/идей о качестве и о том, как оно должно всю индустрию перелапатить, я не вижу пока

Я не говорю _как_, я говорю — _нужна система сертификации ПО_ (и самих софтописателей — тоже).

К>Так что непонятно, о чём вообще идёт разговор.

О необходимости законодательно требовать от "производителей ПО" сертификации продукции и выдачи гарантий на его работу. Всё.

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

CU>>таки это нади писать
C>?

Я имел в виду — переписывать все программы (там где это надо, пусть даже это будет делаться одним #define)

C>>>Зачем? Смысл в том, чтобы посадить в клетку программу, которая выполняет опасные действия (такие как просмотр web-страничек). Программы из "доверяемого периметра" можно в клетку не сажать.
CU>>Либо доверяемых программ будет слишком мало (и будет очень сложно регулировать уровни безопасности большинства программ) либо основная опасность так и останется в "доверенных" но дырявых прогах.
C>Нет. Опасны те программы, которые исполняют недоверяемые данные. Такие программы обычно можно достаточно неплохо изолировать.

CU>>>>В IT области? Не слышал... И я уже писал — это должно быть "вершиной айсберга", а не его основой.
C>>>ISO 9000 везде действует.
CU>>Но везде ли применяется?
C>Нет, ибо нафиг не нужен. Возьми и прочти его, какие проблемы-то? По нему тонны литературы написаны.

Т.е. вроде как стандарт есть, но он нафиг не нужен... Я понял — для кодера контроль качества его кода и требование гарантий страшнее чем ладан для чёрта

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

CU>Здравствуйте, Курилка, Вы писали:


К>>В общем каких-то внятных предложений/идей о качестве и о том, как оно должно всю индустрию перелапатить, я не вижу пока

CU>Я не говорю _как_, я говорю — _нужна система сертификации ПО_ (и самих софтописателей — тоже).

А потом ещё сертификации сертификаторов сертификаторов сертификаторов...
Неинтересно.

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

MN>Мой коммент был у другом. Чтобы всё это заработало надо применять специальную технику управлению ресурсами. То есть не обычные системные вызовы, а плясать с бубном вокруг специального защищённого интерфейса. Где-нибудь да проколишься всё равно. Плюс, это не защищает от программ, которые будут использовать обычные системные интерфейсы, а не указанный безопасный...
С этим все нормально — все привиллегированые системные вызовы требуют root'а. У обычного пользователя его просто не будет, так что системные вызовы просто обломятся с EACCESS.

Сейчас это обходится с помощью sudo — то есть для выполнения административных действий запускается процесс с поднятыми до root'а привиллегиями. Т.е. почти в точности как и UAC в Vista — что как раз позволяет сделать твой сценарий.

PolicyKit ликвидирует потребность запускать весь процесс как root.

MN>А теперь рассмотрим ситуацию — программа, использующая только указанный безопасный интерфейс, с широкими полномочиями, но где-то в ней косяк приводящий к выполнению построннего кода (хоть локальный, хоть удалённый). Мне, как автору этого зловредного кода, абсолютно по барабану, что уязвимая программа использует защищённый интерфейс — мой код будет использовать общесистемные не защищённые методы.... Последствия ясны.
Да, твой код будет обламываться с ошибками защиты доступа.

C>>Так я же сказал, что DBUS — это COM с человеческим лицом В том смысле, что там вещи типа настроек безопасности используются легко и просто, в отличие от COM.
MN>Я немного о другом, в данном случае речь об использовании COM`а для организации разграничения доступа к функциональности сервиса. Пишется COM-объект с контекстом запуска LOCAL_SERVER (точнее в данном случае это уже DCOM) либо с авто-запуском, либо живущий в некотором сервисе. И доступ к объекту ограничивается посредством обычного механизма COM-security.
Да, это вполне возможно. Только вот никто так почти не делает — это сложно и громоздко. Я знаю, я как-то работал с системой безопасности NT. Там без бутылки не разобраться.

MN>Получили сервис с разграничением доступа, интерфейсом к которому является COM. Если проводить аналоги между DBUS и PolicyKit, то это как раз DBUS с интегрированным PolicyKit и отдельно PolicyKit не нужен вообще.
PolicyKit — это система выполнения и хранения авторизации для процесса, включая показ графических диалогов авторизации и т.п.

MN>Вот тебе отдача:
MN>при включенном UAC (а вы его что отключаете на сервере? нехорошо, нехорошо...) менять настройки TCP/IP вообще без подтверждения нельзя ни одному процессу.
Какой сервер? PolicyKit предназначен для user-friendly десктопа.

MN>А FireFox вообще запускаем с Integrity Level`ом "Low Mandatory Level" чтобы он вообще ничего не мог менять и даже вопросов не задавал (настраивается с помощью стандартного UI). Так что вообще ничего писать не надо.
А злой вирус делает buffer overflow в FF, закачивает свое тело на диск и называет его "ОченьБезобиднаяПрограмма.exe". А потом запускает его и обходит UAC.

C>>На PolicyKit+AppArmor решается все просто — делается служба по изменению адреса и вешается на D-BUS.
MN>Ну уже всё не просто раз "делается служба" см. решение для Windows Server 2008...
Почему? Служба — это просто один so-файл (dll то бишь), которая прописана в списке служю DBUS. Ничего сложного.

C>>В Vista сделано подобное с помощью UAC, но оно сделано ужасно криво — пользователи просто всегда нажимают "OK". В Линуксе это делают так, что пользователю никогда не надо будет смотреть что там написано в диалоге, так как пользователь будет сам явно иницировать нужное действие. Ну и кроме того, UAC поднимает привиллегии всего процесса целиком до админивского уровня. Это примерно то же самое, что УЖЕ есть в Linux'ах и от чего хотят избавиться — автоматическое выполнение sudo для административных программ.
MN>Во-первых, раз уж мы сравниваем серверные решения, то давайте говорить о Windows Server 2008, а не Vista...
PolicyKit — это клиентское решение. При обычном непараноидальном режиме в Vista — именно Allow/Deny появляются.

Для сервера есть адский SELinux, где вообще можно сделать так, что даже адимнистратор не сможет прочитать твои данные без мер типа перезагрузки машины или аппаратных снифферов. Там полная реализация MAC (Mandatory Access Control) с поддержкой сетевых меток (т.е. можно сделать чтобы недоверенная служба не могла общаться с доверенной даже через IPC или сеть) и прочих фич.

C>>При запуске файла AppArmor сам подхватит нужный профиль, который ставится вместе с приложением.
MN>Опять же совсем не просто . Обычному приложению это редко нужно, а для сервисов в Windows Server 2008 "сервисный аккаунт" создаётся автоматически при регистрации сервиса ничего писать не надо.
FireFox/ThunderBird? Я лично один раз вирус через эксплоит в нем словил. Еще я бы всякие медиа-плееры точно так же прикрыл бы, так как в них тоже дыры находили.

MN>Дальше права для этого "аккаунта" вы раздаёте как хотите, хоть руками, хоть через программу установки. Вы даже можете использовать эту возможность для сервисов, которые были написаны до выхода Windows Server 2008 и ничего не знали о "сервисных аккаунтах".
Неудобно, появляются проблемы, например, при замене файлов.

C>>Так тут флеймы такие в свое время были.
MN>О чём флэйм?
Было предположение, что CAS неэффективен в unmanaged-системах из-за того, что нельзя контролировать разделение на доверяемый и недоверяемый код.

MN>Всё тоже самое есть в Windows Server 2008, даже больше, местами даже раньше, в большинстве случаев даже программить ничего не надо — всё есть автоматом, сиди и настраивай только... В случае огромных систем — это ой как полезно...
Меньше Я еще про SELinux не начал писать.

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

CU>>>таки это нади писать
C>>?
CU>Я имел в виду — переписывать все программы (там где это надо, пусть даже это будет делаться одним #define)
Можно сделать неинтрузивные обертки. Другое дело, что в Линуксе проще сразу сделать красиво и дописать нужные части нормально.

CU>>>Но везде ли применяется?
C>>Нет, ибо нафиг не нужен. Возьми и прочти его, какие проблемы-то? По нему тонны литературы написаны.
CU> Т.е. вроде как стандарт есть, но он нафиг не нужен... Я понял — для кодера контроль качества его кода и требование гарантий страшнее чем ладан для чёрта
Нет, просто громоздкость процессов не оправдывает обычно результатов. Или положительных результатов в итоге вообще не бывает.

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

CU>>Угу, после того как "приняла" стандарты/правила.

FR>И без них неплохо жила, да и сейчас умудряется не соблюдать и не только мелочь

Исключения били и будут всегда. Это не повод не устанавливать правила.

CU>>>>Для авторов — да. Для пользователей — гербалайф и биодобавки...

FR>>>Нет для авторов часто как раз часто наоборот, каторжный труд

CU>>"каторжный" — это когда завтра доделывать то, что не сделал сегодня. Многие пишут хоть с малейшим предположением дальнейшего сопровождения? Не смешите меня.

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

Если "однодневка" писалась "под себя", то надо было "отредезайнить" её перед "выходом в тираж". Иначе — ССЗБ.

FR>"Пользу" определяет пользователь кошельком, что бывает иначе мы уже проходили, и не хочется повторять.

Я не говорю про "иначе", я говорю про "дополнительные условия". Аллё, меня слышно?!!!