XEN VM server with Linux HA 
The setup below uses XEN and HA components to provide smooth backgroud for running services on VM machines. The setup consists of two servers interconnected by Gbit crossover link which is mandatory for fast and reliable live VM migration and is also used for DRBD and heartbeat.

Software used here is DRDB, Linux heartbeat and XEN server with live VM migration functionality.

The /etc/hosts file:            xen1 xen2

Components installed for heart-beat:

heartbeat-stonith-2.1.3-3.el5.centos *
heartbeat-2.1.3-3.el5.centos *
heartbeat-gui-2.1.3-3.el5.centos *
heartbeat-pils-2.1.3-3.el5.centos *

DRBD components:


The HA setup file (/etc/ha.d/ha.cf):

use_logd yes
bcast eth2
node xen1 xen2
crm on

The HA setup file (/etc/ha.d/authkeys):

cat auth 1

XENd config file (/etc/xen/xend-config.sxp):

(xend-relocation-server yes)
(xend-address 'xen1')
(xend-relocation-hosts-allow '^xen1$ ^xen2$ ^localhost$')
(xend-unix-server yes)
(xend-unix-path /var/lib/xend/xend-socket)
(network-script network-bridge)
(vif-script vif-bridge)
(dom0-min-mem 256)
(dom0-cpus 0)
(vncpasswd '')

The other server must have:

(xend-relocation-server yes)
(xend-address 'xen2')
(xend-relocation-hosts-allow '^xen1$ ^xen2$ ^localhost$')
(xend-unix-server yes)
(xend-unix-path /var/lib/xend/xend-socket)
(network-script network-bridge)
(vif-script vif-bridge)
(dom0-min-mem 256)
(dom0-cpus 0)
(vncpasswd '')

Our DRBD file (/etc/drbd.conf) which is the same on both xen servers:

common {
protocol C;

resource r0 {

startup {
become-primary-on both;

syncer {
rate 51200;

net {
after-sb-0pri discard-zero-changes;
after-sb-1pri discard-secondary;
after-sb-2pri disconnect;

device /dev/drbd1;
disk /dev/loop7;
meta-disk internal;

on xen1 {
on xen2 {

To spawn heartbeat gui:

# /usr/bin/hb_gui &

To spawn XEN manager:


To check the cluster status:


Last updated: Sun May 25 09:46:30 2008
Current DC: xen1 (3ff2a9ca-13be-41a5-a8f8-2657402e32f2)
2 Nodes configured.
1 Resources configured.

Node: xen1 (3ff2a9ca-13be-41a5-a8f8-2657402e32f2): online
Node: xen2 (e61ad97b-2750-4cf4-a307-2a9c48929a2a): online

vm05_r (heartbeat::ocf:Xen): Started xen2

Failed actions:
vm05_r_monitor_0 (node=xen1, call=6, rc=1): Error

The DomU resource in Linux HA was created using HA management gui. You will need to set the 'Parameters' on at 'Resource' as follows: allow_migrate=true, this allows live migration of virtual machines.

Do not forget to set the path to virtual machine configuration file using xmfile parameter.

[ add comment ] ( 2 views )   |  [ 0 trackbacks ]   |  permalink
Apache: protecting directory content using .htpasswd 
Create htaccess definition file: /var/www/html/directory/.htaccess:

AuthType Basic
AuthName "Please enter username and password"
AuthUserFile /var/www/html/directory/.htpasswd
Require valid-user

Create new password file for the user and set initial password:

# htpasswd -c passwordfile username

cat /var/www/html/directory/.htpasswd

Allow the apache to use the config in /etc/httpd/conf/httpd.conf:

# AllowOverride controls what directives may be placed in .htaccess files.
# It can be "All", "None", or any combination of the keywords:
# Options FileInfo AuthConfig Limit
AllowOverride All

# AccessFileName: The name of the file to look for in each directory
# for additional configuration directives. See also the
# AllowOverride directive.
AccessFileName .htaccess

# The following lines prevent .htaccess and .htpasswd files from
# being viewed by Web clients.
<Files ~ "^\.ht">
Order allow,deny
Deny from all

<VirtualHost host.domain.cz:80>
AccessFileName /var/www/html/directory/.htaccess
DocumentRoot /var/www/html/directory/
ServerName domainname.dom
ServerAdmin administrator@domainname.dom

Do not forget to edit the other AllowOverride

# AllowOverride controls what directives may be placed in .htaccess files.
# It can be "All", "None", or any combination of the keywords:
# Options FileInfo AuthConfig Limit
AllowOverride All

[ add comment ] ( 1 view )   |  [ 0 trackbacks ]   |  permalink
Apache /var/log/httpd/error_log: unable to check htaccess file, ensure it is readable 
It has nothing to do with htaccess file, the right reason is the apache "cannot read the directory or file". Set the folder permission to "750" and the folder group owner to apache.

Also check if the directory context is set to apache content when you are runing SeLinux.

# ls -lZ /directory/
# chcon -R -h -t httpd_sys_content_t /directory/path/

[ add comment ] ( 5 views )   |  [ 0 trackbacks ]   |  permalink
Minority Report' OS brought to life (from http://www.engadget.com/) 
Engadget: One of the science advisors from the Steven Spielberg film -- along with a team of other zany visionaries -- has created an honest-to-goodness, real-world implementation of the computer systems seen in the movie.

[ add comment ] ( 6 views )   |  [ 0 trackbacks ]   |  permalink
Linux: udev rules (persistent iSCSI device mapping) 
The following udev rule example runs the script which provides consistent and transparent iSCSI mapping to simple /dev/short_name mapping. If the target share is created with the recognized format (for example iqn.2008-redhat.com:iscsi1.vm07) the script maps the target to /dev/vm07.


KERNEL=="sd?", BUS=="scsi", ENV{ID_MODEL}=="VIRTUAL-DISK", \
ENV{ID_PATH}=="*iscsi*", RUN+="/etc/xen/scripts/iscsi \
$env{ID_PATH} %k"


LINK_NAME=`/bin/echo $1 | awk -F":" '{ print $3 }' | \
awk -F"." '{ print $2 }'`
/bin/ln -s /dev/$2 /dev/$LINK_NAME

Some udev commands to query udev data and testing rules:

udevinfo -a -p $(udevinfo -q path -n /dev/sda)
udevinfo -q env -p $(udevinfo -q path -n /dev/sda)
udevtest $(udevinfo -q path -n /dev/sdf)

[ add comment ] ( 7 views )   |  [ 0 trackbacks ]   |  permalink
Linux: mirroring raw or targets for HA 

# yum -y install drbd82 kmod-drbd82-xen

Configuration steps here. The DRBD site (from which the diagram below is taken) is here.

Prepare the raw filesystem space and mount via losetup (in /var/raw/brd1.sh, the /etc/init.d/drbd calls this script):

# losetup /dev/loop7 /var/raw/brd1.img

Installl xen-related drbd and drbd-kernel module.

# yum install kmod-drbd82-xen.x86_64 -y
# yum install kmod-drbd-xen.x86_64 -y

Configure /etc/drbd.conf:

common {
protocol C;

resource r0 {

startup {
become-primary-on both;

syncer {
rate 512M;

net {
after-sb-0pri discard-zero-changes;
after-sb-1pri discard-secondary;
after-sb-2pri disconnect;

device /dev/drbd1;
disk /dev/loop7;
meta-disk internal;

on labt03.dev.xxx.com {
on labt04.dev.xxx.com {

Create device metadata.

# drbdadm create-md resource

Associates the DRBD resource with its backing device.

# drbdadm attach resource

Connects the DRBD resource with its counterpart on the peer node.

# drbdadm connect resource

DRBD's virtual status file in the /proc filesystem. Similar to /proc/mdstat.

# cat /proc/drbd

Start the initial full synchronization.

# drbdadm -- --overwrite-data-of-peer primary resource

Split brain:

# drbdadm secondary r0
# drbdadm -- --discard-my-data connect r0

[ add comment ] ( 5 views )   |  [ 0 trackbacks ]   |  permalink
Linux: kpartx mount block device from file 
kpartx zpřístupní jednotlivé diskové oddíly (podle tabulky oddílů) jako samostatná bloková zařízení. Přiklad ukazuje mapování oddílů ze souboru.

losetup /dev/loop0 file
kpartx -a /dev/loop0

Nové devices jsou k dispozici pod /dev/mapper

# ls -la /dev/mapper/*

Vytiskne seznam nalezených oddílů:

kpartx -l device

Odstraní mapování oddílů:

kpartx -d device

Prezentace k LVM2... ze které je to opsáno.

Adding more loop devices in /etc/modprobe.conf:
options loop max_loop=16
options netloop nloopbacks=8

[ add comment ] ( 6 views )   |  [ 0 trackbacks ]   |  permalink
Linux: XEN virtualization and live migration (2x XEN servers, 1x iSCSI target) 
Setup is two XEN servers and one iSCSI server. Both XEN servers do have 1Gbit dedicated connection to the iSCSI target. The XEN servers allow LIVE migration of the VM machines. The platform is CentOS 5.2.

XEN node setup

# yum install xen kernel-xen virt-manager virt-install

If you don't have it already installed, add X related packages to the system. If you plan to access virt-manager from Windows environment, install vnc-server.

# yum install xfs
# yum install xorg-x11*
# yum install xterm
# yum install vnc-server

# chkconfick xfs on
# service xfs start

# su - my_vnc_user
$ vncserver
$ exit
# echo "VNCSERVER="8:my_vnc_user" >> /etc/sysconfig/vncservers
# echo "VNCSERVERARGS[8]="-geometry 1024x768 -nolisten tcp -nohttpd" \
>> /etc/sysconfig/vncservers

# chkconfig vncserver on
# service vncserver start

Make the default boot kernel the xen-kernel.

# cat /etc/grub.conf
# grub.conf generated by anaconda
# Note that you do not have to rerun grub after making changes to this file
# NOTICE: You do not have a /boot partition. This means that
# all kernel and initrd paths are relative to /, eg.
# root (hd0,0)
# kernel /boot/vmlinuz-version ro root=/dev/cciss/c0d0p1
# initrd /boot/initrd-version.img
title CentOS (2.6.18-92.1.13.el5xen)
root (hd0,0)
kernel /boot/xen.gz-2.6.18-92.1.13.el5
module /boot/vmlinuz-2.6.18-92.1.13.el5xen ro root=LABEL=/1
module /boot/initrd-2.6.18-92.1.13.el5xen.img
title CentOS (2.6.18-92.1.13.el5)
root (hd0,0)
kernel /boot/vmlinuz-2.6.18-92.1.13.el5 ro root=LABEL=/1
initrd /boot/initrd-2.6.18-92.1.13.el5.img
title CentOS (2.6.18-92.el5)
root (hd0,0)
kernel /boot/vmlinuz-2.6.18-92.el5 ro root=LABEL=/1
initrd /boot/initrd-2.6.18-92.el5.img

Change the default kernel settings to xen-kernel.

# cat /etc/sysconfig/kernel
# UPDATEDEFAULT specifies if new-kernel-pkg should make
# new kernels the default

# DEFAULTKERNEL specifies the default kernel package type

Then run virt-manager remotely or virsh locally.

[x_win_client] # ssh -X xen_machine.some.org virt-manager

Single host VM example

XEN vm config file below uses full virtualisation (not the paravirtualisation), ethernet bridging and virtual disk on file. The vm system boots cdrom first (iso file).

If you would like to keep vm to boot from cdrom iso you have to specify disk = [ "file:/var/lib/xen/images/vm03.img,hda,w", "file:/var/images/rhel45-i386-boot.iso,hdc:cdrom,r" ] and the boot order as boot = "dc". The boot = "c" option makes the system boots from virtual harddrive only.

name = "vm03"
uuid = "8a25f77a-30bc-7fc4-670c-22fa34f1c471"
maxmem = 512
memory = 512
vcpus = 1
builder = "hvm"
kernel = "/usr/lib/xen/boot/hvmloader"
boot = "dc"
pae = 1
acpi = 1
apic = 1
localtime = 0
on_poweroff = "destroy"
on_reboot = "restart"
on_crash = "restart"
device_model = "/usr/lib64/xen/bin/qemu-dm"
sdl = 0
vnc = 1
vncunused = 1
keymap = "en-us"
disk = [ "file:/var/lib/xen/images/vm03.img,hda,w", "file:/var/images/rhel45-i386-boot.iso,hdc:cdrom,r" ]
vif = [ "mac=00:16:3e:6c:08:ff,bridge=xenbr0" ]
serial = "pty"

As we do have VM running, we can proceed to iSCSI configuration. The iSCSI provides diskspace to both the XEN server nodes simultaneously. This will allow us to migrate VM between the XEN servers.

Configure iSCSI target:

# yum install scsi-target-utils -y
# yum install lsscsi -y
# yum install iscsi-initiator-utils -y

Creating harddisk file for VM:

dd if=/dev/zero of=vm07.img bs=1024 count=16777216
dd if=/dev/zero of=vm08.img bs=1024 count=16777216

Disabling seLinux temporary, start all the daemons:

# setenforce 0
# service iscsid start
# chkconfig iscsid on
# service tgtd restart
# chkconfig tgtd on

Create targets:

tgtadm --lld iscsi --op new --mode target --tid 1 -T iqn.2008-redhat.com:iscsi1.vm07
tgtadm --lld iscsi --op new --mode target --tid 2 -T iqn.2008-redhat.com:iscsi1.vm08

Or delete them alike:

delete: tgtadm --lld iscsi --op delete --mode target --tid 1 -I ALL

Show what is configured:

tgtadm --lld iscsi --op show --mode target

Bind taget to file:

# tgtadm --lld iscsi --op new --mode logicalunit --tid 1 --lun 1 -b /iscsi/vm07.img
# tgtadm --lld iscsi --op new --mode logicalunit --tid 2 --lun 1 -b /iscsi/vm08.img

Or delete binding:

delete: tgtadm --lld iscsi --op delete --mode logicalunit --tid 2 --lun 1 -b /iscsi/vm08.img

Allow access to ALL:

tgtadm --lld iscsi --op bind --mode target --tid 1 -I ALL
tgtadm --lld iscsi --op bind --mode target --tid 2 -I ALL

Check again:

tgtadm --lld iscsi --op show --mode target

Put all the commands to the config file and command the system to execute it while system boot, it's not the standard (or check this):

edit /etc/tgt/targets.conf

On client (XEN nodes)

# yum install iscsi-initiator-utils
# service iscsid start
# chkconfig iscsid on

Discovery or log to the targets:

iscsiadm --mode discovery --type sendtargets --portal
iscsiadm -d 255 --mode discovery -t sendtargets -p -l

Scan for a new disk/s:

fdisk -l
mkfs ...

As you need to keep the path to the iscsi share static (even after migration from one node to another) you have to use the /sys/disk/by-id/iscsi-string-identifier path to identify the iscsi vm raw disks or write some rules in udev. The entries /dev/sd[xx] could change next boot time. The example is here.


The VM machine config. Check out the disk path, which points to /sys/disk/by-id/iscsi-string-identifier.

name = "vm08"
uuid = "d138c27b-6d1a-11fd-ea0a-ca8f884b5446"
maxmem = 512
memory = 512
vcpus = 1
builder = "hvm"
kernel = "/usr/lib/xen/boot/hvmloader"
boot = "c"
pae = 1
acpi = 1
apic = 1
localtime = 0
on_poweroff = "destroy"
on_reboot = "restart"
on_crash = "restart"
device_model = "/usr/lib64/xen/bin/qemu-dm"
sdl = 0
vnc = 1
vncunused = 1
keymap = "en-us"
disk = [ "phy:/dev/disk/by-id/scsi-16465616462656166313a310000000000000000000000 0000,hda,w", "file:/var/images/win-xp-64.iso,hdc:cdrom,r" ]
vif = [ "mac=00:16:3e:06:79:47,bridge=xenbr0" ]
serial = "pty"

For live migration you have to change several lines in default /etc/xen/xend-config.sxp. The block below showl only the live migration xen config changes. The config must be edited on all the nodes involved in live vm migration. The actual VM is configured on one of the VM servers only.

(xend-relocation-address '')
(xend-relocation-hosts-allow '^localhost$ ^localhost\\.localdomain$ ^xen1$ ^xen2$')

There is a 1Gbit cross cable between the xen1 and xen2 to speed-up live migration and keep some level of security while migrating the VM machine (RAM) between servers. iscsi1 xen1 xen2

The actual command you have been waiting for, the live VM migration between two hosts:

[xen1-server] # xm migrate -l vm08 xen2

Some links below:

RedHat cluster manual.

[ add comment ] ( 31 views )   |  [ 0 trackbacks ]   |  permalink
RedHat/CentOS: a quick introduction to SeLinux policy (a short howto) 

UNIX access control mechanism is build around file permissions. The
access permissions define which subject can iteract with the file and
how. Due to the simple design this concept provides only the very basic

# ls -l
total 84
-rw------- 1 root root 1085 Mar 6 23:42 anaconda-ks.cfg
-rw-r--r-- 1 root root 17150 Mar 6 23:42 install.log
-rw-r--r-- 1 root root 2566 Mar 6 23:42 install.log.syslog

The main purpose of SeLinux is to avoid users or services to go beyond
their pre-defined scope of actions. SeLinux defines another level of
access control mechanism and implements a new layer of independent
system policy.

SeLinux extension allows you to restrict access actions at MUCH HIGHER
GRANULARITY than the common UNIX permissons - it goes far beyond the
simple UNIX file access control.

System defaults, the policy basics

The POLICY definition is a set of rules which specify how "secure" the
system will be, better - which actions will be allowed in the system as
the policy rule defines only what is allowed. All the actions not
allowed within the policy rules are disabled. It is the same concept as
with building firewall - all traffic is disabled and only specific data
flows are allowed.

There are some RedHat pre-defined (bundled) policies and they can be in
various "states". To determine the current SeLinux setup:

# sestatus
SELinux status: enabled
SELinuxfs mount: /selinux
Current mode: enforcing
Mode from config file: enforcing
Policy version: 21
Policy from config file: targeted

I would use the configuration file to explain what the options "enabled
enforcing targeted" mean. Main SeLinux configuration file is
/etc/selinux/config. In this file we define which policy will be loaded
on system boot.

If you set this file wrong, make a typo, the system will not boot and
panic. If it happens you can edit the Grub commandline and add the
"selinux=0" statement. All the options in the config are ignored then.
Here is the config file itself:

# cat /etc/selinux/config
# This file controls the state of SELinux on the system.
# SELINUX= can take one of these three values:
# enforcing - SELinux security policy is enforced.
# permissive - SELinux prints warnings instead of enforcing.
# disabled - SELinux is fully disabled.
# SELINUXTYPE= type of policy in use. Possible values are:
# targeted - Only targeted network daemons are protected.
# strict - Full SELinux protection.

The SELINUXTYPE is an actual set of allow rules - simply, it is the name
of compiled policy which inherits allow rules. After the system boots
you can't change the SELINUXTYPE, but you are only allowed to modify how
the kernel will follow the policy instructions.

If the kernel is in enforcing mode, then the loaded policy is in use
without exceptions. If the SeLinux is in permissive mode, the kernel
will allow all the actions and will print warning AVC messages only
(good for debugging) instead of dropping the action. You can choose
which SELINUXTYPE policy you will load at system boot. To check policies
you have available on your system type:

# rpm -qa | grep selinux-policy

Or you can check the policies (compiled rule files) by simple listing
content of /etc/selinux directory.

# ls -la
total 56
drwxr-xr-x 4 root root 4096 Mar 27 03:00 .
drwxr-xr-x 77 root root 4096 Mar 27 02:59 ..
-rw-r--r-- 1 root root 512 Mar 27 02:58 config
-rw------- 1 root root 195 May 24 2008 restorecond.conf
-rw-r--r-- 1 root root 1752 Mar 14 2007 semanage.conf
drwxr-xr-x 5 root root 4096 Mar 27 02:58 targeted

As you can see I have only the targeted policy rules installed by now.
The targeted policy is focused on specific system components/services
and all the other content is allowed to run by default - as is labeled
with unconfirmed type. It means that if you do use this policy then the
majority of the software will run and you will still keep the SeLinux
protection for well-known services shipped with distro as samba, http,
postfix, ftp... If you plan to use services which are not bundled by
RedHat then you have to use targeted policy rules or write your own
modules for them.

I will install the strict policy as well. As the strict policy is really
hard-restrictive it is more alike the original NSA SeLinux concept. You
can have problems if your non-selinux-labeled application decides try to
bind some of the tcp sockets for example because unlabeled context is
considered unknow, dangerous and therefore can't interact with the
system. There is now allow rule for unlabeled content. Usually, the
system with strict policy is not able to boot at all (until RedHat 5).
As you need to allow your application to work on the system you have to
prepare special security module for the application.

# yum list | grep selinux-policy | grep -v devel
selinux-policy.noarch 2.4.6-137.el5
selinux-policy-targeted.noarch 2.4.6-137.el5
selinux-policy-mls.noarch 2.4.6-137.1.el5 updates
selinux-policy-strict.noarch 2.4.6-137.1.el5 updates

# yum install selinux-policy-strict

Some basic tweaking on predefined policy

RedHat shipped policies includes so called "booleans" or let's say
"constraints" defined. Using those booleans you can partially change the
SeLinux behavior without creating a whole new policy or policy module.
To list all the booleans related to the apache:

# getsebool -a | grep httpd
allow_httpd_anon_write --> off
allow_httpd_bugzilla_script_anon_write --> off
allow_httpd_mod_auth_pam --> off
allow_httpd_nagios_script_anon_write --> off
allow_httpd_squid_script_anon_write --> off
allow_httpd_sys_script_anon_write --> off
httpd_builtin_scripting --> on
httpd_can_network_connect --> off
httpd_can_network_connect_db --> off
httpd_can_network_relay --> off
httpd_disable_trans --> off
httpd_enable_cgi --> off
httpd_enable_ftp_server --> off
httpd_enable_homedirs --> on
httpd_rotatelogs_disable_trans --> off
httpd_ssi_exec --> off
httpd_suexec_disable_trans --> off
httpd_tty_comm --> on
httpd_unified --> on

The apache config could be configured to allow executing cgi for
example, but the current SeLinux policy is set the way it disallow such
interaction of the Apache daemon. To enable the interaction between the
daemon and the cgis I have to set the trigger:

# setsebool -P httpd_enable_cgi on

Some of the booleans mentioned above can control "SeLinux command
behavior" itself. By default it is possible for root to change how the
system will INTERPRET policy - you can switch from enforcing to
permissive mode forth and back as you wish on the fly using setenforce

# setenforce 0

Even in restricted or targetted policy the root is still the master over
the Linux system, the SeLinux idea is not to limit the root but to allow
the service security will be tuned specifically. Of course, you can
write your own policy which will deny the root to write to /etc
directory if you like.

But even in shipped policy you can limit root user actions a bit. For
example - you can disable the setenforce command.

# getsebool -a | grep secure_mode_policyload
secure_mode_policyload --> off

# setsebool -P secure_mode_policyload on

# sestatus
SELinux status: enabled
SELinuxfs mount: /selinux
Current mode: enforcing
Mode from config file: enforcing
Policy version: 21
Policy from config file: targeted

# setenforce 0
setenforce: setenforce() failed

What the policy module is

The policy module is a set of compiled rules which expands the main
policy configuration. The modular policy is used on the RedHat5.0(?) and
later. Each module is specific to application as you can see:

# semodule -l
amavis 1.1.0
ccs 1.0.0
clamav 1.1.0
dcc 1.1.0
evolution 1.1.0
iscsid 1.0.0
mozilla 1.1.0
mplayer 1.1.0
nagios 1.1.0
oddjob 1.0.1
pcscd 1.0.0
pyzor 1.1.0
razor 1.1.0
ricci 1.0.0
smartmon 1.1.0

Modules are permanently allowed or denied to load while system boot
using semodule -r (remove) and semodule -i (install) command. The
modular policy of RedHat5.2/CentOS5.2 and above also allows you to load
the necessary policy definitions module on the fly. It is good to know
that such behaviour could be enabled or disabled via boolean named
secure_mode_insmod (in || off).

Into the deep, the filesystem

And now some technical talk. Where to start to look for SeLinux. Lets
begin with the filesystem extended attribute information. We can call it
the LABEL and sits on the filesystem if the FS supports it (ext3 does).
The SeLinux labels are saved as metadata. Let's check them out.

# getfattr -n security.selinux /root/anaconda-ks.cfg
getfattr: Removing leading '/' from absolute path names
# file: root/anaconda-ks.cfg

Get the attributes with 'ls -Z':

# ls -Z
-rw------- root root system_u:object_r:user_home_t anaconda-ks.cfg
-rw-r--r-- root root root:object_r:user_home_t install.log
-rw-r--r-- root root root:object_r:user_home_t

You can see the selinux content on the processes as well with 'ps -efZ'.
The magic is the 'Z' option. On the example we can see
"root:object_r:user_home_t". This gibrish is called access control
vector . The vector is the most and only important data for the access
control mechanism.

The architecture

- The SeLinux consists of SeLinux supporting filesystem, the Access
Vector Cache and the Security Server.

- Each filesystem object has it's own vector.

- If some operation should be performed the SeLinux search the allow
rules if the vector of object is allowed to interact with the subject's
vector .

- If SeLinux finds at least one allow rule then the operation is

- The SeLinux is the last resort access control mechanism in the system.

The system has a AVC (the vector cache) to speed up searches. If there
is no record about the result within the cache then the Security Server
is queried.

A set of filters could be placed between the SS and AVC
(security_compute_av()). The filters (constraints) then could drop some
allow messages. It could be useful when changing system behaviour
without the policy compilation and loading.

The SeLinux rules could be more complicated. Instead of simple allow
rule to certain interactions between object and subject they can define
the interacting (originator) object can change it's own "vector
definition" into another "vector". This type of behaviour is called

SeLinux context

# ls -lZ /etc/selinux/semanage.conf
-rw-r--r-- root root system_u:object_r:selinux_config_t

system_u -> user, it could not be identical with /etc/passwd user
object_r -> role, like the group, but SeLinux type
selinux_config_t -> type, the domain, most important

Extended attributes as clasification and sensitivity could be specified,
but we don't need them yet.

Selinux users

Selinux uses it's own users but you don't need to map the passwd user to
SeLinux user if the username is the same.

Creating your own policy

1) compile the module

$ checkmodule -M -m -o local.mod local.te

2) create the package

$ semodule_package -o local.pp -m local.mod

3) load the module into the kernel

$ semodule -i local.pp

The following example was created using audit2allow which generates
policy allow rules from logs of denied operations.

cat /var/log/audit/audit.log | audit2allow -M mynagios

module mynagios 1.0;

require {
type security_t;
type usr_t;
type ping_t;
type httpd_sys_script_t;
type load_policy_t;
class security load_policy;
class file { read write };
class fifo_file getattr;

#============= httpd_sys_script_t ==============
allow httpd_sys_script_t usr_t:fifo_file getattr;

[ add comment ] ( 5 views )   |  [ 0 trackbacks ]   |  permalink
Solaris network card IP alias 
# ifconfig interface:1 plumb
# ifconfig interface:1 netmask
# cat /etc/hostname.interface:1
# cat /etc/hosts | grep alias alias

[ add comment ] ( 5 views )   |  [ 0 trackbacks ]   |  permalink

<<First <Back | 54 | 55 | 56 | 57 | 58 | 59 | 60 | 61 | 62 | 63 | Next> Last>>