1. INTERNATIONALComputer Volume OF COMPUTER ENGINEERING –
International Journal of
JOURNAL 3, Issueand Technology (IJCET), ISSN 0976
6367(Print), ISSN 0976 – 6375(Online)
Engineering
3, October-December (2012), © IAEME
& TECHNOLOGY (IJCET)
ISSN 0976 – 6367(Print)
ISSN 0976 – 6375(Online)
Volume 3, Issue 3, October - December (2012), pp. 369-376
IJCET
© IAEME: www.iaeme.com/ijcet.asp
Journal Impact Factor (2012): 3.9580 (Calculated by GISI) ©IAEME
www.jifactor.com
PROCESS BEHAVIOUR MODELLING USING LSM
S. Ravi Sankar1, Y. Swapna2
1
(Faculty, CSE Department, National Institute of Technology, Goa, India, srs@nitgoa.ac.in)
2
(Faculty, CSE Department, National Institute of Technology, Goa, India, spr@nitgoa.ac.in)
ABSTRACT
Computer security is a chronic and growing problem, even for Linux, as evidenced by the
seemingly endless stream of software security vulnerabilities. Security research has produced
numerous access control mechanisms that help improve system security; however, there is little
consensus on the best solution. Because of this lack of consensus, there are many patches to the
Linux kernel that provide enhanced access controls but none of them are a standard part of the
Linux kernel. The Linux Security Modules (LSM) seeks to solve this by providing a general
purpose framework for security policy modules. This allows many different access control
models to be implemented as loadable kernel modules. Just before the kernel would access the
internal object, an LSM hook makes an out-call to the module posing the question “Is this access
ok with you?” The module processes this policy question and returns either “yes” or “no.” In this
paper we are modeling process behaviour using LSM, a brief overview of existing security
modules. The behaviour of process is checked with LSM Hooks and functions, right before
kernel tries to access/take up the task. If it matches the expected operation, then it returns success
and task will be continued. If an error value is returned, the task will not start.
Keywords: Security, LSM, SELinux, LSM Hook
1. INTRODUCTION
Security is a chronic and growing problem, as more systems (and more money) go on
line, the motivation to attack rises. Linux is not immune to this threat, Linux systems do
experience a large number of software vulnerabilities. At the 2001 Linux Kernel Summit, NSA
developers presented their work on Security-Enhanced Linux (SELinux) [3] and emphasized the
need for enhanced security support in the main Linux kernel. In the ensuing discussion, a
consensus was reached that a general access-control framework for the Linux kernel was needed.
This approach would allow different security models to work without modifying the main kernel
code.
369

2. International Journal of Computer Engineering and Technology (IJCET), ISSN 0976 –
6367(Print), ISSN 0976 – 6375(Online) Volume 3, Issue 3, October-December (2012), © IAEME
Out of this discussion grew the Linux Security Module (LSM) Project [6, 4, 7]. A number
of developers worked together to create a framework of kernel hooks that would allow many
security models to work as loadable kernel modules. This allows many different access control
models to be implemented as loadable kernel modules, enabling multiple threads of security
policy engine development to proceed independently of the main Linux kernel. A number of
existing enhanced access control implementations, including POSIX.1e capabilities [5], SELinux
[3], Domain and Type Enforcement (DTE)[1] and Linux Intrusion Detection System (LIDS)[9]
have already been adapted to use the LSM framework. During the 2002 Linux Kernel Summit,
the technical description of the project was presented, and the first portion of the LSM
framework appeared in the 2.5.29 kernel release. Further kernel releases contained more portions
of the LSM framework.
2. RELATED WORK
This section provides an overview of the Linux Security Modules (LSM) framework. The
LSM framework adds security fields to kernel data structures and inserts calls to hook functions
at critical points in the kernel code to manage the security fields and to perform access control. It
also adds functions for registering and unregistering security modules. Extended attribute
handlers for a new security namespace were added to file systems to support new file security
attributes, and a /proc/pid/attr subdirectory was introduced to provide user space access to new
process security attributes.
The LSM security fields are simply void* pointers. For process and program execution
security information, security fields were added to struct task_struct and struct linux_binprm. For
file system security information, a security field was added to struct super_block [2]. Each LSM
hook is a function pointer in a global table, security_ops. This table is a security_operations
structure as defined by include/linux/security.h. Detailed documentation for each hook is
included in this header file. The hooks are grouped into logical sets based on the kernel object
(e.g. task, inode, file, sock, etc) as well as some miscellaneous hooks for system operations[4]. A
register_security function (in security/security.c) is provided to allow a security module to set
security_ops to refer to its own hook functions, and an unregister_security function is provided
to revert security_ops to the dummy module hooks[2]. Most of its functionality can now be
implemented using the extended attribute support and /proc/pid/attrinterface, as mentioned
above.
2.1. LSM Architecture
This section provides an overview of the SELinux security module internal architecture
as shown in the fig.1. The module code is located within the security/SELinux subdirectory of
the kernel tree. The security server provides general interfaces for obtaining security policy
decisions, enabling the rest of the module to remain independent of the specific security policies
used. These interfaces are defined in the include/security.h header file under the SELinux
module directory.
370

3. International Journal of Computer Engineering and Technology (IJCET), ISSN 0976 –
6367(Print), ISSN 0976 – 6375(Online) Volume 3, Issue 3, October-December (2012), © IAEME
Fig.1: LSM Architecture
Having discussed the high-level design philosophies of LSM we now turn to the
implementation of the LSM interface. At the core, the LSM interface is a large table of functions,
which by default are populated with calls that implement the traditional super user Discretionary
Access Control (DAC) policy. The module writer is then responsible for providing
implementations of the functions that they care about. In [8], the different types of hooks which
LSM provides have been explained.
3. METHODOLOGY
One of the most interesting applications of LSM appears when process permissions are
based on the process behaviour profile. In this paper we are modelling the behaviour of a process
using LSM. For this, in order to implement the LSM module and use the security structure, we
have to disable the NSA security flag after the kernel is compiled and configuring the modules.
By this we can implement our own security Module with the help of the structure Linux security
plug-in located in /usr /src /linux-2.6...... /include /linux /security.h.
At first we insert a module to the kernel which checks the file permissions and the
behaviour of the user application or process with a demon which holds the execution behaviour
of that particular process. The module consists of the struct security_operations structure which
checks the file permissions and socket operation of our particular application.
File permission function detects our present running application and traces the behaviour
like open, read etc. System calls which will be checked with the demon continually and the status
is returned to the module for every system call. If the call is matched demon will return yes to
continue the process and keeps on checking remaining calls. Suppose the call is not matched
with the one in demon it returns NO to the module and informs there is some deviation or
abnormal behaviour of process, immediately the module will terminate the process from
executing. In order to show the process behaviour we used the open system calls and a socket to
model it. Here we treat socket call as abnormal behaviour, as in most cases malfunctioning
processes try to communicate, and terminate the process whenever this call is made. Remaining
for the open calls the process should run normally and module allows it execute.
371

4. International Journal of Computer Engineering and Technology (IJCET), ISSN 0976 –
6367(Print), ISSN 0976 – 6375(Online) Volume 3, Issue 3, October-December (2012), © IAEME
The user application or the process which we are modelling first opens a file, create a
socket, then close the file and socket. The demon consists of a while loop which continually
checks the calls which are sent by module and returns the status accordingly. This function is
called whenever the kernel wants to determine if a specific file can be accessed at this moment in
time. A security module can look at the file, check whether the current user has proper authority
and possibly refuse to grant it.
int f_socket(int family, int type, int protocol, int kern)
{
if( strcmp(current->comm,"app")==0 )
{
printk(KERN_ALERT"in socket create function after strcmpn");
strcpy(kbuf,"socket");
up(&semr);
down_interruptible(&semw);
if(status=='n')
{
printk("process behaviour is suspicious , will be abortedn");
return -1;
}
}
return 0;
}
Fig.2: Flow chart of Process Behaviour Modelling
372

5. International Journal of Computer Engineering and Technology (IJCET), ISSN 0976 –
6367(Print), ISSN 0976 – 6375(Online) Volume 3, Issue 3, October-December (2012), © IAEME
4. IMPLEMENTATION
An implementation of flexible access control architecture in the Linux kernel has been
developed. It is useful and effective for developing Linux security enhancements.
int reg,ureg;
int f_per (struct file *file,int mask);
int f_ioctl (struct file * file, unsigned int cmd,unsigned long arg);
//extern int register_security (struct security_operations *ops);
//extern int unregister_security (struct security_operations *ops);
//int char_ioctl(struct inode *, struct file *, unsigned int, unsigned long);
//int (*file_ioctl) (struct file * file, unsigned int cmd,unsigned long arg):
struct security_operations secop= {
.file_permission = f_per,
.file_ioctl = f_ioctl,
};
int init_module(void)
{
printk(KERN_ALERT"in init functionn");
reg = register_security(&secop);
if(reg!=0)
{
printk(KERN_ALERT"register security failedn");
return -1;
}
return 0;
}
void cleanup_module(void)
{
printk(KERN_ALERT"in exit functionn");
ureg=unregister_security(&secop);
if(ureg!=0)
{
printk(KERN_ALERT"unregister security failedn");
}
}
int f_per (struct file *file,int mask)
{
if( strcmp(current->comm,"app")==0 )
{
printk(KERN_ALERT"in file permission function after strcmpn");
printk(KERN_ALERT"path =%sn",file->f_dentry->d_iname);
}
return 0;
}
int f_ioctl(struct file * file, unsigned int cmd,unsigned long arg)
373

6. International Journal of Computer Engineering and Technology (IJCET), ISSN 0976 –
6367(Print), ISSN 0976 – 6375(Online) Volume 3, Issue 3, October-December (2012), © IAEME
{
int number=10,ret;
if( strcmp(current->comm,"app")==0 )
{
switch(cmd)
{
case readioctl:
ret=copy_to_user((int *)arg,&number,sizeof(number));
if(ret!=0)
{
printk("no of bytes not copied is %dn",ret);
}
printk("the number sent to demon is %d n",number);
break;
default:
printk("invalid choice n");
}
}
return 0;
}
5. RESULTS
Experiments were conducted to test and evaluate the effectiveness of the proposed
approach to provide security. This section presents and details the experiments undertaken and
the results achieved.
Fig. 3: Inserting LSM Module
Fig.4: Running Daemon Process
374

7. International Journal of Computer Engineering and Technology (IJCET), ISSN 0976 –
6367(Print), ISSN 0976 – 6375(Online) Volume 3, Issue 3, October-December (2012), © IAEME
Fig.5: Running Application
Fig.6: Status Info from Daemon to LSM Module
Fig. 7: Intercepting System calls to monitor process behavior
In the above fig.3, using insmod command LSM module has been added to the kernel.
Before adding LSM module, we have to disable the NSA security flag after the kernel is
compiled and configuring the modules. By this we can implement our own security Module with
the help of the structure Linux security plug-in located in /usr /src /linux-2.6...... /include /linux
/security.h.
375

8. International Journal of Computer Engineering and Technology (IJCET), ISSN 0976 –
6367(Print), ISSN 0976 – 6375(Online) Volume 3, Issue 3, October-December (2012), © IAEME
Now the inserted module to the kernel checks the file permissions and the behaviour of
the user application (fig.5) with a demon process (fig.4) which holds the execution behaviour of
that particular process. File permission function detects our present running application and
traces the behaviour like open, read etc. System calls which will be checked with the demon
continually and the status is returned to the module for every system call as shown in the fig. 6
and 7.If the process is suspicious then terminate it from running state or else continue the process
execution.
6. CONCLUSION
There are probably other methods of taking an existing running program and spawning a
root process that this module does not catch. The proposed approach would be useful for
researchers in this area. Anybody who depends on a Linux security module (such as SELinux) is
depending on comprehensive checking within the kernel. Some work in this area could do a lot
to increase the level of trust which can be placed in LSM-based modules. The implemented LSM
meets these criteria. The patch is relatively small, and the performance data in shows that the
LSM patch imposes nearly zero overhead. The broad suite of security products from around the
world that have been implemented for LSM shows that the LSM API is useful and effective for
developing Linux security enhancements.
REFERENCES
[1] Serge Hallyn and Phil Kearns. Domain and Type Enforcement for Linux. In Proceedings of
the 4th Annual Linux Showcase and Conference, October 2000.
[2] Stephen Smalley, Wayne Salamon, and Chris Vance. Implementing SELinux as a Linux
Security Module. http://www.nsa.gov, December 2001.
[3] Peter Loscocco and Stephen Smalley. Integrating Flexible Support for Security Policies into
the Linux Operating System. In Proceedings of the FREENIX Track: 2001 USENIX Annual
Technical Conference (FREENIX ’01), June 2001.
[4] Stephen Smalley, Timothy Fraser, and Chris Vance. Linux Security Modules: General
Security Hooks for Linux. http://lsm.immunix.org/, September 2001.
[5] Winfried Trumper. Summary about POSIX.1e. http://wt.xpilot.org/publications/posix.1e, July
1999.
[6] WireX Communications. Linux Security Module. http://lsm.immunix.org/, April 2001.
[7] Chris Wright, Crispin Cowan, Stephen Smalley, James Morris, and Greg Kroah-Hartman.
Linux Security Modules: General Security Support for the Linux Kernel. In USENIX Security
Symposium, San Francisco, CA, August 2002.
[8] Chris Wright and Crispin Cowan, Stephen Smalley, James Morris and Greg Kroah-Hartman,
Linux Security Module Framework DARPA 2002 .
[9] Linux Intrusion Detection System. World-wide web page available at http://www.lids.org.
376