Германия – Австралия

Германия – Австралия

ZFS user and group quota

Начиная с ZFS версии 4 и ZFS пула версии 15 (проверить версию можно командами "zfs upgrade" и "zpool upgrade"), встроенных в Solaris 10 Update 8, на ZFS можно устанавливать пользовательские и групповые квоты. Далее по списку задач (для групп - просто меняйте везде "user" на "group"). Имена вымышленные, в ходе экперимента ни одного жетского диска не пострадало:
Задать квоту:
# zfs set userquota@ivan=1G mypool/coolfs

Посмотреть квоту:
# zfs get userquota@ivan mypool/coolfs

Посмотреть занятое пользователем пространство:
# zfs get userused@ivan mypool/coolfs

А больше, собственно, ничего и не нужно ...

Из минусов: не хватает возможности устанавливать квоты на пул. Плюс при интенсивном копировании данных на ФС квота может переполниться процентов на 20 ... следует учесть сие поведение ... об этом даже сказано в мане.

CacheFS

Сегодняшний материал - про CacheFS. CacheFS позволяет повысить производительность при работе с NFS и статичными файловыми системами. Материал подготовлен по мотивам сайта http://c0t0d0s0.org. Адаптированная версия на русском языке доступна по ссылке: CacheFS. Оригинальный текст здесь.

Работа - часть жизни.

С одним умным человеком мне довелось пообщаться мельком в течение одного дня. Но именно он оставил неизгладимое впечатление в моем сознании. Очень грамотный, открытый, искренний, исполняющий свои обещания (это выяснилось позже) - таким должен быть современный менеджер (не думайте, что я тут лесть пишу - он всё равно не местный). Но речь не о нём - речь о том, что от такого человека я узнал следующее: 
Все мы работаем, все мы тратим своё время на исполнение служебных обязанностей. Зачастую это преподносится, как зря прожитое, поскольку только личная жизнь есть то единственное, что имеет реальную ценность. 
Но так ли это? Неужели Вы не помните своих коллег, с которыми решали общие задачи, которые подсказывали Вам, как сделать лучше, которых, возможно, Вы учили разным вещам? Общие проекты, идеи, обсуждения, споры - всё это остаётся и всё это ценно - и не стоит думать, что работа - это нечто лишнее в Вашей жизни. Присмотритесь. Есть ли в Вашем коллективе кто-то, на кого Вы ориентируетесь? Или кто-то, с кем у Вас постоянно оживленная дискуссия на тему и без темы? Или кто-то, в ком Вы уверены на все 100, что сможете позвонить и он поможет Вам с возникшей личной проблемой. Естественно, ситуации бывают разные, но нужно стремиться к тому, чтобы работа не становилась зря прожитым временем зарабатывания денег - работа, в каком-то смысле, должна быть частью жизни - и тогда она будет в радость.

Оффтопик:
Вы не замечали, что многие из Ваших друзей уже свалили - да именно "свалили" - из России?

xargs

Век живи - век учись.
Открыл для себя xargs ...
xargs принимает обрабатывает свой стандартный вход (stdin) и передаёт это всё в качестве аргументов команде, указанной в качестве её (xargs) аргумента. Выглядит примерно так:

$ getent passwd | awk -F: '{print $1}' | xargs finger

в результате этой команды будет вызван finger по всем пользователям системы. При чём будет запущен будет только один finger с кучей аргументов, представляющих список пользователей через пробел - да именно через пробел. xargs разделяет поля входного потока по пробелам, табуляциям и переводам строки, и затем передаёт их все finger-у (в данном случае) в качестве аргументов.
Закономерно предположить, что командная строка вполне может переполнится - на этот счёт есть решение: ключик "-L <количество>" - при указании такого параметра xargs запустит команду несколько раз, передавая в качестве аргументов очередное <количество> строк.
Кроме этого она поможет при решении проблемы указанной в недавней записи про проблемы с пробелами в bash. В предложенном решении вместо "for"  можно использовать xargs с ключиком "-0" (цифра ноль):
$ cat spaces.txt | xargs -0
str1 str2 str3 str4
str5 str6 str7 str8
str9 str10 str11 str12
Объяснение "-0" и  прочие подробности - в "man xargs".
... взял её на вооружение.

Принятие решений

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

Чисто теоретически есть три типа методов - "рациональный": плюсы/минусы в столбик и "эмоциональный": хочу/не хочу, и "комбинированный": хочу,но лучше прикинуть.

Все делают это по разному. Ниже я лишь опишу свой метод (он безусловно не уникален, но мало ли кому пригодится).

1. Этап первый. "Очевидность выбора" 

Первым делом выбор проводится методом "очевидности" - если решение важное, но выбор очевиден, то и приступать к пункту 2 не имеет смысла. Безусловно здесь играет роль предыдущий опыт, знания, сообразительность ... и в том числе эмоциональность и люди, чьё мнение имеет высокий вес;

Если вкрадываются сомнения в предпочтительность одного из подходов - переходим ко второму этапу;

2. Этап второй. "Формулировка последствий"

На втором этапе нужно расписать все плюсы и минусы каждого из подходов - все-все-все, вплоть до мелочей. Это, в принципе, не сложно, если немного подумать. Займёт минут 10, но зато упростит жизнь в дальнейшем. Как про "слоников" (или про кого там ...) по пять и по три - большие, но по "пять", а эти по "три", зато маленькие. Так и тут плюсы и минусы всех слоников.

3. Этап третий. "Расстановка приоритетов" 

Осталось решить, что в итоге имеет самое важное значение. В примере выше нужно решить хотите ли Вы съэкономить и купить слоников "по три", или же в первую очередь Вам нужны "большие" слоники.

Резюмируя: Очевидность выбора -> Формулировка последствий -> Расстановка приоритетов;

А вообще коллеги сказали, что в природе существует такой вот интересный подход: 

Для принятия решения нужно ответить на четыре вопроса:

1. Что произойдёт, если я сделаю это?

2. Что не произойдёт, если я сделаю это?

3. Что произойдёт, если я не сделаю это?

4. Что не произойдёт, если я не сделаю это?

По окончании сбора информации, можно переходить к Этапу три "Расстановка приоритетов" ;)

В заключение оффтопик:

Обсудите с друзьями и коллегами: 

Работа. Мы тратим на неё почти всё своё время. В каком случае работа стОит того?

BASH. Проблема с пробелами в файлах.

Очень интересная проблема, в которую по началу все втыкают очень долго.
Например, есть файл, состоящий из строк, в которых есть пробелы. Допустим, нам нужно обработать его  в bash построчно. Первое что, приходит обычно в голову,  сделать примерно так:
> for i in `cat file.txt`; do command $i; done
Однако, результат себя не оправдывает:
> cat spaces.txt
str1 str2 str3 str4
str5 str6 str7 str8
str9 str10 str11 str12
> for i in `cat spaces.txt`; do echo $i;done
str1
str2
str3
str4
str5
str6
str7
str8
str9
str10
str11
str12
Происходит это потому, что "for" разделяет передаваемые ему поля не только по переводу строки, но в том числе и по пробелам, что в свою очередь и приводит к таким проблемам.

Частным решением проблемы может стать использование промежуточных переменных и редактора sed. Например так:

> for i in `cat spaces.txt|sed s/\ /:/g`; do k=`echo $i | sed s/:/\ /g` && echo $k;done

str1 str2 str3 str4

str5 str6 str7 str8

str9 str10 str11 str12

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

Как я планировал свой месяц.

Последнее время на работе не мог собраться с мыслями — занимался всем подряд и ничем конкретно — дела вроде как делались, но осознания того, что сегодня я сделал — «то», завтра сделаю «это», а за неделю успею провернуть «то-то и то-то» не было. В итоге планы сдвигались, и было ощущение, что что-то надо таки поменять..

В общем было решено потратить целый день на планирование своего времени на месяц вперед (благо работа позволяет такую роскошь).

Раньше уже занимался планированием своего времени на уровне «есть задачи — нужно сделать, записал в ежедневник — сделал». При этом в течение дня оставалось много свободного времени, которое тратилось на решение текущих задач и на тупняк — состояние, из которого временами бывает выйти очень сложно. Пытался для плаирования времени использовать системы управления проектами — разбивать задачи на подзадачи, расписывать по времени и т.д. Но всё это хорошо тогда, когда основаная задача состоит в том, чтобы разделить работу между участниками команды. В моём же случае ставилась цель «спланировать своё время на решение поставленных мне задач» - следующий уровень детализации планирования.

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

Итак:

Пункт первый: Берёте лист A4. и пишете те задачи, которые Вы хотите сделать в текущем месяце. В моём случае получилось 5 больших задач. Думаю, что задач должно быть до 6-7 - не больше. 

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

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

Далее переходим к следующему этапу. Переворачиваем листок и начинаем считать, сколько времени у Вас есть вообще.
Исходные данные: В месяце 22 рабочих дня (Апрель 2010), рабочий день — 8ч. Кроме этого: 1 час в день точно будет уходить на разговоры / чай / покурить и т.п.. Кроме этого, в каждой работе есть своя специфика. Например: в моём случае 2 часа в день можно смело выделить на участие в большом общем проекте (совещания, разговоры, дискуссии, споры, реализация), 3 часа в неделю на тренинги, 2,5 часа в неделю — на еженедельные совещания. В итоге получаем следующее:

У нас есть:176 часов рабочего времени в месяц;

1*22+2*22+3*4+2,5*4=88 часов уходит на «всякие дела», от которых никуда не деться.

Итого получаем — ровно 88 часов на решение поставленных задач.

Собственно далее всё просто:

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

Ну а далее самое интересное:

Берём любой календарный тул — будь то Outlook, Google Calendar – не суть — и начинаем выделять время каждого конкретного дня на конкретные задачи. При этом не забываем выделять свободное время на обед / разговоры / общие проекты (как в моём случае). Плюс ко всему учитываем сроки исполнения той или иной задачи — скажем, если Вам нужно сделать Задачу номер один через неделю — то все её подзадачи очевидно должны быть сделаны на этой неделе и т.д. При этом не забывайте вычеркивать / выделять на A4 те задачи, которые Вы внесли в календарь.

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

Не знаю сработает ли, но пока выглядит красиво.

SPARC. Как получить mac адрес из OpenBoot.

Заходим в OpenBoot и вводим следующие команды (выделены жирнокрасным).

Сетевые девайсы и MAC адрес выделены жирнозелёным.

{3} ok show-devs
/pci@9,600000
/pci@9,700000
/pci@8,600000
/pci@8,700000
/memory-controller@3,400000
/SUNW,UltraSPARC-III+@3,0
/memory-controller@2,400000
/SUNW,UltraSPARC-III+@2,0
/memory-controller@1,400000
/SUNW,UltraSPARC-III+@1,0
/memory-controller@0,400000
/SUNW,UltraSPARC-III+@0,0
/virtual-memory
/memory@m0,a0
/aliases
/options
/openprom
/chosen
/packages
/pci@9,600000/network@1
/pci@9,700000/network@2
/pci@9,700000/usb@1,3
/pci@9,700000/ebus@1
......
{3} ok cd /pci@9,700000/network@2
{3} ok .properties
assigned-addresses       82001010 00000000 00200000 00000000 00200000
                         82001030 00000000 02000000 00000000 00100000
pci-req-removal
compatible               pci108e,abba.20
                         pci108e,abba
                         pciclass,020000
                         pciclass,0200
reg                      00001000 00000000 00000000 00000000 00000000
                         02001010 00000000 00000000 00000000 00200000
version                  Gigaswift FCode 2.11 03/09/10
address-bits             00000030
max-frame-size           00004000
phy-type                 mif
model                    SUNW,pci-ce
device_type              network
name                     network
local-mac-address        01 02 ab 32 21 a2
66mhz-capable
fast-back-to-back
devsel-speed             00000002
class-code               00020000
interrupts               00000001

The end.

Тестирование знаний по ZFS

Вчера добавил тест по ZFS в свой курс (пока там только тест - лекции будут позже). Feedback приветствуется.

Как включить NFS логи в Solaris

Задача: понять кто и какие файлы читает на наших NFS-шАрах.
Взято тут. Проверено на собственном опыте. Переведено и пересказано далее по тексту.

По порядку:

1. Добавить "-o log" в /etc/dfs/dfstab. Например:

share -F nfs -o log -d "" /export/myshare

2. Перезапустить NFS сервис:
В Solaris 10:

myhost1# svcadm restart nfs/server

В Solaris 8 и Solaris 9:
myhost1# /etc/init.d/nfs.server stop && /etc/init.d/nfs.server start

3. Логи смотреть тут:

/var/nfs/nfslog

Изменение IP адреса и имени хоста в Solaris 10

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

• /etc/hostname. (Например: /etc/hostname.ce0) - в данном файле нужно указать имя хоста. Содержимое этого файла влияет на IP  адрес хоста, который будет взят из файла /etc/inet/hosts при загрузке;

myhost1 # cat /etc/hostname.ce0

myhost1

• /etc/nodename - то же самое. Содержимое этого файла влияет на имя хоста (hostname);

myhost1 # cat /etc/nodename

myhost1

• /etc/inet/hosts - здесь нужно указать IP адрес.

myhost1# grep myhost1 /etc/inet/hosts

10.20.30.40     myhost1

• /etc/inet/netmasks - если подсеть имеет нестандартную маску, то её нужно указать здесь:

myhost1# grep 10.20.30. /etc/inet/netmasks

10.20.30.0    255.255.255.0

• /etc/defaultrouter - шлюз "по-умолчанию".

myhost1# cat /etc/defaultrouter

10.20.30.1
После перезагрузки изменения вступят в силу.

Если же нужно сделать то же самое но "на лету", то делаем следующее (или нечто подобное):
# ifconfig ce0 10.20.30.40 netmask 255.255.255.0

# hostname myhost1

# route add default 10.20.30.1

Всё.

Системная утилита для Solaris 10

Ниже представлен фрагмент второй лекции курса "Безопасность сетей на базе ОС Solaris 10". 
Утилита getent позволяет запрашивать информацию из всех типов баз. Однако, запрашивать информацию из базы shadow она не может, и об этом чётко сказано на man-странице getent (строго говоря в списке баз, с которыми может работать getent нет базы shadow). Почему такая ситуация имеет место быть, сказать сложно, поскольку реализовать данный функционал можно даже своими силами. Ниже приведен пример как это можно сделать.

Итак ...

Для получения информации из системных баз используются библиотечные функции, такие как: gethostbyname, getpwuid, getpwnam, getaddrinfo и другие. Они не зависят от конкретного расположения базы, и одинаково работают для всех типов баз. Например, функция gethostbyname() запрашивает информацию о хосте на основе заданного имени, а функция getpwnam()  ищет запись в базе passwd паролей по имени пользователя; А вот функция getspent() выполняет запросы к базе shadow. На её основе и создана следующая утилита, которая выводит логины и хэши паролей всех пользователей из этой самой базы.

#include <sys/types.h>
#include <unistd.h>
#include <pwd.h>
#include <stdio.h>
#include <stdlib.h>
#include <shadow.h>
#include <crypt.h>
#include <string.h>

int main (void)

{

    struct spwd *spwd_info;

    char *pwd;

    char *lname;

    setspent;

    while (spwd_info = getspent()) {

        printf("%s:%s\n",spwd_info->sp_namp, spwd_info->sp_pwdp);

    }

    return (0);

}

Компилируем и используем (gcc, cc, ... ).

Собственно всё ...

* Записаться на онлайн-курс "Безопасность сетей на базе Solaris 10" можно на сайте http://opencourses.ru

Sun Tech Days 2010

Несколько лет подряд в СПб проходит конференция Sun Tech Days - ежегодно проводимое мероприятие для IT-специалистов, где можно было узнать новости о последних разработках Sun Microsystems (впрочем ... теперь, видимо, "разработках Oracle"); послушать реальных администраторов и реальных разработчиков, рассказывающих реальные вещи; собственноручно разработать драйвер в рамках Hands-on Labs ... и просто почувствовать себя в кругу ... в огромном кругу! - таких же как ты технарей, которым просто _интересно_ все, что связано с миром IT.
В этом году это чудо будет называться Sun Tech Days 2010 :) и состоится 8-9 апреля. Для регистрации перейдите по этой ссылке. Увидимся. 

Обзор механизмов обеспечения безопасности ОС Solaris 10.

Введение

ОС Solaris является представителем большого семейства ОС Unix. Стоит отметить, что Solaris на данный момент является единственной коммерческой Unix системой, разработчики которой решили пойти пути открытия исходного кода операционной системы. Более того одна из наиболее современных ОС на данный момент доступна совершенно бесплатно для использования в любых целях. Много хороших слов можно сказать и про лицензию CDDL и про политику компании Sun Microsystems в отношении образовательных учреждений, однако сегодня мы начнем разговор о конкретных вещах – защите ОС Solaris.

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

Наряду с реализацией базовых функций по обеспечению безопасности, Solaris предлагает внушительный перечень инновационных механизмов защиты, которые мы вкратце рассмотрим на этой лекции:

• Process Rights Management;
• Role Based Access Control;
• Solaris Containers;
• Solaris Trusted Extensions;
• и ряд других;

Process Rights Management

В рамках классической модели администрирования Unix-систем особая роль отдается суперпользователю root, права которого в системе никак не ограничены. При этом возникает ряд негативных моментов, таких как:

• сложность разделения административных полномочий в системе;
• неограниченность доступа к ресурсам системы администратора.

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

Одним из решений данной проблемы, предлагаемых в ОС Solaris является предоставление процессам привилегий, необходимых им для выполнения определенных задач. Понятие «привилегии» является вполне конкретным и представляет собой дискретное право на выполнение какого-либо действия в системе. Использование привилегий устраняет необходимость использования setuid-программ.

Например, для установки системного времени, в модели без использования привилегий программе необходимо быть запущенной с правами суперпользователя (либо из под учетной записи root, либо установив на программу бит setuid). При использовании привилегий достаточно иметь привилегию sys_time. В этом случае данная программа сможет влиять только на системное время, но ни на любые другие компоненты ОС.

Таким образом понятие «привилегии» является ключевым компонентом управления правами процессов (Process Rights Management).

Более подробно использование привилегий будут рассмотрены в лекции 4 «Role Based Access Control».
Role Based Access Control

Так же, как привилегии являются основой для управления правами, RBAC является основой для управления правами пользователей. Права суперпользователя разделяются по т.н. профилям прав. Профили прав назначаются ролям, которые по своей сути являются учетными записями специального типа. Администратором системы предоставляются права пользователям входить в определенные роли, что позволяет разделить права по администрированию разных компонентов системы между разными пользователями.

Вместе с системой поставляются предопределенные наборы прав, которые охватывают большой спектр административных полномочий суперпользователя. В частности присутствуют такие профили прав как, Primary Administrator (эквивалент пользователя root), Cron Management (доступ к администрированию Cron), Printer Management (управление системой печати) и многие другие. Таким образом достаточно создать роль, приписать ей определенные профили прав из уже имеющихся и предоставить возможность определенным пользователям входить в эту роль. Так же профили прав с таким же успехом могут быть назначены и обычным пользователям.

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

• Primary Administrator – эквивалент суперпользователя;
• System Administrator – роль, с правами меньшими, чем Primary Administrator. Может управлять файловыми системами, системой электронной почты, программным обеспечением. Но имеет ряд ограничений по безопасности. Например, с ее помощью нельзя устанавливать пароли пользователей системы;
• Operator – роль администратора обладающая самыми маленькими административными правами, такими как управление резервным копированием и системой печати.

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

Solaris Containers

В технологию Solaris Container входят две технологии:

• Управление ресурсами (Resource Management);
• Зоны (Zones).

Первая реализует механизм контроля использования приложениями системных ресурсов и позволяет:

• Распределять вычислительные ресурсы между приложениями, такие как, процессорное время, оперативная память и др.;
• Контролировать использование выделенных ресурсов и выделять необходимые дополнительные ресурсы при необходимости;
• Вести учет информации, которую можно использовать для анализа, биллинга и планирования выделения вычислительных мощностей;

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

Далее вкратце рассмотрим основы этих двух механизмов. Более подробно они будут рассмотрены в лекции Solaris Containers.

Resource Management

Для реализации управления ресурсами предусмотрены следующие механизмы решающие определенный круг задач:

• Механизмы ограничения (Constraint Mechanisms) – предоставляют администратору или разработчику устанавливать лимиты потребления ресурсов приложениями (в данном случае требуется пояснить, что ресурсы выделятся не конкретным приложениям, а т.н. «workloads» - набору связанных задач. Например: все приложения конкретного пользователя, все приложения проекта и т.п.);
• Механизмы планирования (Scheduling Mechanisms) – механизм принятия решений о выделении ресурсов приложениям;
• Механизмы разделения (Partitioning Mechanisms) – данный механизм позволяет привязывать перечень доступных ресурсов к набору связанных задач («workload»). Он позволяет гарантировать предоставление процессам требуемых системных ресурсов.

Объектами выделения ресурсов (объекты, которым выделяются ресурсы) в Solaris являются проекты (projects), задачи (tasks) и процессы (processes), взаимосвязи которых показаны на рисунке.


Вершиной дерева является проект. Каждый пользователь привязывается к определенному проекту или проекту по умолчанию, если такая привязка не выполнена администратором отдельно. При подключении к проекту создается новая задача. Процессы создаются в рамках этой задачи. Задачи создаются при выполнении следующих команд, действий и функций:

• login;
• cron;
• newtask;
• setproject;
• su;

Zones

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

В ОС Solaris представлены 2 типа зон – глобальная и неглобальная. Глобальная зона одна и из нее можно выполнять все действия по установке, настройке, загрузке и остановке неглобальных зон (количеством до 8129). Использование неглобальных зон для различных задач позволяет повысить безопасность системы за счет полной изоляции пользователей и процессов разных зон, при которой компроментация приложения или действия пользователей одной зоны никак не влияют на другие зоны;

Аудит системы.

Solaris Auditing

Аудит представляет собой сбор информации об использовании ресурсов системы. Собираемая информация содержит в себе в том числе и данные о событиях безопасности (security related), происходящих в системе. Эти данные можно использовать для расследования инцидентов, анализа угроз безопасности и других мероприятий.

В процессе аудита системы генерируются записи аудита, сохраняющиеся в файле на локальной ФС, NFS разделе, либо отправляемые по протоколу syslog на другой хост. Записи аудита генерируются в результате определенных событий. Записи аудита могут генерироваться:

• Приложениями;
• В результате определенного события;
• В результате системного вызова.

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

Basic Audit and Reporting Tool

BART представляет собой универсальный инструмент контроля целостности системы. Суть работы BART заключается в генерации слепка объектов файловой системы и последующей проверке этих объектов на соответствие сохраненному эталону. Контроль целостности реализуется за счет использования контрольных сумм MD5.

BART можно гибко настраивать. В частности можно указать определенный перечень объектов для проверки и параметры, используемые для сравнения эталона и проверяемого объекта (например конкретные атрибуты файла, а не все его атрибуты).

Trusted Extensions

Trusted Extensions представляет собой технологию защиты информации по уровням доступа, что позволяет реализовывать политику защиты информации вне зависимости от ее владельца. Уходя корнями в Trusted Solaris 8, сегодня эта технология реализована в стандартном ядре ОС Solaris 10.



Данный подход позволяет Solaris осуществлять поддержку обоих моделей:

• DAC (Discretionary Access Control), основанной на привязке предоставления доступа к владельцу;
• MAC (Mandatory Access Control), основанной на уровне доступа субъекта;

Основным понятием данной технологии является понятие метки («Label»), на основе которого субъектам системы предоставляется доступ к объектам системы. Ввиду своей простоты технология MAC, основанная на метках, является быстрее технологии DAC, основанной на дискретных правах доступа.

При отключенном уровне Trusted Extensions (что реализуется установкой в ядре булевой переменной, которая показывает режим проверки доступа) ядро не реализует политику MAC. После включения Trusted Extensions ядро системы при попытке доступа проводит проверку, основанную на сравнении меток субъектов системы, запрашивающих доступ, и меток объектов системы, к которым этот доступ запрашивается.

Реализация многоуровневого контроля доступа Trusted Extensions в Solaris соответствует Common Criteria Labeled Security Protection Profile (LSPP) и Role-Based Access Protection Profile (RBAC). Гарантируя высокую надежность, Trusted Extensions, в тоже время, обеспечивают совместимость и эффективность.

Совместимость достигается за счет использования существующих стандартов. При реализации Trusted Extensions не использовались какие-либо новые протоколы или новые атрибуты объектов файловой системы, что позволяет не использовать приложения без предварительной модификации. MAC реализуется за счет виртуализации среды исполнения средствами вышеупомянутой технологии Solaris Containers. Фактически для каждого уровня допуска (метки) создается собственная зона, в которой и запускаются приложения с соответствующим уровнем доступа.

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

Операционные системы, поддерживающие технологию MAC могут взаимодействовать через сеть с поддержкой разграничения уровня доступа. В рамках данной технологии каждый узел сети может работать на разных уровнях доступа (при существующей поддержке операционной системой данной технологии). Разделение трафика по уровням доступа выполняется за счет использования опции CIPSO (Commercial IP Security Option), характеризующей уровень доступа, в каждом отправляемом IP пакете. Таким образом имеется возможность строить сети, защищенные по уровням доступа.

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

Заключение

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

* Записаться на онлайн-курс "Безопасность сетей на базе Solaris 10" можно на сайте http://opencourses.ru