Wednesday, September 14, 2011

SELinux: For A Secure Web Space


Linux is a premium force in the web hosting industry, which is also achieving popularity as a PC operating system nowadays. When it comes to hosting a website, Linux web servers are primarily chosen due to their flexibility, stability and security of services. But as we all know, security of all operating systems revolve around controlling access and is hence subject to exploits. Since Linux is open source, vulnerabilities can be easily exploited by potential attackers to gain illegal access to a web server. As a measure of securing Linux at every level, from the kernel up, Security Enhanced Linux (SELinux) was developed.
The development of SELinux or Security Enhanced Linux was initiated by the National Security Agency, the University of Utah, and the Secure Computing Corporation. The architecture was called Flask operating system, implemented with mach micro kernel.
With this article, l will explain the basics of SELinux. SELinux implements MAC [Mandatory Access Control] instead of the traditional DAC [Discretionary Access Control].

DAC and Limitations

Linux distributions normally incorporate the Discretionary Access Control (DAC) mechanism, that lets resource owners decide who can access a resource and how.
DAC implements security by denying access based on the identity of groups to which the user belongs. Using DAC, there are two user levels in the OS; Administrator and Non-administrator. The administrator is simply the root user or a user with root privileges. If a non-administrator user is to have administrative privileges, the user has to be added, either to a wheel user group or in sudoers. Most often, full privileges will have to be given to this user.
It was soon realized that DAC was not the best solution, as it gave applications the privileges of the user running them. One compromised application running as root could ultimately affect the entire web server. In a compromised web server, through a global writable file or directory, malicious codes or softwares could get administrative privileges using setuid.
All these reasons led security experts to develop Mandatory Access Control (MAC), which grants access to resources as defined by a security policy, regardless of the user running the application.

MAC [Mandatory access control]

This is also called non-DAC. In simple terms, MAC uses the principle of least privilege, where processes/objects or users have the minimal privileges that are required for their normal functioning. Administrators can define security policies for subjects/objects, to interact with other parts of the system.

LSM (Linux Security Modules)

This framework was developed to support a variety of computing security models in the Linux kernel. LSM was released under GNU-GPL and is now part of all the latest Linux kernels. LSM enables the implementation of MAC, with least amount of changes in the Linux kernel.
In a web server, SELinux is based on two technologies: Type Enforcement and RBAC [role-based access control ]. Type enforcement, which is described in a policy file, defines a type for each subject/process and object. Each file has security labels and these labels contain the type of policy. They are stored in xattrs [called extended attributes]. By default, all interactions between subjects and objects will be denied in SELinux.
Using the policies, a matrix can be derived that defines the interactions of each process used by the Type Enforcement.

How to Enable/Disable SELinux?

SELinux is available in all major distros by default. During the installation of Linux [RedHat/Fedora], you will be prompted to enable or disable SELinux along with the firewall option.
In Fedora/Redhat, SELinux can be enabled or disabled by editing the file“/etc/selinux/config “. There are 3 modes for the parameter SELINUX. They are:
SELINUX = disabled
SELINUX = permissive
SELINUX = enforcing
The values ‘disabled‘ and ‘permissive‘ are mainly used to disable SELinux in a server.
The value “disabled” will completely switch off SELinux. All operations will be allowed to work normally and the policies of security attributes will not have any effect on the services or files.
The value “permissive” will allow all operations, but logs those which can be denied using the policy. All warnings get logged, thereby allowing the audit of each process interaction for creating corresponding policy rules.
To disable SELinux in a live server temporarily, you may change the value of/selinux/enforce to zero.
echo 1 >/selinux/enforce : Enable
echo 0 >/selinux/enforce : Disable
cat /selinux/enforce : Check status
If the Linux distro used in a web hosting server does not have the file/etc/selinux/config, SELinux can be disabled or enabled by adding the line “enforcing=0” or “enforcing=1” to grub.conf under /boot of the web server.
Re-enabling SELinux in a server needs relabeling of all files in the server. The server needs to be booted in permissive mode and then the following command has to be run to relabel the files.
fixfiles relabel
This can be also achieved by creating a file named autorelabel [like autofsck]. It will be processed in the next reboot of the web server.
After getting the system fully labelled, the status needs to be changed to “enforcing”, to make SELinux fully functional.

SELinux Boot Process

Unlike the normal boot process, the following are the steps performed during the boot up of an SELinux enabled kernel.
  • The kernel will run as kernel_t and all applications will use it.
  • The /sbin/init process which is also running as kernel_t will load the policy file to the kernel.
  • After the init load, it will be re-executed and gets labelled as init_exec_t
  • When kernel_t executes init_exec_t applications, it will be switched toinit_t, which is a rule hard coded in the kernel. Now init will be running as init_t.
  • When init_t executes an application, say sysinit which is labelled asinitrc_exec_t, the transition to initrc_exec will be performed as per the rule.
  • This process will continue.
For all other processes, the kernel will check the policy file and grant or deny access, as per the rules written. The denied messages will be logged for reference.
To know more about policy files, refer the following links.
If a program is compromised, SeLinux does not permit further access to the system, rather, it restricts access to the infected system. SELinux also protects data from being shared incorrectly. SELinux can also be used with distros other than Redhat and Fedora - Debian [as of etch release], Ubuntu [from version 8.x], Yellow Dog Linux, Gentoo, Slackware are supported.
With SELinux in place, it is possible for web hosts to offer a better and highly secure web space. There are other security models too, used in Linux, instead of SELinux. Grsecurity, AppArmor, Rule Set Based Access Control [RSBAC], PaX are a few of them.

REFERENCES

By at
Labels:

Understanding EXT3 File System and Data Recovery using ext3grep


Most of the Linux servers are today loaded with the EXT3 File System. We have come across a lot of incidents where files have gone lost through a simple rm -rf command, either done accidentally or sometimes even intentionally by others. There has always been a misconception that such files cannot be retrieved in ext3. In fact, it is quite possible to retrieve the data.
On further investigation into this, I was able to locate a lot of tools that could help recovering the deleted data from an ext3 file system. Magicrescue, Ext3grep, Testdisk, Ddrescue, Photorec and ext3undel are some examples, to list a few.
I was in pursuit of a tool that is capable of recovering all file types and is exclusively designed for the ext3 file system. One among the best tools that I found and would like to take you through is ext3grep.

Why ext3grep

This tool provides a good set of command line features and a good idea regarding the ext3 file system. Before proceeding further, let’s look into the merits and demerits of this tool.
Merits:
  • Almost any file format can be recovered.
  • You can recover your files based on the date of deletion.
  • Even large files can be retrieved using this tool.
De-Merits:
  • The tool works only on an unmounted file system.
  • Frequent crashes of the machine can happen, as it recovers huge amount of data.
 

Points to be ensured before the Recovery Process

  • Make sure that it is not a primary partition because the software does not need the partition to be mounted during recovery.
  • Mount the partition in the read-only mode, so that the i-nodes will not get overwritten with the new data, as this can cause issues in recovering the files.
  • Ensure that you are installing ext3grep in another partition and also that there is enough space in this partition to recover the files.
 

Download and Install ext3grep in your File system

Download the source code from:http://ext3grep.googlecode.com/files/ext3grep-0.9.0.tar.gz or you can download them through svn access. Follow the steps below for the installation:
mkdir ext3grep
svn checkout http://ext3grep.googlecode.com/svn/trunk/ ext3grep
cd ext3grep
./configure -prefix=/opt/ext3grep      # Make sure that it does not get installed in
                                         the affected partition
make
make install

The Basics of the ext3 File system:

Let’s take a look at how the basic ext3 file system uses ext3grep. Ext3 is an ext2 file system with the journaling option. Journaling is nothing but keeping track of the transactions, so that in case of a crash, the files may be recovered from a previous state. All transaction information are passed to the journaling block device layer (JDB), which is independent of the ext3 file system.
The ext3 partition consists of a set of groups which are created during disk formatting. Each group consists of a super block, a group descriptor, a block bitmap, an i-node bitmap, an i-node table and data blocks. A simple layout can be specified as follows:
,---------+---------+---------+---------+---------+---------,
       | Super   | FS      | Block   | Inode   | Inode   | Data    |
       | block   | desc.   | bitmap  | bitmap  | table   | blocks  |
       `---------+---------+---------+---------+---------+---------'
You can get the total number of groups in the particular partition using the following command:
./ext3grep  /dev/hda2 --superblock | grep 'Number of groups'
Number of groups: 24
Each group consists of a set of fixed size blocks which could be of 4096, 2048 or 1024 bytes in size.
Some of the basic terminology associated with the ext3 file system are:
Superblock:
Superblock is a header that tells the kernel about the layout of the file system. It contains information about the block size, block-count and several such details. The first superblock is the one that is used when the file system is mounted.
To get information related to the blocks per group, use the command:
/opt/ext3grep/bin/ext3grep  /dev/hda2 --superblock | grep 'blocks per group'
Number of blocks per group: 32768
To get the block size details from the superblock, use the command:
/opt/ext3grep/bin/ext3grep /dev/hda5 --superblock|grep size
Block size: 4096
Fragment size: 4096
You can get a complete list of the superblock details using the command:
/opt/ext3grep/bin/ext3grep /dev/hda5 --superblock
Group Descriptor:
The next block is the group descriptor which stores information of each group. Within each group descriptor, is a pointer to the table of i-nodes and the allocation bitmaps for the i-nodes and data blocks.
Allocation Bitmap:
An allocation bitmap is a list of bits describing the block and the i-nodes which are used so that the allocation of files can be done efficiently.
I-nodes:
Each file is associated with one i-node. It contains various information about the files. The data of the files are not stored in the i-node as such, but it points to the location of the data on the disk (data structure to file).
I-nodes are stored in the i-node tables. The command: df -i will give you the total number of i-nodes in the partition and the command ls -i filename will give you the i-node number of the respective file.
df -i | grep /dev/hda5
Filesystem  Inodes          IUsed   IFree           IUse% Mounted on
/dev/hda5    18233952   33671   18200281    1%      /
-------------------------------------------------
ll -i ext3grep
inode no   permission owner  group     size in bytes     date         filename
6350788 -rwxr-xr-x 1 root      root       2765388       Oct  5  23:49 ext3grep
Directories:
In the ext3 file system, each directory is a file. This directory uses an i-node and this i-node contains all the information about the contents of the directory. Each file has a list of directory entries and each entry associates one file name with one i-node number. You can get the directory i-node information using the command:
ll -id bin
6350787 drwxr-xr-x 2 root root 4096 Oct  5 23:49 bin
Superblock Recovery:
Sometimes the superblock gets corrupted and all the data information of that particular group is lost. In this case we can recover the superblock using the alternate superblock backup.
 First, list the backup superblock
dumpe2fs -h /dev/hda5
Primary superblock at 0, Group descriptors at 1-5
 Backup superblock at 32768, Group descriptors at 32769-32773
 Backup superblock at 98304, Group descriptors at 98305-98309
 Backup superblock at 163840, Group descriptors at 163841-163845
 Backup superblock at 229376, Group descriptors at 229377-229381
 Backup superblock at 294912, Group descriptors at 294913-294917
 Next, find the position of backup superblock.
Usually the block size of ext3 will be 4096 bytes, unless defined manually during file system creation.
position= backup superblock *4
32768*4=131072
Now, mount the file system using an alternate superblock.
mount  -o sb=131072 /dev/hda5 /main
 
The ext3grep is a simple tool that can aid anyone who would have accidentally deleted a file on an ext3 file system, only to later realize that they required it.
 

Some important commands for the partition

Find the number of group to which a particular i-node belongs.
The number of i-nodes per group can be found using ext3grep described below:
group = (inode_number - 1) / inodes_per_group
To find the block to which the i-node belongs, use the command:
/opt/ext3grep/bin/ext3grep  /dev/hda2  --inode-to-block 272
Inode 272 resides in block 191 at offset 0x780.
To find the journal i-node of the drive:
/opt/ext3grep/bin/ext3grep  /dev/hda2  --superblock  | grep 'Inode number of
journal file'
Inode number of journal file: 8

The Recovery Process

In the recovery process the first thing to do is to list the files of the particular disk. You can use the command:
/opt/ext3grep/bin/ext3grep  /dev/hda2  --dump-names
Before working on the recovery process make sure that you have unmounted the partition.
To Recover all files:
The following command will recover all the files to a new directory RESTORED_FILES which is in the current working directory. The current working directory should be a new drive.
/opt/ext3grep/bin/ext3grep  /dev/hda2  --restore-all
After this, you will have a copy of all the files in the directory RESTORED_FILES .
To Recover a Single File:
If you want to recover a single file, then find the i-node corresponding to the directory that contains that file. For example, if I accidentally lost a file named backup.sql which was in /home2. First I need to find its i-node:
ll -id /home2/
2 drwxr-xr-x  5 root root 4096 Aug 27 09:21 /home2/
Here the first entry ‘2′ is the i-node of /home2. Now I can use ext3grep to list the contents of /home2.
/opt/ext3grep/bin/ext3grep  /dev/hda2  --ls --inode 2
The first block of the directory is 683. Inode 2 is directory “”.
Directory block 683:
          .-- File type in dir_entry (r=regular file, d=directory, l=symlink)
          |          .-- D: Deleted ; R: Reallocated
Index Next |  I-node   | Deletion time                        Mode        File name
==========+==========+----------------data-from-inode------+-----------+=========
   0    1 d       2                                         drwxr-xr-x  .
   1    2 d       2                                         drwxr-xr-x  ..
   2    3 d      11                                         drwx------  lost+found
   3    4 d  144001                                         drwxr-xr-x  testfol
   4    6 r      13                                         rrw-r--r--  aba.txt
   5    6 d  112001  D 1219344156 Thu Aug 21 14:42:36 2008  drwxr-xr-x  db
   6  end d  176001                                         drwxr-xr-x  log
   7  end r      12  D 1219843315 Wed Aug 27 09:21:55 2008  rrw-r--r--  backup.sql
Here, we see that the file backup.sql is already deleted. I can recover it using ext3grep through two methods.
 Recovery using the file name:
You can recover the file by providing the path of the file to the ext3grep tool. In my case /home2 was added as a separate partition. So I should give the path of the file as simply backup.sql, since it is in root directory of that partition.
umount /home2
/opt/ext3grep/bin/ext3grep  /dev/hda2  --restore-file backup.sql
Loading journal descriptors... sorting... done
The oldest inode block that is still in the journal, appears to be from
1217936328 = Tue Aug  5 07:38:48 2008
Number of descriptors in journal: 1315; min / max sequence numbers: 203 / 680
Loading hda2.ext3grep.stage2... done
Restoring backup.sql
Ensure that the file has been recovered to the folder “RESTORED_FILES”
ll -d RESTORED_FILES/backup.sql
-rw-r--r--  1 root root 49152 Dec 26  2006 RESTORED_FILES/backup.sql
 Recovering using the i-node information.:
You can recover the file also by using the i-node information of the file. The i-node number can be obtained using the command:
/opt/ext3grep/bin/ext3grep  /dev/hda2  --ls --inode 2
------------------------------------
           7  end r      12  D 1219843315 Wed Aug 27 09:21:55 2008  rrw-r--r--  backup.sql
Here the i-node number is 12 and you can restore the file by issuing the following command:
/opt/ext3grep/bin/ext3grep  /dev/hda2  --restore-inode 12
Loading journal descriptors... sorting... done
The oldest i-node block that is still in the journal, appears to be from
1217936328 = Tue Aug  5 07:38:48 2008
Number of descriptors in journal: 1315; min / max sequence numbers: 203 / 680
Restoring inode.12

 mv RESTORED_FILES/inode.12 backup.sql

 ll -h backup.sql
-rw-r--r--  1 root root 48K Dec 26  2006 backup.sql
To Recover files based on time:
Sometimes there can be a conflict where the ext3grep tool detects a lot of old files that were removed, but have the same name. In this case you have to use the “–after” option. In addition, you will also have to provide a Unix time stamp to recover the file. The Unix time stamp can be obtained from the following link: http://www.onlineconversion.com/unix_time.htm.
For example, if I would like to recover all the files that were deleted after Wed Aug 27 05:20:00 2008, the command used should be as follows:
/opt/ext3grep/bin/ext3grep  /dev/hda2  --restore-all --after=1219828800
Only show/process deleted entries if they are deleted on or after Wed Aug 27 05:20:00 2008.
Number of groups: 23
Minimum / maximum journal block: 689 / 17091
Loading journal descriptors... sorting... done
The oldest inode block that is still in the journal, appears to be from
1217936328 = Tue Aug  5 07:38:48 2008
Number of descriptors in journal: 1315; min / max sequence numbers: 203 / 680
Writing output to directory RESTORED_FILES/
Loading hda2.ext3grep.stage2... done
Restoring aba.txt
Restoring backup.sql
You can also use the ‘–before’ option to get a file before that date.
/opt/ext3grep/bin/ext3grep  /dev/hda2  --restore-all --before=1219828800
You can recover files between a set of dates combining both the above options. For example, in order to recover a file between 12/12/2007 and 12/9/2008, I need to use a command as follows:
/opt/ext3grep/bin/ext3grep  /dev/hda2  --restore-all  --after=1197417600 --before=1228780800
To List the Correct hard links
A recovery of the files can cause a lot of hard link related issues. To find out the hard linked files, you can use the command:
/opt/ext3grep/bin/ext3grep  /dev/hda2 --show-hardlinks
After this, remove the unwanted hard linked files which are duplicates.
To List the Deleted files.
You can use the following command to list the deleted files.
/opt/ext3grep/bin/ext3grep  /dev/hda2 --deleted

Conclusion

The ext3grep is a simple tool that can aid anyone who would have accidentally deleted a file on an ext3 file system, only to later realize that they required it. Even though this tool does not provide you with a complete set of features, it can be used to get a good outline of your hard disk and to find out a way for the recovery of lost data.

Reference

By at
Labels: ,

The Kernel Debugging Tools for Linux


Your Kernel just crashed or one of your drive is not working!! What do you do?
Well, this article gives an introduction to some kernel debugging tools for Linux. These tools makes the kernel internals more transparent. These tools help you to trace the kernel execution process and examine its memory and data structures.
The tools discussed here are :
1. Kernel debugger, kdb
2. Kernel GNU debugger, kgdb
3. GNU debugger, gdb
4. JTAG- based debuggers.
Of the mentioned tools, the kdb and kgdb were introduced as patches to the kernel code. The plain debugger gdb doesn’t need the patching process with kernel code. The JTAG (Joint Test Action Group) based debuggers are hardware assisted and powerful tools, but are expensive.
Here I will explain the installation and usage of the kdb tool. The rest of the tools are briefed.
Kernel debugger, kdb
Kdb is a project maintained by the Silicon Graphics. The main advantage of kdb is that you can debug the kernel that you are running on.
To install the kernel debugger:
1. Download and unzip the patches and apply them to your linux source tree.
Of the 2 patches, the ‘common’ patch contains the changes for the generic kernel code, and the other is the
2. You can get the required patches from
You should choose the patches depending upon the kernel you are compiling. I compiled the latest 2.6.26 kernel. So I chose the following patches :
kdb-v4.4-2.6.26-rc9-common-1
kdb-v4.4-2.6.26-rc9-x86-1
3. Patch them to your kernel tree.
# cd /usr/src/kernels/linux – Path to your untarred linux kernel source
# patch -p1 < kdb-v4.4-2.6.9-rc4-common-1
# patch -p1 < kdb-v4.4-2.6.9-rc4-i386-1
If your patches are not successful you will get files with extensions .rej in the directory.
3. If successful, recompile the new kernel with the patches enabled usingxconfig/menuconfig.
While compiling make sure the CONFIG_KDB option is enabled. You can also enable CONFIG_FRAME_POINTER for better debugging. But this uses an extra register and slightly slower kernel code. These options comes under ‘Kernel Hacking’ section.
The KDB commands to be executed during the initialization process can be defined in a plain text file called kdb_cmds, which exists in the kdb directory of the linux source tree. This file can also be used to define environment variables for setting the display and print options.
For me file was in this path : /usr/src/kernels/linux/kdb
The flags passed to kdb are of three
These flags can be passed at boot time to ensure that the KDB is On/Off. The Early flag helps to troubleshoot the problems during boot time.

KDB commands

KDB allows memory and register modification, applying breakpoints, and stack tracing.
Memory display and modification
Commonly used commands are : md, mdr, mm, and mmW.
1. The md command takes an address/symbol and a line count and displays memory starting at the address for line-count number of lines.
2. The mdr command takes an address/symbol and a byte count and displays the raw contents of memory starting at the specified address for byte-count number of bytes.
3. The mm command modifies memory contents.
4. The mmW command changes W bytes starting at the address.
Register display and modification
Commonly used commands are : rd, rm, and ef.
1. The rd command (without any arguments) displays the contents of the processor registers.
2. The rm command modifies the contents of a register.
3. The ef command takes an address as an argument and displays an exception frame at the specified address.
Stack tracing
The main stack tracing commands are bt, btp, btc, and bta.
1. The bt command attempts to provide information on the stack for the current thread.
2. The btp command takes a process ID as an argument and does a stack traceback for that particular
3. The btc command does a stack traceback for the running process on each live CPU.
4. The bta command does a traceback for all processes in a particular state. Without any argument, it does a traceback for all processes. Optionally, various arguments can be passed to this command. The processes in a particular state will be processed depending on the argument. The options and the corresponding states are as follows:
* D: Uninterruptible state
* R: Running
* S: Interruptible sleep
* T: Traced or stopped
* Z: Zombie
* U: Unrunnable
Breakpoints
The commonly used breakpoint commands are bp, bc, bd, be, and bl.
1. The bp command takes an address/symbol as an argument and applies a breakpoint at the address. It is similar to the bpa command except that it forces the use of a hardware register.
2. The bd command disables a particular breakpoint.
3. The be command enables a breakpoint. The argument to this command is also the breakpoint number.
4. The bl command lists the current set of breakpoints. It includes both the enabled and the disabled breakpoints.
5. The bc command removes a breakpoint from the breakpoint table. It takes either a specific breakpoint number as an argument or it takes *, in which case it will remove all breakpoints.
Kernel GNU debugger, kgdb
The kgdb developed initially as a patch is now included in the official 2.6.26 kernel. This source level debugging tool is much easier to use. It requires two machines to be connected via a serial connection (a RS-232 interface using null modem/a UDP/IP networking protocol).
The gdb is used along with kgdb to trace through kernel code. The gdb runs on the host machine and the kgdb patched kernel runs on the target machine.
GNU debugger, gdb
This is also a powerful stand alone tool used for debugging. But with this tool you can’t set the breakpoint or trace the kernel code. Instead you can use gdb to debug the core files which are dumped when an error occurs.
It leads us with clues on how to troubleshoot the problem.
JTAG- based debuggers
JTAG debuggers use hardware assistance to debug code. This needs a monitor and a front end API to debug the code. It can be used to debug the BIOS, the bootloader, real mode Linux kernel initialization code, and the protected mode kernel.
You can start the debugging mode via command line parameters that you pass to the kernel while booting up or using hardware or software break points. A break point is referred to as the point where the debugger takes in charge when the control is transferred at a point of execution.
If the instruction stops on flash memory and if the corresponding instruction cannot be replaced by the debugger you can use hardware breakpoint. A hardware breakpoint needs processor support. A software breakpoint can be set either using debugger commands or by inserting them into your code. Besides debugging, the second purpose of the JTAG interface is allowing device programmer hardware to transfer data into internal non-volatile device memory.
Conclusion:
After reading through you might be thinking, which one is the best debugger?
The commonly used ones are kdb and kgdb. These tools are aimed at different working environments. The decision depends upon mainly the design.
The kdb home page says like, “This debugger is part of the Linux kernel and provides a means of examining kernel memory and data structures while the system is operational. Additional commands may be easily added to format and display essential system data structures given an identifier or address of the data structure.”
The kgdb home page says like, “The kgdb is a source level debugger for Linux kernel. It is used along with gdb to debug Linux kernel.”
So try the tool you find suitable for your environment, then read more and hack your kernel… ;)
References:
By at
Labels:

Using 2-step verification Explained Clearly

By at
Labels: ,
Subscribe to: Posts (Atom)