Поиск по этому блогу

среда, 25 июля 2012 г.

Perl: сохраняем хэш (hash) в XML, считываем XML в хэш (hash)

Используем для этого модуль XML::Simple. Для дампа хэша используем Data::Dumper.
#!/usr/bin/perl

use strict;
use warnings;
use XML::Simple;
use Data::Dumper;
$Data::Dumper::Indent = 1;
$Data::Dumper::Terse = 1;
Имя XML-файла куда будем сохранять наш хэш:
my $conf_xml = 'serpol.xml';
Пример многоуровневого хэша:
my $routers = {
    "router0" => {
        user    => 'user0',
        password=> 'pass0',
        enable  => 'enab0',
        edgedev => {
            'switch00' => { type => "Cisco" },
            'switch01' => { type => "ExtremeNetworks" },
            'dslam0' => { type => "Alcatel 7324" }
        }
    },
    "router1" => {
        user    => 'user1',
        password=> 'pass1',
        enable  => 'enab1',
        edgedev => {
            'switch10' => { type => "Cisco" }
        }
    }
};
Вот таким вот образом мы сохраняем данные в XML-файл:
my $xml_os = XML::Simple->new();
open my $fh, '>:encoding(utf8)', $conf_xml or die "open($conf_xml): $!";
my $xml = $xml_os->XMLout( $routers,
    OutputFile => $fh,
    RootName => 'serpol',
    AttrIndent => 0,
    NoAttr => 0
);
close $fh;
undef $xml_os;
Вот, что у нас получилось:
<serpol>
  <router0 enable="enab0" password="pass0" user="user0">
    <edgedev name="dslam0" type="Alcatel 7324" />
    <edgedev name="switch00" type="Cisco" />
    <edgedev name="switch01" type="ExtremeNetworks" />
  </router0>
  <router1 enable="enab1" password="pass1" user="user1">
    <edgedev name="switch10" type="Cisco" />
  </router1>
</serpol>
А теперь прочитаем назад этот XML-файл в хэш:
my $xml_is = XML::Simple->new();
my $hash = $xml_is->XMLin( $conf_xml );
print Dumper( $hash );
undef $xml_is;
Дамп восстановленного хэша:
{
  'router1' => {
    'enable' => 'enab1',
    'password' => 'pass1',
    'user' => 'user1',
    'edgedev' => {
      'name' => 'switch10',
      'type' => 'Cisco'
    }
  },
  'router0' => {
    'enable' => 'enab0',
    'password' => 'pass0',
    'user' => 'user0',
    'edgedev' => {
      'dslam0' => {
        'type' => 'Alcatel 7324'
      },
      'switch01' => {
        'type' => 'ExtremeNetworks'
      },
      'switch00' => {
        'type' => 'Cisco'
      }
    }
  }
};

вторник, 24 июля 2012 г.

Аналог iperf в Cisco

Запускаем приёмник. На маршрутизаторе Cisco необходимо выполнить нижеописанные команды. Значения в скобках — значения по умолчанию, которые вступают в силу по нажатию ENTER. В настройках можно изменить окно TCP для имититации работы рабочих станций.
#ttcp
transmit or receive [receive]:
buflen [8192]:
bufalign [16384]:
bufoffset [0]:
port [5001]:
sinkmode [y]:
rcvwndsize [2144]: 4096
show tcp information at end [n]:
ttcp-r: buflen=8192, nbuf=2048, align=16384/0, port=5001, rcvwndsize=4096 tcp

Теперь необходимо запустить передатчик:
#ttcp
transmit or receive [receive]: trans
Target IP address: 192.168.0.254
buflen [8192]:
nbuf [2048]: 50
bufalign [16384]:
bufoffset [0]:
port [5001]:
sinkmode [y]:
buffering on writes [y]:
show tcp information at end [n]:
ttcp-t: buflen=8192, nbuf=50, align=16384/0, port=5001 tcp -> 192.168.0.254

Когда соединение установлено, приемник выводит в строке состояния сообщение о том, что связь установлена. После завершения передачи, приемник выводит статистику тестирования, которая показывает количество переданных данных, время передачи, рассчитанную пропускную способность, количество операций ввода/вывода для чтения данных:
ttcp-r: accept from 192.168.0.253 (mss 1460, sndwnd 2144, rcvwnd 4096)
ttcp-r: 409600 bytes in 61064 ms (61.064 real seconds) (~5 kB/sec) +++
ttcp-r: 301 I/O calls ttcp-r: 0 sleeps (0 ms total) (0 ms average)
Аналогичным образом передатчик делает вывод в строке состояния, когда он подключается к получателю. Когда передача завершена, передатчик показывает свою статистику:
ttcp-t: connect (mss 1460, sndwnd 4096, rcvwnd 2144)
ttcp-t: 409600 bytes in 60504 ms (60.504 real seconds) (~5 kB/sec) +++
ttcp-t: 50 I/O calls
ttcp-t: 0 sleeps (0 ms total) (0 ms average)
Дополнительно можно почитать тут http://worm.org.ua/2010/12/ttcp-iperf-cisco/

понедельник, 16 июля 2012 г.

Debian: i386 параллельно с amd64

- Есть ли жизнь на Марсе?
- Тоже нет!

Добавить архитектуру i386 в дистрибутив amd64 в Debian'е сейчас не просто, а очень просто:
sudo dpkg --add-architecture i386
После чего наслаждаемся возможностью установки пакетов архитектуры i386.
Зачем это надо?
Ну, к примеру, совсем недавно в Debian Sid куда-то делся ia32-libs, а skype 64-й архитектуры отказался без него работать и рекомендовал себя удалить. Пришлось ставить skype архитектуры i386 и продолжить наслаждаться общением:
sudo dpkg -i ./skype-install-i386.deb
sudo apt-get install -f

суббота, 7 июля 2012 г.

Использование разрешений POSIX в Linux

Томас Бёчлер (Tomas Bächler), перевод: attila
Оригинал http://archlinux.me/brain0/

В традиционных системах UNIX существовал единственный уровень привилегий: суперпользователь (root). Если вы root, вам позволено все. Но и простые пользователи иногда должны иметь возможность выполения привилегированных операций.

Есть два простых решения:
  1. временное получение прав суперпользователя, используя su или sudo;
  2. установка setuid бита на исполняемом файле.
В обоих случаях вы получаете привилегии суперпользователя целиком, и хотя таким образом обычно запустить только весьма ограниченное команд, ошибки в этих программах или библиотеках создают угрозу взлома. Злоумышленник может заставить делать программу то, для чего она изначально не предназначалась, вплоть до запуска командой оболочки root’а.

В 1997 году комитет по стандартам (POSIX 1003.1e) создал черновую версию стандарта расширений механизма защиты. Одно из таких расширений разбивает привилегии root на части, позволяя давать задача лишь часть его привилегий. Хотя этот стандарт так и остался черновиком, спецификация была завершена и фактически реализована в ядре Linux.

Начиная с версии 2.2, ядро Linux при выполнении системного вызова проверяет, есть ли у процесса необходимые разрешения, вместо проверки root ли вы. Процесс имеет три набора прав доступа: доступный (permitted), наследуемый (inheritable) и текущий (effective). Именно последний набор используется ядром при проверке, дозволяется ли процессу выполнение определенных операций. Наследуемые разрешения передаются новой программе при выполнении execve. Доступные же разрешения ограничивают множество всех возможных текущих разрешений, на которые только процесс может рассчитывать. Кроме того, процесс может добавлять в свой наследуемый набор только разрешения из доступного набора (если только у процесса не имеется разрешения CAP_SETPCAP в списке текущих, об этом позже).

Как процесс может управлять своими наборами разрешений, подробно описано в [4].

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

Полный список разрешений приведен в ман-странице capabilities (7) и в заголовочном файле /include/linux/capability.h. Примеры ниже будут касаться разрешения CAP_NET_RAW. Но прежде всего вы должны убедиться, что библиотека libcap 2.X установлена в системе. (Если вы используете Arch Linux, скорее всего, она уже установлена как зависимость coreutils).
$ pacman -Q libcap
libcap 2.19-1
$ pacman -Ql libcap | grep bin/
libcap /usr/sbin/
libcap /usr/sbin/capsh
libcap /usr/sbin/getcap
libcap /usr/sbin/getpcaps
libcap /usr/sbin/setcap
{
Для Debian'а:
$ aptitude show libcap2 libcap2-bin
$ apt-file show libcap2 | grep bin/ | grep -v doc
libcap2-bin: /sbin/capsh
libcap2-bin: /sbin/getcap
libcap2-bin: /sbin/getpcaps
libcap2-bin: /sbin/setcap
}

Мы будем использовать утилиту setcap для управления разрешениями файлов. Для этого файловая система должна поддерживать расширенные атрибуты файлов (это, например, ext2/ext3/ext4). Прежде чем мы, наконец, начнем действовать, рассмотрим, что означают термины доступный, наследуемый и текущий наборы в контексте файловых разрешений.

Доступные разрешения исполняемого файла становятся доступными разрешениями процесса после запуска файла, вне зависимости от наследуемых разрешений процесса. Наследуемые разрешения файла соотносятся с наследуемыми разрешениями процесса, и «пересечение» добавляется к доступным разрешениям процесса. Текущее разрешение файла — это даже не набор, а единственный бит. Если он установлен, после запуска файла все доступные разрешения процесса становятся его текущими разрешениям, если нет — ни одно из доступных разрешений не будет текущим.

Итак, начнем. Файл /bin/ping традиционно имеет установленный setuid-бит для работы:
$ ls -l /bin/ping
-rwsr-xr-x 1 root root 30824 Фев 23 21:40 /bin/ping
Уберем его и установим текущий бит и CAP_NET_RAW разрешение:
$ chmod -s /bin/ping
$ setcap cap_net_raw=ep /bin/ping
$ getcap /bin/ping
/bin/ping = cap_net_raw+ep
ping продолжает работать! То же самое можно проделать и с traceroute. Но есть программы, с которыми это не проходит. Некоторые программисты считают нужным проверить, root ли вы, перед выполнение определенного системного вызова. Так, программа tcptraceroute содержит такой код:
if (getuid() & geteuid())
fatal("Got root?\n");
Эта программа не будет работать без прав суперпользователя, даже если разрешить CAP_NET_RAW.

Хорошо, но как сделать, чтобы привилегированные функции программы были доступны лишь некоторым пользователям? Чтобы решить эту проблему, Tomas Bächler написал небольшую утилиту, capsudo. Для работы этой утилиты необходмо наличие libcap и iniparser в системе. Сборка и установка выполняется командами make и make install. Исполняемый файл capsudo должен иметь установленное разрешение CAP_SETPCAP.  CAP_SETPCAP позволяет процессу добавлять в набор наследуемых любые разрешения, даже те, которые отсутствуют среди доступных, но не позволяют им быть доступными, пока не будет выполнена программа с установленным соотетсвтующим наследуемым разрешением файла.

Установим для /bin/ping CAP_NET_RAW в качестве наследуемого разрешения:
$ setcap cap_net_raw=ei /bin/ping
и добавим следующую секцию в /etc/capsudoers:
[ping]
caps = cap_net_raw
command = /bin/ping
users = user1 user2
allow_user_args = 1
Теперь пользователи user1 и user2 могут запускать ping без прав суперпользователя командой
capsudo ping 127.0.0.1
Просто команда `ping’ работать уже не будет, так как у файла /bin/ping есть только наследуемое разрешение, а не доступное. Процесс же capsudo, проверив права пользователя в /etc/capsudoers, добавляет CAP_NET_RAW-разрешение в список своих наследуемых разрешений (это ему позволено, так как у файла capsudo установлено разрешение CAP_SETPCAP). Когда capsudo запускает ping, наследуемое разрешение файла совпадает с наследуемым разрешением процесса и добавляется в список доступных (и, соответсвенно, текущих, так как у файла /bin/ping установлен текущий бит).

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

Итак, у файла /bin/ping разрешения остаются прежними
getcap /bin/ping
/bin/ping = cap_net_raw+ei
В /etc/pam.d/login добавляем строчку:
auth        required    pam_cap.so
Файл /etc/security/capability.conf приводим к виду:
cap_net_raw user1
none *
После входа в систему командная оболочка пользователя user1 будет иметь установленное наследуемое разрешение cap_net_raw. Действительно:
$ getpcaps $$
Capabilities for `3658': = cap_net_raw+i
Теперь пользователь user1 будет иметь возможность запускать программу ping, если заходит в систему обычным образом (и не будет иметь такой возможности, когда заходит, например, по ssh, так как использование модуля pam_cap прописано только в /etc/pam.d/login).

Ссылки:
[1] man 7 capabilities
http://www.kernel.org/doc/man-pages/online/pages/man7/capabilities.7.html
[2],[3] Tomas Bächler, его блог
http://archlinux.me/brain0/
http://archlinux.me/brain0/2009/07/28/using-posix-capabilities-in-linux-part-one/
http://archlinux.me/brain0/2010/01/05/using-posix-capabilities-in-linux-part-two/
[4] Серж Е. Халлин, «Разрешение POSIX для файлов: разделяем полномочия root»
http://www.ibm.com/developerworks/ru/library/l-posixcap/l-posixcap.html#
[5] Chris Friedhoff, POSIX Capabilities & File POSIX Capabilities
http://www.friedhoff.org/posixfilecaps.html

Примечение переводчика:
Слово ‘capability’ всюду переведено словом „разрешение“, как это сделано в [4].



Копипаст http://posix.ru/freenotes/linux/51, касательно Debian'а - отсебятина ;)