OpenOffice.org становится привлекательной мишенью для хакеров

>> В том то и дело, что увлеклись обсасыванием этой темы. Мне как раз глубоко наср^Wвсё равно, какие рутовые файлы пропадут: > я не слакваршик, и легко могу восстановить системные пакеты. Но файлы лежащие у меня в ~, для меня очень ценны.

>Открой для себя backup в места не доступные пользователю.

Еще один теоретик, блин. Пока робот ищет нужную кассету и перематывает её пол-дня может пройти. А это - рабочее время.

>Если хочешь чтобы было намного безопаснее чем в винде - не делай ничего, уже все гораздо безопаснее.

Это - спорный вопрос. И потом, не важно как оно там в винде, важно как оно тут, достаточно ли безопасно.

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

> Если еще больше - можно 44 пользователя скриптом завести, это толково придумано,

А уж пользователи-то будут как благодарны, за доп. удобства.

>SELinux, grsecurity

Как они могли бы помочь против дырке в OpenOffice? Опять теория?

> В том то и дело, что увлеклись обсасыванием этой темы. Мне как раз глубоко наср^Wвсё равно, какие рутовые файлы пропадут: я не слакваршик, и легко могу восстановить системные пакеты. Но файлы лежащие у меня в ~, для меня очень ценны.

Открой для себя бакап-сервера, кои умеют кэшировать инфу на своем надежном сторэйдже, перед записью на ленту. Грохнется /lib/libc.so.6, например, посмотрю я, как "легко" она восстановится без остановки машины...

> Что теперь, заводить по дополнительному пользователю на каждую прогу? Один для фаерфокса, один для опенофиса, и т.д..? Очень классно, если за компом работают 4 человека и каждый пользуется 10ю прогами, мне теперь надо 44 пользователя заводить? Толково придумано.

google -> "Mandatory Access Control", а стандартные пользователи для системных демонов уже заведены заранее в любом дистрибутиве.

> > Открой для себя backup в места не доступные пользователю.

> Еще один теоретик, блин. Пока робот ищет нужную кассету и перематывает её пол-дня может пройти. А это - рабочее время.

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

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

Не используй. Зачем юзеру на рабочем месте браузер? Или комбайн типа "MS Office" куда безопаснее или надежнее? Ключевое слово - "апдейт".

> А уж пользователи-то будут как благодарны, за доп. удобства.

И нафига такие извращения? "Если линукс не может помочь вам в решении проблемы - это неправильная проблема".

> Как они могли бы помочь против дырке в OpenOffice? Опять теория?

Очень просто - берем и режем доступ на запись и выполнение OOo везде кроме ~/docs юзера, плюс запрещаем макросы в OOo и средствами MAC запрещаем модификацию его конфигов. Элементарное решение "в лоб".

>И нафига такие извращения? "Если линукс не может помочь вам в решении проблемы - это неправильная проблема".

"Смеялсо!"

>> Как они могли бы помочь против дырке в OpenOffice? Опять теория?

>Очень просто - берем и режем доступ на запись и выполнение OOo везде кроме ~/docs юзера, плюс запрещаем макросы в OOo и средствами MAC запрещаем модификацию его конфигов. Элементарное решение "в лоб".

...которое мало что меняет. Ну снесёт фин-директору не весь ~, а только ~/docs, думаешь, спасёт это админа? :)

>Открой для себя бакап-сервера, кои умеют кэшировать инфу на своем надежном сторэйдже, перед записью на ленту.

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

>Грохнется /lib/libc.so.6, например, посмотрю я, как "легко" она восстановится без остановки машины...

А зачем её восстанавливать без остановки машины? Мы говорим о рабчей станции. Кто будет OO на сервере пускать?

>google -> "Mandatory Access Control", а стандартные пользователи для системных демонов уже заведены заранее в любом дистрибутиве.

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

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

> "Смеялсо!"

RMS вообще прикольный тип ;)

> > Очень просто - берем и режем доступ на запись и выполнение OOo везде кроме ~/docs юзера, плюс запрещаем макросы в OOo и средствами MAC запрещаем модификацию его конфигов. Элементарное решение "в лоб".

> ...которое мало что меняет. Ну снесёт фин-директору не весь ~, а только ~/docs, думаешь, спасёт это админа? :)

Кто снесет? Мсье плохо прочитал мессагу? ;)

> На работе где я работал уже 6 лет назад, бэкапилось около 100 Террабайт данных. Много можно было накэшировать, как ты думаешь?

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

И еще одно интересно - неужто эти 100тер лились с одной системы, этот поток не поддавался распаралллеливанию и т.п. Сдается мне, нечисто тут дело ;)

Те 100 терабайт походу были результатами расчетов на BlueGene? ;) Офигеть... 6 лет назад...

> А зачем её восстанавливать без остановки машины? Мы говорим о рабчей станции. Кто будет OO на сервере пускать?

Ну... а зачем вообще доводить дело до необходимости что-то восстанавливать - видимость занятости создавать? Политика "deny by default" не зря была придумана и мало где не может быть рекомендована.

> Подумай сам, чем это поможет пользователю сохранить документы.

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

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

Ну так к кому претензии? Так и делается, Х11 раздробили, GNOME изначально такой, KDE поддается... вполне возможно, что в скором времени и ООо покрошат и т.п.

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

Да это бы решило проблему, но в реальной жизни ни у кого пока не получилось таким путем пойти. Проблема в том что пользователи хотят очень много и им несколько наплевать на безопастность. Майкрософт им предлагает дырявые Офис/Экслорер решения которые много могут.

Если ограничить функционал - проблема исчезнет. Запретить документы в форматах требующих больших программ. Например text только в txt, или в html со строго ограниченным набором простых тагов (<b>,<i>,<h1>,<p>,<center> и т п) без javascript и без java.

На прокси поставить резку javascript и html не соответствующему w3c стандратам.

Будет очень секьюрно и без костылей, только пользователи тебя пошлют и будут использовать другое более дырявое но более работающее решение.

Безопастность и стабильность для большинства совсем не главное в этой жизни! Билли это понял раньше многих.

>> Если еще больше - можно 44 пользователя скриптом завести, это толково придумано, > А уж пользователи-то будут как благодарны, за доп. удобства.

Можно настроить для них это прозрачно так что они не будут об этом знать.

>> SELinux, grsecurity > Как они могли бы помочь против дырке в OpenOffice? Опять теория? Подумай еще.

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

Надеюсь в ~/Documents/external_docs/ не терабайт лежит и это можно каждый день бэкапить.

Кстати есть ли в природе программа offline валидатор html ?

Я хочу проверить что это
- корректный xml/html, все открытые таги коректно закрыты
- набор тагов из списка разрешенных.
- уровень вложенности <table> не более 5
- строчек во всех таблицах не более 10000.
- уровень вложенности других тагов не более 30.

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

ну дык. Я думаю, что и не жмотились.

>И еще одно интересно - неужто эти 100тер лились с одной системы, этот поток не поддавался распаралллеливанию и т.п. Сдается мне, нечисто тут дело ;)

Само собой, что не с одной. А что это меняет?

>Те 100 терабайт походу были результатами расчетов на BlueGene? ;)

Нет, но часть из них могла быть входными данными для этих расчётов :)

>Офигеть... 6 лет назад...

Угу. Тогда еще не жмотились ни на IT, на на исследования генома.