Блокирование доступа к Linux на промышленном уровне. Часть1: Удаление оболочки.

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

Эта фраза обязательно должна быть в начале новости.

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

Саныч, доброе утро, открой для себя увлекательный мир виртуальных машин.

Зачётная новость! Пишите ещё! :)

По ссылке не ходил. Неужели там наконец-то рассказано,
что делает команда rm -rf /

Людям, работающим с линаксом на вирт. машине эта новость не нужна.

Мда... Статья для бывшего виндового админа-параноика...

Конечно, легче выковырять драйвера для CD-ROM из ядра, чем проставить нужные права на файл в /dev :)

Конечно, все шелл скрипты надо переписать на C, там же можно допустить столько красивых багов и дыр! :)

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

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

Кстати, они ещё забыли выдрать из системы perl, tcl, python, ruby и другие скриптовые языки.

В общем, моё предложение: прописать автору статьи препарат "апстенка" в дозировке по 2 кирпича 3 раза в день после еды

+1

> Людям, работающим с линаксом на вирт. машине эта новость не нужна.

Людям, работающим с линАксом нужен логопед.

А вот интересно, насколько сложно в SELinux эмулировать возможности групповых политик в винде?

> А вот интересно, насколько сложно в SELinux эмулировать возможности групповых политик в винде?

Я не знаток винды(и se(x)linux-а тоже). Но можно попробовать посмотреть, как конкретные виндовые возможности реализовать в *nix.

> А вот интересно, насколько сложно в SELinux эмулировать возможности групповых политик в винде?

А в венде разве есть групповые политики типа как в линупсе?

Троллим?)))

Ну это примерно как для Старкон2 эмулировать DOS DosBox'om, который запущен под иксами в Дебиане, который запущен в VMWare... дальше сами знаете, куда Вам обращаться.

> Троллим?)))

в винде ещё переключалка раскладок неудобная :)

Я что то пропустил, но не нашёл там самого распространёного метода init=/bin/bash в загрузчике ?

а не давать рута пользователю не легче? ш з бред

> Я что то пропустил, но не нашёл там самого распространёного метода init=/bin/bash в загрузчике ?

так он же лечится словом restrict в /etc/lilo.conf. uлавное при этом - поменять строчку "password=tatercounter2000" на что-нибудь другое :)

> а не давать рута пользователю не легче? ш з бред

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

Я кстати уже посоветовал

Хотя парень как-будто вменяемый

сколько можно постить ненужный хлам под названием "статья" с известного сайта? пиарщик

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

пусть ставит себе в хомяк, в установке по ssh не вижу проблем, ходить никуда ненадо

а еще нужный софт можно ставить, к примеру, на nfs шару.

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

> пусть ставит себе в хомяк,

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

> в установке по ssh не вижу проблем, ходить никуда ненадо

проблем нет, а вот админа это зае^Wмучает

Открой для себя sudo :)

> А вот интересно, насколько сложно в SELinux эмулировать возможности групповых политик в винде?

Очень сложно эмулировать все дыры, вытекающие из того, что групповые политики не являются частью ядра. Групповые политики в Винде - это просто read-only ключи реестра, которые проверяются приложениями. Соответственно, их можно запросто обойти любым из следующих способов:

1) Найти программу, которая на эти политики плюет и делает, что надо.

2) Скопировать бинарник, заменить в копии проверяемые пути в реестре на несуществующие.

3) Написать DLL-ку, которая подменяет функции работы с реестром и прописать ее в HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Windows\AppInit_DLLs (или воспользоваться любым другим способом инъекции DLL).

С SELinux такие фокусы не проходят.

>проблем нет, а вот админа это зае^Wмучает

ну apt-get install сильно не мучает, а вот make && make install для каждого пользователя делать это кащунство, лучше уж в одном месте весь софт держать и по nfs шарить

> а еще нужный софт можно ставить, к примеру, на nfs шару.

конечно, можно /usr расшарить по сети. а как будет в плане тормозов? да и повтррюсь - не у всех набор софта будет одинаков

>конечно, можно /usr расшарить по сети. а как будет в плане тормозов? да и повтррюсь - не у всех набор софта будет одинаков

статью не читал :), а как там предлагается решать данную проблему?

> Открой для себя sudo :)

Если смотреть с точки хрения админа-параноика, то нельзя его открывать. Потому что во-первых, у sudo частенько появляются проблемы с безопастностью, во-вторых, пользователь сможет поставить дырявую прогу и через неё повысить свои привилегии.

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

>> конечно, можно /usr расшарить по сети. а как будет в плане тормозов? да и повтррюсь - не у всех набор софта будет одинаков

> статью не читал :), а как там предлагается решать данную проблему?

я б не стал действовать согласно тому, что написано в той статье, мне автор не кажется человеком с адекватным восприятием реальности. да там и не написано на эту тему :)

Групповые политики Windows это не средство обеспечения безопасности, это просто удобное средство администрирования. Безопасность обеспечивается другими средсвами, в частности - правами пользователя.

С другой стороны, ты мне скажи, где нужно что-то поменять, чтобы обойти Software Restriction Policy, заданную на контроллере домена? Где тот ключ реестра и кто имеет право его меняь? Где тот бинарник? Кто имеет право писать HKLM?

>Если смотреть с точки хрения админа-параноика, то нельзя его открывать. Потому что во-первых, у sudo частенько появляются проблемы с безопастностью, во-вторых, пользователь сможет поставить дырявую прогу и через неё повысить свои привилегии. Я не знаю, как правильно разделить полномочия на установку программ, потому и интересуюсь

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

хотя если разрешить пользователю через sudo пользовать apt, то левый пакет он уже не поставит, только тот - который есть в репозиториях прописанных в sources.list.

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

или их тоже на Си переписать?

отобрать звезду у IBM_dW за систематически тухлые новости :)

>возможно я чего-то путую, но мне казалось, что в болшенстве дистрибутивов init выполняет все-таки shell-скрипты... или их тоже на Си переписать?

на "промышленном" уровне все нужно переписывать на Си

> конечно, можно /usr расшарить по сети. а как будет в плане тормозов? да и повтррюсь - не у всех набор софта будет одинаков

Я когда-то делал такое с помощью rsync. т.е. просто на юзерских машинах тупо sync'ал /usr раз в месяц (cron).

> хотя если разрешить пользователю через sudo пользовать apt, то левый пакет он уже не поставит, только тот - который есть в репозиториях прописанных в sources.list.

и что. даже в официальном репозитории выплывают глючные проги. Вон дебовцы даже в stable нередко проблемы с безопасностью правят(правда, только их и ничего более). Всего-то делов - не поставить версию с пофиксанным багом и воспользоваться эксплоитом для глючной версии

>> конечно, можно /usr расшарить по сети. а как будет в плане тормозов?

> Я когда-то делал такое с помощью rsync. т.е. просто на юзерских машинах тупо sync'ал /usr раз в месяц (cron).

а если при установке нового софта производилось нечто большее, чем тупое копирование файлов в /usr? В общем, Вам повезло, что эта система у Вас не грохнулась

>и что. даже в официальном репозитории выплывают глючные проги. Вон дебовцы даже в stable нередко проблемы с безопасностью правят(правда, только их и ничего более). Всего-то делов - не поставить версию с пофиксанным багом и воспользоваться эксплоитом для глючной версии

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

>> Всего-то делов - не поставить версию с пофиксанным багом и воспользоваться эксплоитом для глючной версии

> баги то находят, я не спорю, но выпускаются также апдейты.

Прочитайте ту строчку, на которую Вы ответили и поймите, что это не спасёт.

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

Это ещё надо обнаружить. А если я тихо-мирно через дырку в защите сливаю конфиденциальные данные, то поймать сложно

> Потому что во-первых, у sudo частенько появляются проблемы с безопастностью

Простите, но это когда у sudo частенько(!) появлялись проблемы с безопасностью? Что-то прямо новость для меня.

>> возможно я чего-то путую, но мне казалось, что в болшенстве дистрибутивов init выполняет все-таки shell-скрипты... или их тоже на Си переписать?

> на "промышленном" уровне все нужно переписывать на Си

интересно, как будет проходить апдейт системы на "промышленном" уровне? ;)

>> Потому что во-первых, у sudo частенько появляются проблемы с безопастностью

> Простите, но это когда у sudo частенько(!) появлялись проблемы с безопасностью? Что-то прямо новость для меня.

Корявенько выразился. sudo _повышает_ уровень опасности уязвимостей. Но проблем находили немало(см гугель: http://www.google.ru/search?q=sudo+exploit&ie=utf-8&oe=utf-8&aq=t...)

Может красноглазый друг не знает, что:

пользователь, который создает групповую политику, должен обладать правами на чтение и запись в системный том контроллеров домена, кроме того, он должен иметь право модификации выбранного контейнера Active Directory.

на контроллерах доменов период применения политик равен 5-ти минутам. при работе компьютера в сети групповые политики могут измениться, поэтому они применяются периодически (по умолчанию каждые 90 минут, можно поставить каждые 7 секунд).

Что существет глобальная ассоциация объектов GPO - с такими контейнерами Active Directory, как сайты, домены и подразделения, т.е админы нижней ступени в иерархии не могут изменять политику высшей иерархии.

И эти люди говорят мне, что линакс - типа реальный энтерпрайз.

> И эти люди говорят мне, что линакс - типа реальный энтерпрайз.

Эти люди говорят "К логопеду!"

>>на "промышленном" уровне все нужно переписывать на Си

А еще кошернее будет на жабе или моно. ;-)

>на "промышленном" уровне все нужно переписывать на Си

Нифига, на java. Вообще ынтырпрайз будет.

если вместо nfs заюзать afs серьёзных проблем не будет

> И эти люди говорят мне, что линакс - типа реальный энтерпрайз.

речь шла не про то, как работают политики, а то как их обойти

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

Уважаемые г-да IBMеры! Нужно немного заботиться об имидже собственного ресурса и стараться не размещать статьи столь откровенно низкого технического уровня.

> речь шла не про то, как работают политики, а то как их обойт

Повторю:

Групповые политики Windows это не средство обеспечения безопасности, это просто удобное средство администрирования. Безопасность обеспечивается другими средсвами, в частности - правами пользователя.

С другой стороны, ты мне скажи, где нужно что-то поменять, чтобы обойти Software Restriction Policy, заданную на контроллере домена? Где тот ключ реестра и кто имеет право его меняь? Где тот бинарник? Кто имеет право писать HKLM?