Re[20]: Code Access Security - future is here :)
От: Cyberax Марс  
Дата: 05.02.08 13:46
Оценка:
Здравствуйте, cl-user, Вы писали:

CU>>>Эти программы пишут под заказ или для "широких массовых продаж"?

C>>Считать ли программу, занимающую 30% рынка — массовой? А если рынок исчисляется десятками тысяч штук?
CU>Значит должны быть и конкуренты, и тесты. Но 10'000 — это узкая сфера, в которой "потребители" сами могут скооперироваться и выставлять требования "производителям" (я так думаю — цена позволяет).
Конкуренты есть, это без проблем. Скооперироваться потребители не могут, как в анекдоте — куда они денутся с подводной-то лодки?

Тестировать на 100% с полным доказательством кода — нельзя, конкуренты обгонят софт по фичам. Потребителям вполне достаточно разумного балланса между качеством и фичами.
Sapienti sat!
Re[39]: Code Access Security - future is here :)
От: cl-user  
Дата: 05.02.08 13:50
Оценка:
Здравствуйте, Курилка, Вы писали:

К>Посмотри в форуме декларативного программирования про TFP, правда, видимо, не всё можно написать при помощи TFP, но там безошибочность 100% при корректной работе железа.


А теперь оцените вероятность перехода TFP в разряд "мэйнстрима" без необходимости подтверждения качества кода?
Re[39]: Code Access Security - future is here :)
От: cl-user  
Дата: 05.02.08 13:52
Оценка:
Здравствуйте, Cyberax, Вы писали:

C>>>А другого ничего нет. Или адское тестирование и доказательство кода, или ситуация как сейчас.

CU>>Да что-же это такое... Мир совершенен, и любое изменение == ухудшение ситуации? Всё, картинка зафиксирована, и ничего другого и быть не может?
C>Мир совершенен? Это что-то новенькое.

C>Технологии создания ПО эволюционируют, тут все нормально. Но кардинально вряд ли что-то в ближайшем будущем изменится.


О, уже "вряд ли", а не "ничего нет". А если ещё усилия приложить?
Re[21]: Code Access Security - future is here :)
От: cl-user  
Дата: 05.02.08 13:54
Оценка:
Здравствуйте, Cyberax, Вы писали:

C>Конкуренты есть, это без проблем. Скооперироваться потребители не могут, как в анекдоте — куда они денутся с подводной-то лодки?


Почему не могут? Обговорить необходимые требования — и вперёд: кто первый, "того и тапки"
Re[22]: Code Access Security - future is here :)
От: Cyberax Марс  
Дата: 05.02.08 13:57
Оценка:
Здравствуйте, cl-user, Вы писали:

C>>Конкуренты есть, это без проблем. Скооперироваться потребители не могут, как в анекдоте — куда они денутся с подводной-то лодки?

CU>Почему не могут? Обговорить необходимые требования — и вперёд: кто первый, "того и тапки"
Как ты себе представляешь сотрудничество кучи разных компаний со всего мира?

Ну ладно, сговорились. Что дальше? Не покупать микроскопы назло врагам?
Sapienti sat!
Re[40]: Code Access Security - future is here :)
От: Курилка Россия http://kirya.narod.ru/
Дата: 05.02.08 13:57
Оценка:
Здравствуйте, cl-user, Вы писали:

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


К>>Посмотри в форуме декларативного программирования про TFP, правда, видимо, не всё можно написать при помощи TFP, но там безошибочность 100% при корректной работе железа.


CU>А теперь оцените вероятность перехода TFP в разряд "мэйнстрима" без необходимости подтверждения качества кода?


А чего тут оценивать? У кого будут доказанно корректные программы, и это доказательство не выйдет за рамки бюджета, тот выиграет в конкурентной борьбе. Клиенту нужен в первую очередь продукт, "гербовый знак" на бумажке которая есть у софтописателя задачу клиента не решит. А про "липовые" сертификаты уже упоминали.
Re[23]: Code Access Security - future is here :)
От: cl-user  
Дата: 05.02.08 14:01
Оценка:
Здравствуйте, Cyberax, Вы писали:

C>Как ты себе представляешь сотрудничество кучи разных компаний со всего мира?


Не надо "кучи", надо "критической массы", которая (при числе конкурентов > 2) может быть меньше 50%.
И вы таки не слышали скандалов по поводу "межкорпорационных сговоров", иногда между откровенными конкурентами?
Re[41]: Code Access Security - future is here :)
От: cl-user  
Дата: 05.02.08 14:08
Оценка:
Здравствуйте, Курилка, Вы писали:

CU>>А теперь оцените вероятность перехода TFP в разряд "мэйнстрима" без необходимости подтверждения качества кода?


К>А чего тут оценивать? У кого будут доказанно корректные программы, и это доказательство не выйдет за рамки бюджета, тот выиграет в конкурентной борьбе.


Да ну? Пока софтописатели ничем не ограничены, они продают рекламу — гербалайф и биодобавки.

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


"Знак" скажет, что продукт соответствует хоть каким-то нормам и хоть что-то гарантирует. А при прочих равных условиях может оказаться решающим плюсом для принятия решения в пользу...

К>А про "липовые" сертификаты уже упоминали.


"Гав-гав-гав!!!" (это вместо 3-х этажного мата) ЗАКОНЫ ТОЖЕ ДАЮТ СБОИ, И НЕ РЕДКО — ОТМЕНИМ ВСЕ ЗАКОНЫ И БУДЕМ ЖИТЬ "ПО ПОНЯТИЯМ"?!!!
Re[42]: Code Access Security - future is here :)
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 05.02.08 14:19
Оценка:
Здравствуйте, cl-user, Вы писали:

К>>А чего тут оценивать? У кого будут доказанно корректные программы, и это доказательство не выйдет за рамки бюджета, тот выиграет в конкурентной борьбе.


CU>Да ну? Пока софтописатели ничем не ограничены, они продают рекламу — гербалайф и биодобавки.


В области заказного ПО это не так.


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[42]: Code Access Security - future is here :)
От: Курилка Россия http://kirya.narod.ru/
Дата: 05.02.08 14:21
Оценка:
Здравствуйте, cl-user, Вы писали:

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


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


CU>"Знак" скажет, что продукт соответствует хоть каким-то нормам и хоть что-то гарантирует. А при прочих равных условиях может оказаться решающим плюсом для принятия решения в пользу...


Вот когда ты нормы приведёшь и что-то конкретное, тогда можно обсуждать.

К>>А про "липовые" сертификаты уже упоминали.


CU>"Гав-гав-гав!!!" (это вместо 3-х этажного мата) ЗАКОНЫ ТОЖЕ ДАЮТ СБОИ, И НЕ РЕДКО — ОТМЕНИМ ВСЕ ЗАКОНЫ И БУДЕМ ЖИТЬ "ПО ПОНЯТИЯМ"?!!!


Для тебя весь мир бинарен и существует только белое и чёрное?
Жизнь по-моему намного интереснее на самом деле
Re[43]: Code Access Security - future is here :)
От: cl-user  
Дата: 05.02.08 14:55
Оценка:
Здравствуйте, Курилка, Вы писали:

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


CU>>"Знак" скажет, что продукт соответствует хоть каким-то нормам и хоть что-то гарантирует. А при прочих равных условиях может оказаться решающим плюсом для принятия решения в пользу...


К>Вот когда ты нормы приведёшь и что-то конкретное, тогда можно обсуждать.


С нормами проще. Самые простые — отсутствие переполнения стека, деления на ноль и т.п., отсутствие закладок... Что, сами трудно придумать? Есть программы — анализаторы сишного (и не только) кода — вот пусть хоть этим требованиям удовлетворяют Потом объединить большинство общеупотребительных требований в один (пусть) ISO — можно начинать сертифицировать

Блин, я должен кодеров учить писать программы?

К>>>А про "липовые" сертификаты уже упоминали.


CU>>"Гав-гав-гав!!!" (это вместо 3-х этажного мата) ЗАКОНЫ ТОЖЕ ДАЮТ СБОИ, И НЕ РЕДКО — ОТМЕНИМ ВСЕ ЗАКОНЫ И БУДЕМ ЖИТЬ "ПО ПОНЯТИЯМ"?!!!


К>Для тебя весь мир бинарен и существует только белое и чёрное?


Нет. Просто не надо рассматривать "крайние значения" (если не стоит задача рассматривать именно крайние значения) — при анализе они очень часто "отбрасываются".
Re[43]: Code Access Security - future is here :)
От: cl-user  
Дата: 05.02.08 14:57
Оценка:
Здравствуйте, eao197, Вы писали:

CU>>Да ну? Пока софтописатели ничем не ограничены, они продают рекламу — гербалайф и биодобавки.


E>В области заказного ПО это не так.


С заказным — согласен. Но как только появятся "общеупотребительные" сертификаты на ПО — очень быстро попросят им соответствовать и в заказном ПО.
Re[40]: Code Access Security - future is here :)
От: Cyberax Марс  
Дата: 05.02.08 15:00
Оценка:
Здравствуйте, cl-user, Вы писали:

C>>Технологии создания ПО эволюционируют, тут все нормально. Но кардинально вряд ли что-то в ближайшем будущем изменится.

CU>О, уже "вряд ли", а не "ничего нет". А если ещё усилия приложить?
А зачем? Тут ведь непонятно куда их прикладывать.
Sapienti sat!
Re[24]: Code Access Security - future is here :)
От: Cyberax Марс  
Дата: 05.02.08 15:01
Оценка:
Здравствуйте, cl-user, Вы писали:

C>>Как ты себе представляешь сотрудничество кучи разных компаний со всего мира?

CU>Не надо "кучи", надо "критической массы", которая (при числе конкурентов > 2) может быть меньше 50%.
CU>И вы таки не слышали скандалов по поводу "межкорпорационных сговоров", иногда между откровенными конкурентами?
Так что клиентам-то делать? Им микроскопы, однако, нужны. И качество программ, в целом, их вполне удовлетворяет.

Так как платить в 100 раз больше за абсолютно надежную программу, разработка которой займет 10 лет — им просто нет смысла.
Sapienti sat!
Re[41]: Code Access Security - future is here :)
От: cl-user  
Дата: 05.02.08 15:08
Оценка:
Здравствуйте, Cyberax, Вы писали:

C>>>Технологии создания ПО эволюционируют, тут все нормально. Но кардинально вряд ли что-то в ближайшем будущем изменится.

CU>>О, уже "вряд ли", а не "ничего нет". А если ещё усилия приложить?
C>А зачем? Тут ведь непонятно куда их прикладывать.

К разработке правил а-ля "расширенный стиль программирования"+доп. действий, соблюдение которых гарантирует отсутствие определённых ошибок в коде, и средств автоматической верификации на соответствие.
Re[25]: Code Access Security - future is here :)
От: cl-user  
Дата: 05.02.08 15:11
Оценка:
Здравствуйте, Cyberax, Вы писали:

CU>>Не надо "кучи", надо "критической массы", которая (при числе конкурентов > 2) может быть меньше 50%.

CU>>И вы таки не слышали скандалов по поводу "межкорпорационных сговоров", иногда между откровенными конкурентами?
C>Так что клиентам-то делать? Им микроскопы, однако, нужны. И качество программ, в целом, их вполне удовлетворяет.

Если их всё удовлетворяет, то делать здесь действительно нечего. А неудовлетворённым — искать пути выхода из неудовлетворительной ситуации.
Re[42]: Code Access Security - future is here :)
От: Cyberax Марс  
Дата: 05.02.08 15:17
Оценка:
Здравствуйте, cl-user, Вы писали:

C>>А зачем? Тут ведь непонятно куда их прикладывать.

CU>К разработке правил а-ля "расширенный стиль программирования"+доп. действий, соблюдение которых гарантирует отсутствие определённых ошибок в коде, и средств автоматической верификации на соответствие.
Так ноль проблем! Верификаторы кода доступны уже лет 30.

Только вот они требуют огромных затрат по их использованию. Причем доказано, что сильно лучше их не сделать — все время упираемся в неразрешимую проблему останова. Кроме того, даже если и есть 100%-верный проверятель, то встанет следующая проблема — а как проверить спецификацию?

Практичные частичные проверятели тоже есть, начиная от инспекций в IDEA (IDE для Java) и кончая PreFast'ом от MS и анализатором от Coverity.
Sapienti sat!
Re[34]: Code Access Security - future is here :)
От: dr.Chaos Россия Украшения HandMade
Дата: 05.02.08 15:44
Оценка:
Здравствуйте, cl-user, Вы писали:

DC>> ну тогда приведи пример, за того ПО за повышенную надежность которого, ты согласен заплатить больше денег. И насколько больше.


CU>За любое, которое сложнее `cp`, `rm` и т.д. "Больше" — понятие относительное. Для начала, думаю, достаточно прекратить OEM-поставки софта


Ну допустим убунта стоит 0, сколько ты готов за неё выложить, вместе со всем софтом? За гарантии качества. Кстати какие гарантии ты захочешь?

DC>>Гарантий и ответственности от производителя ПО конечно хочется, но как это адекватно реализовать непонятно.


CU>Надо думать. А не отмахиваться "Не, не хочу! Невозможно! Нафиг не надо!!!"


Ну вот твои предложения, кроме тестирования.

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


CU>Не более чем с любым другим товаром.


Другие товары через таможню везут, а в инете таможни ещё нет, и, надеюсь, не будет.

DC>>Мне это мой опыт подсказывает . Т.к. работаю я в такой компании, которая, в силу специфики софта, обязана вести жёсткий контроль качества и сертификацию тоже проходила, и тестирование на каждый чих. В итоге, реально работает только фидбэк от пользователей, которые, к тому же, жалуются на скорость внедрения новых фич.


CU>Хм, и ты 100% уверен, что виной тому, что "реально работает только фидбэк от пользователей" и т.д., _ТОЛЬКО_ внедрённый контроль качества и пройденная сертификация, и нет никакого пути улучшить ситуацию, не снизив при этом контроля за качеством?


Виновата не сертификация или контроль, а потребности пользователей: они хотят и надежность с гарантиями и новые фичи. Я же вижу очень много бюрократических процедур, которые отнимают моё время от основной задачи, их можно было б как то модифицировать, но, видимо, не хотят тратить ресурсы.

Короче виновато, то самое соотношение цена/качество. Мало того надо еще дорабатывать законодательство, чтоб я мог подать в суд на производителя ПО которое причинило мне урон, нужны средства для достоверного определения что именно эта программа причинила ущерб и т.п. Будет что-то подобное когда-нибудь или нет — не знаю, для некоторых областей вполне возможно. Но для массового ПО врядли.
Побеждающий других — силен,
Побеждающий себя — Могущественен.
Лао Цзы
Re[5]: Code Access Security - future is here :)
От: Mr. None Россия http://mrnone.blogspot.com
Дата: 06.02.08 04:26
Оценка:
Здравствуйте, Cyberax, Вы писали:

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


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


Ага, то есть как раз наоборот прогрызает дырку в стандартных системных средствах защиты и ограничения доступа, то бишь сама крутится под рутом и от своего имени предоставляет интерфейсы для доступа к привелигированным операциям? Ещё лучше! Ф топку такое решение.
1) Где гарантия, что в самой этой службе нет ошибок и зловредный код не внедриться в саму эту службу, раз она работает от рута, то очень удобно;
2) Как насчёт фиксации, того кто именно совершил операцию? Она имперсонирует своего пользователя? Если да, то как она выполняет привелигированную операцию требующую рута? Если нет, то как система зафиксирует что дейтсвие выполнил вася пупкин, а не root? На лицо потенциальная проблема "Непризнания участия"...


C>>>Так я же сказал, что DBUS — это COM с человеческим лицом В том смысле, что там вещи типа настроек безопасности используются легко и просто, в отличие от COM.

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

1) Не "вполне возможно", а просто можно и нужно.
2) Именно так делается в любом нормальном, профессионально разработанном серверном приложении.
3) Ничего сложного и громоздкого нет, всё очень просто, особенно, когда речь идёт о COM-security.
4) Система безопасность в NT была местами проще чем в Windows 2000 (про Windows Server 2008 я вообще молчу), проблемы были только с API по управлению ACL, но она легко решалась один раз написаниебиблиотеки (благо всё прозрачно и документировано).
5) Прежде чем говорить "я знаю" — подумайте, так ли это.


MN>>Вот тебе отдача:

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

Что значит user-friendly десктоп? Консоль администратора к серверу — это user-friendly десктоп? Если да, то какая разница? Если вы имеете в виду обычную пользовательскую систему, то на ней я лучше включу антивирус, брэндмауэр, вырублю для администратора нафик все UAC`и и прочую фигню (чтобы система не умничала передо мной, когда мне это не нужно), а сам буду работать обычным пользователем.


MN>>А FireFox вообще запускаем с Integrity Level`ом "Low Mandatory Level" чтобы он вообще ничего не мог менять и даже вопросов не задавал (настраивается с помощью стандартного UI). Так что вообще ничего писать не надо.

C>А злой вирус делает buffer overflow в FF, закачивает свое тело на диск и называет его "ОченьБезобиднаяПрограмма.exe". А потом запускает его и обходит UAC.

1) Программа с Integrity Level`ом "Low Mandatory Level" может сохранять данные только в определённый подкаталог домашнего каталога пользователя.
2) Integrity Level передаётся по наследством, всё что будет сохранено программой с Integrity Level`ом "Low Mandatory Level", будет иметь такой же Integrity Level и "ОченьБезобиднаяПрограмма.exe" не сможет ничего сделать.


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

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

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


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


Лишняя паранойя — это тоже чревато. С таким же успехом в Windows системах вы можете отобрать у всех администраторов привилегию "Take ownership of files or other objects", подредактировать дефолтные права на ветках реестра и файлах, где привилегии сохраняются (дабы запретить восстановление этой привилегии кому попало) и раздавать какие хотите права на принадлежащие вам объекты вплоть до полного запрета доступа администратора. Вот только если вы забудете пароль самого главного администратора, который может восстановить всё обратно, в этом случае даже перезагрузка не поможет...


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

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

Vista, Server 2008 — Integrity Levels.
XP, Server 2003 — Safer.

И никаких проблем.


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

C>Неудобно, появляются проблемы, например, при замене файлов.

Какие проблемы? Где? Причём тут замена файлов?


C>>>Так тут флеймы такие в свое время были.

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

Ах этот... Помню — согласен, полная фигня . В конце концов никто так и не ответил на мой вопрос: а где гарантии, что самый ранний нативный загрузчик не атакован и не подменён. И совсем не смешно, как кажется, если вспомнить Blue Pill от госпожи Рудковской: новый тип атаки на систему с применением возможностей аппаратной поддержки виртуализации на процессорах; когда малварь — это по сути маленький такой гипервизор, использующий эти самые аппаратные возможности поддержки виртуализации для того, чтобы запустиьтся на системе и потом загрузить из под себя ОС; тут уже никакие антивирусы не спасают — они его просто не видят...
Компьютер сделает всё, что вы ему скажете, но это может сильно отличаться от того, что вы имели в виду.
Re[6]: Code Access Security - future is here :)
От: Cyberax Марс  
Дата: 06.02.08 05:24
Оценка:
Здравствуйте, Mr. None, Вы писали:

MN>Ага, то есть как раз наоборот прогрызает дырку в стандартных системных средствах защиты и ограничения доступа, то бишь сама крутится под рутом и от своего имени предоставляет интерфейсы для доступа к привелигированным операциям? Ещё лучше! Ф топку такое решение.

MN>1) Где гарантия, что в самой этой службе нет ошибок и зловредный код не внедриться в саму эту службу, раз она работает от рута, то очень удобно;
Авторизацией занимается сам DBUS, коду которого мы доверяем. Адресное пространство службы защищено стандартными средстваим ОС.

Если зловредный код смог подсоединиться к службе, то значит он уже прошел авторизацию. Соответственно, нет никаких различий со случаем с использованием sudo/UAC. Кроме одного — код службы можно достаточно просто проаудитировать на проблемы безопасности, а в случае с sudo/UAC привиллегии получило бы всё приложение. Ну и можно еще службу ограничить дополнительно AppArmor'ом/SELinux'ом.

MN>2) Как насчёт фиксации, того кто именно совершил операцию? Она имперсонирует своего пользователя? Если да, то как она выполняет привелигированную операцию требующую рута? Если нет, то как система зафиксирует что дейтсвие выполнил вася пупкин, а не root? На лицо потенциальная проблема "Непризнания участия"...

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

C>>Да, это вполне возможно. Только вот никто так почти не делает — это сложно и громоздко. Я знаю, я как-то работал с системой безопасности NT. Там без бутылки не разобраться.

MN>1) Не "вполне возможно", а просто можно и нужно.
Тогда где у нас красивые и удобные аналоги? Я видел всего несколько приложений, которые использовали возможности DCOM для чего-то кроме простых вызовов. Одно из этих приложений (1С) в итоге переписали без DCOMа. Из моего опыта — с DCOMом постоянно были какие-то проблемы.

C>>Какой сервер? PolicyKit предназначен для user-friendly десктопа.

MN>Что значит user-friendly десктоп?
Интерфейс, который будет изпользоваться тупыми юзерами.

MN>Консоль администратора к серверу — это user-friendly десктоп? Если да, то какая разница? Если вы имеете в виду обычную пользовательскую систему, то на ней я лучше включу антивирус, брэндмауэр, вырублю для администратора нафик все UAC`и и прочую фигню (чтобы система не умничала передо мной, когда мне это не нужно), а сам буду работать обычным пользователем.

Работать тупому юзеру простым пользователем в Винде? Ха. Хахаха.

А UAC как раз чаще всего и отключают — чтоб не мешал.

C>>А злой вирус делает buffer overflow в FF, закачивает свое тело на диск и называет его "ОченьБезобиднаяПрограмма.exe". А потом запускает его и обходит UAC.

MN>1) Программа с Integrity Level`ом "Low Mandatory Level" может сохранять данные только в определённый подкаталог домашнего каталога пользователя.
А если я захочу сделать "Save as..." для картинки или документа? Упс... Ну или хотя бы поставить плугин (требуется запись в каталог FF)? И "Low Mandatory Level" идет лесом.

PolicyKit как раз и позволяет сделать, чтобы такие действия выполнялись без проблем.

MN>2) Integrity Level передаётся по наследством, всё что будет сохранено программой с Integrity Level`ом "Low Mandatory Level", будет иметь такой же Integrity Level и "ОченьБезобиднаяПрограмма.exe" не сможет ничего сделать.

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

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

Ну да, поэтому PolicyKit удобнее — там все просто и прозрачно.

MN>Лишняя паранойя — это тоже чревато. С таким же успехом в Windows системах вы можете отобрать у всех администраторов привилегию "Take ownership of files or other objects", подредактировать дефолтные права на ветках реестра и файлах, где привилегии сохраняются (дабы запретить восстановление этой привилегии кому попало) и раздавать какие хотите права на принадлежащие вам объекты вплоть до полного запрета доступа администратора.

А еще надо не забыть убрать привиллегию отладки, возможность устанавливать сервисы, не забыть закрыть множество мелких дырок и т.п. В общем, нереально. Особенно учитывая, что нет вещей типа сетевых меток безопасности. SELinux дает полностью систему контроля доступа на все стороны деятельности системы, фактически, получается capability-based security.

И да, из-за параноидальности SELinux для сервера вполне нормально использовать (я использую ), для десктопа — слишком неудобно. Очень часто встречаются случаи, когда безопасность мешает работе.

MN>Вот только если вы забудете пароль самого главного администратора, который может восстановить всё обратно, в этом случае даже перезагрузка не поможет...

С чего бы? Грузимся с live-cd, спокойно меняем из Линукса нужные ACLи, и телемаркет. Даже если раздел зашифрован, то надо просто знать пароль пользователя, умеющего его расшифровывать.

C>>FireFox/ThunderBird? Я лично один раз вирус через эксплоит в нем словил.

MN>Vista, Server 2008 — Integrity Levels.
MN>XP, Server 2003 — Safer.
MN>И никаких проблем.
Есть проблемы

C>>Неудобно, появляются проблемы, например, при замене файлов.

MN>Какие проблемы? Где? Причём тут замена файлов?
С сервисами проблема в том, что или нужно чтобы они имели доступ только к своему поддереву (чтобы можно было сделать наследуемые разрешения). Ставить разрешения на файлы вне своего поддерева — неудобно и непрактично. Т.е. если я хочу, чтобы сервис имел доступ к файлам system32/user32.dll, system32/gdi32.dll, system32/myprintdriver.dll но ни к каким другим — то мне придется добавлять ACLи на всю system32. Причем если autoupdate решит поменять myprintdriver.dll — то у нас все резко сломается.

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

В AppArmor мы отделяем политику безопасности от метаданных самого файла.

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

MN>Ах этот... Помню — согласен, полная фигня . В конце концов никто так и не ответил на мой вопрос: а где гарантии, что самый ранний нативный загрузчик не атакован и не подменён. И совсем не смешно, как кажется, если вспомнить Blue Pill от госпожи Рудковской: новый тип атаки на систему с применением возможностей аппаратной поддержки виртуализации на процессорах; когда малварь — это по сути маленький такой гипервизор, использующий эти самые аппаратные возможности поддержки виртуализации для того, чтобы запустиьтся на системе и потом загрузить из под себя ОС; тут уже никакие антивирусы не спасают — они его просто не видят...
Ну Blue Pill обнаруживается кучей способов пока что, тут никаких особых проблем.

А защита от замены начального загрузчика тоже есть. Правда, нужно заменить BIOS на EFI (Extensible Firmware Interface) — там есть возможность записать проверить, что загружаемое ядро имеет правильную цифровую подпись. Ну а ядро уже дальше само может проверить целостность системы. Это сейчас во всяких приставках как раз используется для защиты от mod-чипов. Да, и Линукс это тоже поддерживает
Sapienti sat!
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.