International Journal of Engineering INTERNATIONALComputer Volume OF COMPUTER ENGINEERING JOURNAL 3, Issueand Technology (IJCET), ISSN 0976 6367(Print), ISSN

N 0976 6375(Online) 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 IAEME: www.iaeme.com/ijcet.asp Journal Impact Factor (2012): 3.9580 (Calculated by GISI) www.jifactor.com

IJCET
IAEME

PROCESS BEHAVIOUR MODELLING USING LSM

1 2

S. Ravi Sankar1, Y. Swapna2

(Faculty, CSE Department, National Institute of Technology, Goa, India, srs@nitgoa.ac.in) (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 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

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

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 strcmp\n"); strcpy(kbuf,"socket"); up(&semr); down_interruptible(&semw); if(status=='n') { printk("process behaviour is suspicious , will be aborted\n"); 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), 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 function\n"); reg = register_security(&secop); if(reg!=0) { printk(KERN_ALERT"register security failed\n"); return -1; } return 0; } void cleanup_module(void) { printk(KERN_ALERT"in exit function\n"); ureg=unregister_security(&secop); if(ureg!=0) { printk(KERN_ALERT"unregister security failed\n"); } } int f_per (struct file *file,int mask) { if( strcmp(current->comm,"app")==0 ) { printk(KERN_ALERT"in file permission function after strcmp\n"); printk(KERN_ALERT"path =%s\n",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 %d\n",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

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

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