Process behaviour modelling using lsm
Upcoming SlideShare
Loading in...5
×
 

Process behaviour modelling using lsm

on

  • 541 views

 

Statistics

Views

Total Views
541
Views on SlideShare
541
Embed Views
0

Actions

Likes
0
Downloads
3
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    Process behaviour modelling using lsm Process behaviour modelling using lsm Document Transcript

    • 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.aspJournal Impact Factor (2012): 3.9580 (Calculated by GISI) ©IAEMEwww.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
    • 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 numberof developers worked together to create a framework of kernel hooks that would allow manysecurity models to work as loadable kernel modules. This allows many different access controlmodels to be implemented as loadable kernel modules, enabling multiple threads of securitypolicy engine development to proceed independently of the main Linux kernel. A number ofexisting 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 LSMframework appeared in the 2.5.29 kernel release. Further kernel releases contained more portionsof the LSM framework.2. RELATED WORK This section provides an overview of the Linux Security Modules (LSM) framework. TheLSM framework adds security fields to kernel data structures and inserts calls to hook functionsat critical points in the kernel code to manage the security fields and to perform access control. Italso adds functions for registering and unregistering security modules. Extended attributehandlers for a new security namespace were added to file systems to support new file securityattributes, and a /proc/pid/attr subdirectory was introduced to provide user space access to newprocess security attributes. The LSM security fields are simply void* pointers. For process and program executionsecurity information, security fields were added to struct task_struct and struct linux_binprm. Forfile system security information, a security field was added to struct super_block [2]. Each LSMhook is a function pointer in a global table, security_ops. This table is a security_operationsstructure as defined by include/linux/security.h. Detailed documentation for each hook isincluded 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]. Aregister_security function (in security/security.c) is provided to allow a security module to setsecurity_ops to refer to its own hook functions, and an unregister_security function is providedto revert security_ops to the dummy module hooks[2]. Most of its functionality can now beimplemented using the extended attribute support and /proc/pid/attrinterface, as mentionedabove.2.1. LSM Architecture This section provides an overview of the SELinux security module internal architectureas shown in the fig.1. The module code is located within the security/SELinux subdirectory ofthe kernel tree. The security server provides general interfaces for obtaining security policydecisions, enabling the rest of the module to remain independent of the specific security policiesused. These interfaces are defined in the include/security.h header file under the SELinuxmodule directory. 370
    • 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 theimplementation 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 DiscretionaryAccess Control (DAC) policy. The module writer is then responsible for providingimplementations of the functions that they care about. In [8], the different types of hooks whichLSM provides have been explained.3. METHODOLOGY One of the most interesting applications of LSM appears when process permissions arebased on the process behaviour profile. In this paper we are modelling the behaviour of a processusing LSM. For this, in order to implement the LSM module and use the security structure, wehave 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 securityplug-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 thebehaviour of the user application or process with a demon which holds the execution behaviourof that particular process. The module consists of the struct security_operations structure whichchecks the file permissions and socket operation of our particular application. File permission function detects our present running application and traces the behaviourlike open, read etc. System calls which will be checked with the demon continually and the statusis returned to the module for every system call. If the call is matched demon will return yes tocontinue the process and keeps on checking remaining calls. Suppose the call is not matchedwith the one in demon it returns NO to the module and informs there is some deviation orabnormal behaviour of process, immediately the module will terminate the process fromexecuting. In order to show the process behaviour we used the open system calls and a socket tomodel it. Here we treat socket call as abnormal behaviour, as in most cases malfunctioningprocesses try to communicate, and terminate the process whenever this call is made. Remainingfor the open calls the process should run normally and module allows it execute. 371
    • 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 asocket, then close the file and socket. The demon consists of a while loop which continuallychecks the calls which are sent by module and returns the status accordingly. This function iscalled whenever the kernel wants to determine if a specific file can be accessed at this moment intime. A security module can look at the file, check whether the current user has proper authorityand 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
    • International Journal of Computer Engineering and Technology (IJCET), ISSN 0976 –6367(Print), ISSN 0976 – 6375(Online) Volume 3, Issue 3, October-December (2012), © IAEME4. IMPLEMENTATION An implementation of flexible access control architecture in the Linux kernel has beendeveloped. 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
    • 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 proposedapproach to provide security. This section presents and details the experiments undertaken andthe results achieved. Fig. 3: Inserting LSM Module Fig.4: Running Daemon Process 374
    • 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 iscompiled and configuring the modules. By this we can implement our own security Module withthe help of the structure Linux security plug-in located in /usr /src /linux-2.6...... /include /linux/security.h. 375
    • 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 ofthe user application (fig.5) with a demon process (fig.4) which holds the execution behaviour ofthat particular process. File permission function detects our present running application andtraces the behaviour like open, read etc. System calls which will be checked with the demoncontinually and the status is returned to the module for every system call as shown in the fig. 6and 7.If the process is suspicious then terminate it from running state or else continue the processexecution.6. CONCLUSION There are probably other methods of taking an existing running program and spawning aroot process that this module does not catch. The proposed approach would be useful forresearchers in this area. Anybody who depends on a Linux security module (such as SELinux) isdepending on comprehensive checking within the kernel. Some work in this area could do a lotto increase the level of trust which can be placed in LSM-based modules. The implemented LSMmeets these criteria. The patch is relatively small, and the performance data in shows that theLSM patch imposes nearly zero overhead. The broad suite of security products from around theworld that have been implemented for LSM shows that the LSM API is useful and effective fordeveloping Linux security enhancements.REFERENCES[1] Serge Hallyn and Phil Kearns. Domain and Type Enforcement for Linux. In Proceedings ofthe 4th Annual Linux Showcase and Conference, October 2000.[2] Stephen Smalley, Wayne Salamon, and Chris Vance. Implementing SELinux as a LinuxSecurity Module. http://www.nsa.gov, December 2001.[3] Peter Loscocco and Stephen Smalley. Integrating Flexible Support for Security Policies intothe Linux Operating System. In Proceedings of the FREENIX Track: 2001 USENIX AnnualTechnical Conference (FREENIX ’01), June 2001.[4] Stephen Smalley, Timothy Fraser, and Chris Vance. Linux Security Modules: GeneralSecurity Hooks for Linux. http://lsm.immunix.org/, September 2001.[5] Winfried Trumper. Summary about POSIX.1e. http://wt.xpilot.org/publications/posix.1e, July1999.[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 SecuritySymposium, 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