File-system Intrusion Detection by preserving MAC DTS: A Loadable Kernel Module based approach for LINUX Kernel 2.6.x
|
|
- Reynard Simmons
- 8 years ago
- Views:
Transcription
1 File-system Intrusion Detection by preserving MAC DTS: A Loadable Kernel Module based approach for LINUX Kernel 2.6.x Suvrojit Das suvrojit.das@gmail.com Arijit Chattopadhayay arijitnit06@gmail.com Monojit Saha meetmanojit@gmail.com Dipesh Kumar Kalyani dipesh.thepace@gmail.com ABSTRACT Every operating system has its own set of critical files, whose access is generally protected by access control mechanisms, native to the operating system. The importance of such files also simultaneously invites their inspection, unauthorized modification and tampering. So, the need for preserving the authenticity of these critical files along with tracking any unauthorized access to them demands paramount importance. This addresses the need of a good file-system intrusion detection system which is capable of monitoring and tracking any accidental, benign, malicious, intentional changes made to the files that reside in the file-system. For any file the MAC DTS, i.e. the modification, access and creation date and timestamp is a major parameter which can be helpful in detecting any unauthorized access to the documents and monitoring file system intrusion in a broader perspective. So by preserving the MAC DTS we can gain crucial evidence about unauthorized access in the file system. This paper proposes one solution to preserve the MAC DTS for the LINUX operating system (kernel version 2.6.x) with pre-installed plug-ins in the form of Loadable Kernel Modules (LKM). Keywords Intrusion Detection System (IDS); File system; Modification, Access and Creation date and time stamps (MAC DTS); Authentic Date and Time Stamps (ADTS); Virtual File System (VFS) Layer; Loadable Kernel Modules (LKM) Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. To copy otherwise, to republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee. CSIIRW '09, April 13-15, Oak Ridge, Tennessee, USA Copyright 2009 ACM $ INTRODUCTION There are many levels of access protection in the Linux file system, still illegal intrusion into the system is a very common phenomenon. Intruders find their way to enter into the file system, investigate the nature of the file system in order to learn where the vulnerable points are and where the most damage can be caused with the least effort, and then cause serious damage to the system. So providing and maintaining the security in a file system is a challenging issue. An Intrusion Detection System (IDS) are the combination of tools that the security administrator uses to detect an intrusion. To stop the illegal intrusion in a system, it is absolutely necessary to detect them first. The illegal intrusion in a system s file system can be detected by presence of a new unfamiliar file in the system, changes in file permissions, changes in the MAC DTS, missing files. The MAC DTS entities reveal the fundamental information regarding the time of creation of the file and its subsequent modification and access, which provides a crucial role in reconstruction of sequence of events in the file system type operations, in a strict time line. As file systems overwrite the changes in MAC DTS, we cannot get back the original MAC details, as the retrieval of overwritten data is very difficult and expensive. Also, all currently available date and time stamp procedures simply acquire available date and time stamps of the system at that particular instance, which are easy to change. It may so happen that intruders can even tamper with the MAC DTS of the critical files with an objective to remain untraced of their activities and even to deny forensic evidence of their mischief [1]. Hence what we want is the capability in file system itself to assist in preserving original MAC DTS to help in file system intrusion detection. This paper proposes one solution to preserve the MAC DTS of system wide critical files for the LINUX kernel version 2.6.x, by logging the MAC DTS of critical files in a LOG file at the VFS layer itself, so that every unauthorized access can be logged as evidence and as a framework for taking future actions.
2 Fig 1: Virtual File System Architecture 2. RELATED WORK A solution based on ext2 file system for Linux kernel version 2.4, using pre-installed plug-ins in form of Loadable Kernel Modules (LKM) to preserve MAC DTS information, is found in [1]. Though the authors have highlighted the forensic aspects, their idea can be used with further refinements made in this paper, for the purpose of file system intrusion detection. Also, [1] refers to use of data structures specific for the ext2 file system which has its own disadvantages, detailed in section 5. This paper takes care of this type of problems also by not using file system specific data structures. 3. BACKGROUND Linux distinguish between processes running within the kernel (running in kernel mode) and processes started by users (running in user mode) including the special user root. Functions inside the kernel can only be accessed by the use of system calls which provide a well defined and static interface. Even the user root cannot run arbitrary code in kernel mode. Though, Linux is able to load kernel modules at run time. Special system calls are used to bring the code of the module into the kernel. One of Linux's keys to success is its ability to co-exist comfortably with other systems. To support this feature Linux uses a concept called the Virtual File System (VFS) which is a layer of abstraction between the system call interface and the actual implementation of different file systems [Fig. 1]. The key idea behind VFS consists of introducing a common file model capable of representing all supported file systems. For instance in this model each directory is regarded as a file, which contains a list of files and other directories. However several non- UNIX disk based file systems use a file allocation table (FAT) which stores the position of each file in the directory tree. These file-systems do not treat directories as files. To satisfy VFS's common file model the Linux implementations of such FAT based file systems need to construct on the fly the files corresponding to the directories and such files exist only as objects in kernel memory. Actually the Linux kernel does not hard code a particular function to handle an operation such as read() or ioctl(). Instead it uses a pointer for each operation and the pointer is made to point to the proper function for the particular file system being accessed. Fig 2: Interaction Of different objects in a VFS implementation For example, if we want to read a file in an MS-DOS file system, the kernel converts the read() system call into a call specific to the MS-DOS file-system. The application's call to read() makes the kernel invoke the corresponding sys_read() service routine, like every other system call. The file is represented by a file data structure in the kernel memory. The data structure contains a filed called f_op that contains pointers to functions specific to MS- DOS files, including a function that reads a file sys_read() finds the pointer to this function and invokes it. Thus, the application's read() is turned into the rather indirect call: file->f_op->read(...); The common file model consists of the following object types (data structures) [Fig 2]: 1. super block objects: stores information concerning a mounted file system. For disk based file systems this object usually corresponds to a file system control block stored on disk. 2. inode objects: stores general information about a specific file. 3. file objects: stores information about the interaction between an open file and a process. This information exists only in kernel memory during the period when a process has the file open. 4. dentry object: stores information about the linking of a directory entry( i.e. a particular name of a file) with the corresponding file. Each disk based file system stores this
3 Fig 3: generic system call interface information in its own particular way on disk. The most recently used dentry objects are contained in a disk cache (which is a software mechanism that allows the kernel to keep in RAM some information that is normally stored on disk) named the dentry cache which speeds up the translation from a file path name to the inode of the last path name component.each specific file system has its own meta data on disk which includes the super block, the block group descriptors, etc. which can be found in literature. 4. DESIGN AND IMPLEMENTATION Our objective is to develop the kernel module in such a way that it redirects the flow of execution in the VFS layer itself, and so it is not limited to the use of different underlying file system specific data structures. Our implementation does not manipulate central resources like the interrupt descriptor table (IDT) or the system call table [Fig. 4] i.e. we provide a solution at the VFS layer and so it is not file system specific. In our design we are maintaining a LOG file that logs the MAC DTS of the files being accessed and changed in any underlying file system that is registered to the VFS and mounted. To achieve this we have kept in mind the following objectives: 1. Each time some of the specific system files have been accessed or changed, we will be tracking the MAC timestamps and log them in our LOG file, along with the effective user id of the calling process. 2. The LOG file is hidden in such a way that it is not accessible to a normal user. 3. The LOG file can be accessed only by the administrator (valid root user) whenever he wish to do so. 4. In case the system is compromised, i.e., the root password is exposed to the intruder, even then the intruder cannot gain access to the LOG file unless he knows the name of the LOG file; in fact it is the kernel module that writes to the LOG file which is otherwise hidden from the normal file system view. As long as the name of the file is unknown to the intruder, in spite of his gaining the super user privileges, he cannot access the file. 5. The mechanism does not slow down or affect the system performance. 6. The administrator (root) is privileged to consider and mark some system files or other documents as critical to the system and hence allowing it to be monitored for any unauthenticated access. Fig 4: Time line of execution of a system call from user space and trapping of system calls Whenever a file is being monitored, each invocation of sys_open() system call implicitly or explicitly over this file would generate a record of inode number, the EUID of the calling process, and MAC- DTS of that file, describing this access. To understand this fact let us first look at how a file is accessed. Each and every regular file is accessed via the sys_open() system call. When a user process wants to open a file for reading or writing it makes a call to the sys_open() system call either explicitly or implicitly [Fig 4]. By explicit calling we mean that it directly calls sys_open(). Implicit invocation of open is when the system call is invoked by some other program on behalf of the user. The sys_open () or more commonly known by its C wrapper function open() finds an unused file descriptor in the processes file descriptor table. The lowest numbered file descriptor is returned to the process. In our implementation we have modified the sys_open() system call with the help of LKMs. This also provides flexibility in our implementation as this logging mechanism can be inserted and removed at the will of the administrator. Now whenever a user calls sys_open() from any user program, it is being trapped and our own substitution for the sys_open() system call, my_open() is invoked, where we are examining the file which the user program tries to open and if it is among the critical files to be monitored then we keep a LOG of the MAC DTS of that file in our LOG file. After that we call the original sys_open() system call. The salient features of the implementation are: 1. Monitoring the critical files of any recent access or modification or change. 2. Logging in the MAC DTS, inode number of the critical file being accessed, along with and EUID of the caller. 3. Hiding the LOG file from normal file system view provided by the VFS. Our implementation is capable of hiding the file also from the root user as long as the module is loaded in the system, i.e., in case of a compromised system whose super user password is cracked, our implementation demands that the LOG file
4 remains inaccessible, as long as the intruder (who otherwise has the super user privileges) does not know the name of the LOG file. So the complexity of gaining access to the LOG file even in a compromised system is as hard as guessing a standard system password. So, we choose the name of the Log file in such a way that guessing its name is as hard as guessing a password. 4. Preventing access to the LOG file i.e. reading from or writing to it. 5. We have also trapped the unlink system call which prevents intentional or unintentional deletion of the file. 4.1 Details of design and implementation The sequence of steps followed to track access to the critical files by preserving MAC DTS and prevent its alteration is: 1. Trapping the system call by using the system call table address. 2. Writing the LOG into a file. 3. Hiding the LOG file from the file system, unless administrator unloads the module from the system. The entire procedure is implemented on kernel 2.6.x on ext2, ext3 file systems. It ensures that only root has the permission to mention the critical files Trapping System calls In order to trap the system calls in 2.6 Kernel we need to get the address of the system call table. In kernel 2.4.x it was exported by the kernel so this was available easily. In kernel 2.6.x, the system call table's address can be obtained either directly from System.map file or /proc/ kallsyms or by running a loop from two known checkpoints whose addresses are exported. The following steps are followed: a. Get the address of the system call to be replaced. b. Replace address of the system call with the address of the specified code to be run instead of it, so that when the system will call that specific system call then instead of that system call this particular code will run. c. From the modified code the original system call, call the original system call. During the removal we have to restore the address of the original system calls, so that in absence of the module the system will function properly Trapping the open system call Whenever anybody (whether it is the system or any user) tries to access a file, the open system call is implicitly or explicitly called by the system so we trap the open system call [Listing 4.1.1] and monitor some specific critical files (as defined by the administrator) and LOG its MAC DTS Writing to the Log file We have defined a function wrt_file() called from the my_open () function [Listing 4.1.2]. System call: my_open Input: file_path, flags, modes Output: file_descriptor { file_descriptor=get a file_descriptor by opening the file_path in desired mode. Inode=locate the VFS inode of the file; Check whether the file is to be monitored or not. if(to_be_monitored) { Write the inode to the LOG file. Write the modification time, access time, change time of the file. } return (file_descriptor); } Listing Modified sys_open system call Function: wrt_file Input: file_name, data Output: data written to the file { STEP 1. Retrieve the legal virtual address boundaries for that process(virtual Address Space represented by mm_segment_t). STEP 2. Store the address in old_add. STEP 3. Set the address limit to the kernel space (via set_fs(kernel_ds)).kernel_ds stores the address limit for the kernel. STEP 4. Set the wrt_flag as 1. STEP 5. Get file_descriptor by calling sys_open with the file_name and O_APPEND mode. STEP 6. Write the data into the file. STEP 7. Close the file_descriptor STEP 8. Set the address limit to old_add,i.e. to the user s virtual address space. } Listing Algorithm for my_write function Usage of the wrt_flag in the program The wrt_file() calls the open() system call to write into the LOG file. Then the control will move to my_open()which eventually calls the wrt_file(). Thus a loop will be created. For this purpose, we have introduced a variable wrt_flag, a static integer, which will take care of this problem. This variable
5 is set when wrt_file() calls the my_open(). The function my_open() first checks whether this is called from wrt_file() or not. If it is called by wrt_file() then my_open() will not execute the later part; rather it unsets the flag calls the original open system call code and returns. Since this wrt_flag is not a shared by any other process in the system, so even in the case of a context switch between the part of the code where flag is set & unset, it will not affect the system. It will avoid forming the loop and keeps the open() system call in the trapped state, such that if any other file is opened then the system will start trapping Hiding the LOG file After storing the information of the critical files in a LOG, it is mandatory to hide the LOG file from the normal file system view (includes hiding from the purview of the super user). When a file is viewed several dirent structures of a directory must be read irrespective of the local or network file opening procedures. For this purpose getdents64() or getdents() system call is needed. This can be explained with the example of viewing the files in a directory by using the ls command. This command calls getdents64() or getdents() system call. So we need to trap this system call, for hiding the LOG file Trapping the getdents64 system call The basics behind the algorithm of trapping this system call [Fig 5.2], is that whenever a command like ls is issued, it will: 1. Find out the current directory. 2. It will copy the linux_dirent64 structure into a variable declared by us. 3. The directory path is compared with the directory path where the LOG file is kept and if it matches then the getdents64() call is intercepted else the normal call is executed. 4. If the directory is the same, it ll search the entire directory whether the LOG file exists in that particular directory or not. 5. If the LOG file exists in that directory then it ll skip that entry of the LOG file such that although the LOG file exists in the system then also user cannot see the LOG file. Thus, we make the LOG file invisible to the user Avoiding the deletion of the LOG file This is done by trapping the unlink system call 1. It checks the absolute path of the file 2. Compares it with that of the LOG file 3. Prevents deletion if the file to be deleted is the LOG file. Similarly the module and its entry in /proc/modules can be hidden. 5. DISCUSSIONS The whole process is swift and doesn t compromise with the speed of task execution and at the same time maintains the log of MAC DTS of files of paramount importance and prevents this information from any unauthorized access. This LOG file can also serve as forensic digital evidence in computer crimes [1]. But for Fig 5.1 Original working of getdents_64 () Fig 5.2 Trapped version of getdents_64 () that, a standardization of the LOG file and issues like secure storage and unbiased creation of the LOG is necessary so that it becomes a valid digital forensic document acceptable by the Court of LAW. The proposed mechanism has been implemented and tested in both ext2 and ext3 file systems (although not modifying any specific data structures of either ext2 or ext3, rather controlling the whole operation from the VFS layer) with Linux kernel version 2.6.x. A mechanism of directly modifying data structures specific to the ext2 file system, on disk, directly allocating and using data blocks to record MAC- DTS, can be found in [1]. This process does not create inodes to refer to these data blocks. These data blocks are then marked allotted and used for the purpose of hidden storage (of the logged MAC trail information). But then they have to store
6 the addresses of the data blocks to be used for future reference. Rather, they have created and maintained a linked list of these data blocks and stores the address of the header of the linked list in a so far unused field called bg_reserved, of the ext2 block group descriptor. So, this is a case of introducing deliberate inconsistency between the file system metadata and the actual file system data which helps in hiding the data during normal or forceful file system checking operations like that done by e2fsck, which is required in case of any file system errors, detected by the system. When a file system consistency checking program such as e2fsck executes a consistency check on the file system status it refers to the super block and the group descriptors stored in block group[0] and then copies them into all other block groups [4]. Even, if data corruption occurs in the main super block or the main group descriptors in block group[0] become invalid, the system invokes e2fsck to refer to the old copies of the super block and the group descriptors stored in a block groups other than the first. In this process, it may so happen that the contents of fields of bg_reserved, used to save MAC trail log [1], are lost in such a process. Moreover, if certain blocks are marked as being used (1 in block bitmap table) even when no file uses them, (the approach given in [1]) e2fsck will identify and de-allocate the blocks. Since our solution aims at logging MAC DTS at the VFS layer itself, we overcome such problems that arise due to use of data structures specific to different file systems. So, if the very purpose of logging the MAC DTS of a set of critical files and hiding the LOG can be carried out in the VFS layer itself, and if the process of finding out the LOG information is as hard as guessing a password, we can avoid using file system specific data structures. 6. REFERENCES [1] Mridul Sankar Barik, Gaurav Gupta, Subhro Sinha, Alok Mishra, Chandan Mazumdar. An efficient technique for enhancing forensic capabilities of Ext2 file system. Digital Investigation 4S (2007) S55-S61. [2] Dr. Knut Eckstein, Forensics of Advanced Unix FS, 2004 IEE/USMA IA Workshop. [3] Swevson C, Philips, R Shevoi, S 2007 in IFP, Int Federation of Information Processing, Vol. 242, Advances in Digital Forensics III, eds. P Caiger K S Shevoi, ( Borton, Springer), P [4] Bovet Daniel P, Cesati Marco. Understanding the Linux kernel. 3rd ed. O Reilly & Associates. [5] Bach Maurice J. The design of the UNIX operating system. Prentice Hall of India; 1988.
The Linux Virtual Filesystem
Lecture Overview Linux filesystem Linux virtual filesystem (VFS) overview Common file model Superblock, inode, file, dentry Object-oriented Ext2 filesystem Disk data structures Superblock, block group,
More informationCHAPTER 17: File Management
CHAPTER 17: File Management The Architecture of Computer Hardware, Systems Software & Networking: An Information Technology Approach 4th Edition, Irv Englander John Wiley and Sons 2010 PowerPoint slides
More informationCS 416: Opera-ng Systems Design
Question 1 Explain the major difference between a file system that supports journaling (e.g., Linux ext4) versus a log-structured file system (e.g., YAFFS2). Operating Systems 2015 Exam 3 Review Paul Krzyzanowski
More informationFile Systems for Flash Memories. Marcela Zuluaga Sebastian Isaza Dante Rodriguez
File Systems for Flash Memories Marcela Zuluaga Sebastian Isaza Dante Rodriguez Outline Introduction to Flash Memories Introduction to File Systems File Systems for Flash Memories YAFFS (Yet Another Flash
More informationFile System Encryption with Integrated User Management
File System Encryption with Integrated User Management Stefan Ludwig Corporate Technology Siemens AG, Munich fsfs@stefan-ludwig.de Prof. Dr. Winfried Kalfa Operating Systems Group Chemnitz University of
More informationCMSC 421, Operating Systems. Fall 2008. Security. URL: http://www.csee.umbc.edu/~kalpakis/courses/421. Dr. Kalpakis
CMSC 421, Operating Systems. Fall 2008 Security Dr. Kalpakis URL: http://www.csee.umbc.edu/~kalpakis/courses/421 Outline The Security Problem Authentication Program Threats System Threats Securing Systems
More informationChapter 12 File Management
Operating Systems: Internals and Design Principles, 6/E William Stallings Chapter 12 File Management Dave Bremer Otago Polytechnic, N.Z. 2008, Prentice Hall Roadmap Overview File organisation and Access
More informationChapter 12 File Management. Roadmap
Operating Systems: Internals and Design Principles, 6/E William Stallings Chapter 12 File Management Dave Bremer Otago Polytechnic, N.Z. 2008, Prentice Hall Overview Roadmap File organisation and Access
More informationLinux Kernel Architecture
Linux Kernel Architecture Amir Hossein Payberah payberah@yahoo.com Contents What is Kernel? Kernel Architecture Overview User Space Kernel Space Kernel Functional Overview File System Process Management
More informationGuideline on Auditing and Log Management
CMSGu2012-05 Mauritian Computer Emergency Response Team CERT-MU SECURITY GUIDELINE 2011-02 Enhancing Cyber Security in Mauritius Guideline on Auditing and Log Management National Computer Board Mauritius
More informationEnd to End Defense against Rootkits in Cloud Environment. Design- Part 2
End to End Defense against Rootkits in Cloud Environment Design- Part 2 Sachin Shetty Associate Professor Electrical and Computer Engineering Director, Cybersecurity Laboratory Tennessee State University
More informationFile Systems Management and Examples
File Systems Management and Examples Today! Efficiency, performance, recovery! Examples Next! Distributed systems Disk space management! Once decided to store a file as sequence of blocks What s the size
More informationAudit Trail Administration
Audit Trail Administration 0890431-030 August 2003 Copyright 2003 by Concurrent Computer Corporation. All rights reserved. This publication or any part thereof is intended for use with Concurrent Computer
More informationDefining Digital Forensic Examination and Analysis Tools Using Abstraction Layers
Defining Digital Forensic Examination and Analysis Tools Using Abstraction Layers Brian Carrier Research Scientist @stake Abstract This paper uses the theory of abstraction layers to describe the purpose
More informationSurvey of Filesystems for Embedded Linux. Presented by Gene Sally CELF
Survey of Filesystems for Embedded Linux Presented by Gene Sally CELF Presentation Filesystems In Summary What is a filesystem Kernel and User space filesystems Picking a root filesystem Filesystem Round-up
More informationSecure Web Application Coding Team Introductory Meeting December 1, 2005 1:00 2:00PM Bits & Pieces Room, Sansom West Room 306 Agenda
Secure Web Application Coding Team Introductory Meeting December 1, 2005 1:00 2:00PM Bits & Pieces Room, Sansom West Room 306 Agenda 1. Introductions for new members (5 minutes) 2. Name of group 3. Current
More informationChapter 6, The Operating System Machine Level
Chapter 6, The Operating System Machine Level 6.1 Virtual Memory 6.2 Virtual I/O Instructions 6.3 Virtual Instructions For Parallel Processing 6.4 Example Operating Systems 6.5 Summary Virtual Memory General
More informationComparing and Contrasting Windows and Linux Forensics. Zlatko Jovanovic. International Academy of Design and Technology
Comparing and Contrasting Windows and Linux Forensics Zlatko Jovanovic International Academy of Design and Technology Abstract Windows and Linux are the most common operating systems used on personal computers.
More informationLOCKING DOWN LOG FILES: ENHANCING NETWORK SECURITY BY PROTECTING LOG FILES
LOCKING DOWN LOG FILES: ENHANCING NETWORK SECURITY BY PROTECTING LOG FILES Bernie Lantz, Utah State University, bernie.lantz@usu.edu Rob Hall, Utah State University, rob.hall@usu.edu Jason Couraud, Utah
More informationProTrack: A Simple Provenance-tracking Filesystem
ProTrack: A Simple Provenance-tracking Filesystem Somak Das Department of Electrical Engineering and Computer Science Massachusetts Institute of Technology das@mit.edu Abstract Provenance describes a file
More informationChapter 13 File and Database Systems
Chapter 13 File and Database Systems Outline 13.1 Introduction 13.2 Data Hierarchy 13.3 Files 13.4 File Systems 13.4.1 Directories 13.4. Metadata 13.4. Mounting 13.5 File Organization 13.6 File Allocation
More informationChapter 13 File and Database Systems
Chapter 13 File and Database Systems Outline 13.1 Introduction 13.2 Data Hierarchy 13.3 Files 13.4 File Systems 13.4.1 Directories 13.4. Metadata 13.4. Mounting 13.5 File Organization 13.6 File Allocation
More informationFile System Management
Lecture 7: Storage Management File System Management Contents Non volatile memory Tape, HDD, SSD Files & File System Interface Directories & their Organization File System Implementation Disk Space Allocation
More informationOracle Cluster File System on Linux Version 2. Kurt Hackel Señor Software Developer Oracle Corporation
Oracle Cluster File System on Linux Version 2 Kurt Hackel Señor Software Developer Oracle Corporation What is OCFS? GPL'd Extent Based Cluster File System Is a shared disk clustered file system Allows
More informationNetwork Attached Storage. Jinfeng Yang Oct/19/2015
Network Attached Storage Jinfeng Yang Oct/19/2015 Outline Part A 1. What is the Network Attached Storage (NAS)? 2. What are the applications of NAS? 3. The benefits of NAS. 4. NAS s performance (Reliability
More informationLSM-based Secure System Monitoring Using Kernel Protection Schemes
LSM-based Secure System Monitoring Using Kernel Protection Schemes Takamasa Isohara, Keisuke Takemori, Yutaka Miyake KDDI R&D Laboratories Saitama, Japan {ta-isohara, takemori, miyake}@kddilabs.jp Ning
More informationChapter 11: File System Implementation. Operating System Concepts with Java 8 th Edition
Chapter 11: File System Implementation 11.1 Silberschatz, Galvin and Gagne 2009 Chapter 11: File System Implementation File-System Structure File-System Implementation Directory Implementation Allocation
More informationSophos Anti-Virus for Linux user manual
Sophos Anti-Virus for Linux user manual Product version: 7 Document date: January 2011 Contents 1 About this manual...3 2 About Sophos Anti-Virus for Linux...4 3 On-access scanning...7 4 On-demand scanning...10
More informationCS 377: Operating Systems. Outline. A review of what you ve learned, and how it applies to a real operating system. Lecture 25 - Linux Case Study
CS 377: Operating Systems Lecture 25 - Linux Case Study Guest Lecturer: Tim Wood Outline Linux History Design Principles System Overview Process Scheduling Memory Management File Systems A review of what
More informationFile-System Implementation
File-System Implementation 11 CHAPTER In this chapter we discuss various methods for storing information on secondary storage. The basic issues are device directory, free space management, and space allocation
More informationExample of Standard API
16 Example of Standard API System Call Implementation Typically, a number associated with each system call System call interface maintains a table indexed according to these numbers The system call interface
More informationRECOVER ( 8 ) Maintenance Procedures RECOVER ( 8 )
NAME recover browse and recover NetWorker files SYNOPSIS recover [-f] [-n] [-q] [-u] [-i {nnyyrr}] [-d destination] [-c client] [-t date] [-sserver] [dir] recover [-f] [-n] [-u] [-q] [-i {nnyyrr}] [-I
More informationPatterns for Secure Boot and Secure Storage in Computer Systems
Patterns for Secure Boot and Secure Storage in Computer Systems Hans Löhr, Ahmad-Reza Sadeghi, Marcel Winandy Horst Görtz Institute for IT Security, Ruhr-University Bochum, Germany {hans.loehr,ahmad.sadeghi,marcel.winandy}@trust.rub.de
More informationIncident Response and Computer Forensics
Incident Response and Computer Forensics James L. Antonakos WhiteHat Forensics Incident Response Topics Why does an organization need a CSIRT? Who s on the team? Initial Steps Detailed Project Plan Incident
More informationRecovering Deleted Files in Linux
Recovering Deleted Files in Linux Brian Buckeye and Kevin Liston Most systems administrators have experienced a situation where a vital file has accidentally been deleted without a recent backup. In this
More informationUnix/Linux Forensics 1
Unix/Linux Forensics 1 Simple Linux Commands date display the date ls list the files in the current directory more display files one screen at a time cat display the contents of a file wc displays lines,
More informationWhat is Web Security? Motivation
brucker@inf.ethz.ch http://www.brucker.ch/ Information Security ETH Zürich Zürich, Switzerland Information Security Fundamentals March 23, 2004 The End Users View The Server Providers View What is Web
More information1. Introduction to the UNIX File System: logical vision
Unix File System 1. Introduction to the UNIX File System: logical vision Silberschatz, Galvin and Gagne 2005 Operating System Concepts 7 th Edition, Feb 6, 2005 Logical structure in each FS (System V):
More informationLab 2 : Basic File Server. Introduction
Lab 2 : Basic File Server Introduction In this lab, you will start your file system implementation by getting the following FUSE operations to work: CREATE/MKNOD, LOOKUP, and READDIR SETATTR, WRITE and
More informationOPERATING SYSTEMS FILE SYSTEMS
OPERATING SYSTEMS FILE SYSTEMS Jerry Breecher 10: File Systems 1 FILE SYSTEMS This material covers Silberschatz Chapters 10 and 11. File System Interface The user level (more visible) portion of the file
More informationCOS 318: Operating Systems
COS 318: Operating Systems File Performance and Reliability Andy Bavier Computer Science Department Princeton University http://www.cs.princeton.edu/courses/archive/fall10/cos318/ Topics File buffer cache
More informationTraditional Rootkits Lrk4 & KNARK
Traditional Rootkits Lrk4 & KNARK Based on a paper by John Levine & Julian Grizzard http://users.ece.gatech.edu/~owen/research/conference%20publications/rookit_southeastcon2003.pdf ECE 4883 Internetwork
More informationHP-UX Essentials and Shell Programming Course Summary
Contact Us: (616) 875-4060 HP-UX Essentials and Shell Programming Course Summary Length: 5 Days Prerequisite: Basic computer skills Recommendation Statement: Student should be able to use a computer monitor,
More informationA Content-Based Load Balancing Algorithm for Metadata Servers in Cluster File Systems*
A Content-Based Load Balancing Algorithm for Metadata Servers in Cluster File Systems* Junho Jang, Saeyoung Han, Sungyong Park, and Jihoon Yang Department of Computer Science and Interdisciplinary Program
More informationOperating Systems 4 th Class
Operating Systems 4 th Class Lecture 1 Operating Systems Operating systems are essential part of any computer system. Therefore, a course in operating systems is an essential part of any computer science
More informationChapter 3 Operating-System Structures
Contents 1. Introduction 2. Computer-System Structures 3. Operating-System Structures 4. Processes 5. Threads 6. CPU Scheduling 7. Process Synchronization 8. Deadlocks 9. Memory Management 10. Virtual
More informationToasterkit - A NetBSD Rootkit. Anthony Martinez Thomas Bowen http://mrtheplague.net/toasterkit/
Toasterkit - A NetBSD Rootkit Anthony Martinez Thomas Bowen http://mrtheplague.net/toasterkit/ Toasterkit - A NetBSD Rootkit 1. Who we are 2. What is NetBSD? Why NetBSD? 3. Rootkits on NetBSD 4. Architectural
More informationCSE543 - Introduction to Computer and Network Security. Module: Reference Monitor
CSE543 - Introduction to Computer and Network Security Module: Reference Monitor Professor Trent Jaeger 1 Living with Vulnerabilities So, software is potentially vulnerable In a variety of ways So, how
More informationDIGITAL FORENSIC INVESTIGATION, COLLECTION AND PRESERVATION OF DIGITAL EVIDENCE. Vahidin Đaltur, Kemal Hajdarević,
DIGITAL FORENSIC INVESTIGATION, COLLECTION AND PRESERVATION OF DIGITAL EVIDENCE Vahidin Đaltur, Kemal Hajdarević, Internacional Burch University, Faculty of Information Technlogy 71000 Sarajevo, Bosnia
More informationChapter 12 File Management
Operating Systems: Internals and Design Principles Chapter 12 File Management Eighth Edition By William Stallings Files Data collections created by users The File System is one of the most important parts
More informationCustomized Data Exchange Gateway (DEG) for Automated File Exchange across Networks
Customized Data Exchange Gateway (DEG) for Automated File Exchange across Networks *Abhishek Vora B. Lakshmi C.V. Srinivas National Remote Sensing Center (NRSC), Indian Space Research Organization (ISRO),
More informationFile Management. Chapter 12
Chapter 12 File Management File is the basic element of most of the applications, since the input to an application, as well as its output, is usually a file. They also typically outlive the execution
More informationPCI DSS Best Practices with Snare Enterprise Agents PCI DSS Best Practices with Snare Enterprise Agents
PCI DSS Best Practices with Snare Enterprise InterSect Alliance International Pty Ltd Page 1 of 9 About this document The PCI/DSS documentation provides guidance on a set of baseline security measures
More informationSophos SafeGuard Native Device Encryption for Mac Administrator help. Product version: 7
Sophos SafeGuard Native Device Encryption for Mac Administrator help Product version: 7 Document date: December 2014 Contents 1 About SafeGuard Native Device Encryption for Mac...3 1.1 About this document...3
More informationEncrypt-FS: A Versatile Cryptographic File System for Linux
Encrypt-FS: A Versatile Cryptographic File System for Linux Abstract Recently, personal sensitive information faces the possibility of unauthorized access or loss of storage devices. Cryptographic technique
More informationHow To Ensure Correctness Of Data In The Cloud
Ensuring Data Storage Security in Cloud Computing ABSTRACT Cloud computing has been envisioned as the next-generation architecture of IT enterprise. In contrast to traditional solutions, where the IT services
More informationOutpost Network Security
Administrator Guide Reference Outpost Network Security Office Firewall Software from Agnitum Abstract This document provides information on deploying Outpost Network Security in a corporate network. It
More informationINTRUSION PROTECTION AGAINST SQL INJECTION ATTACKS USING REVERSE PROXY
INTRUSION PROTECTION AGAINST SQL INJECTION ATTACKS USING REVERSE PROXY Asst.Prof. S.N.Wandre Computer Engg. Dept. SIT,Lonavala University of Pune, snw.sit@sinhgad.edu Gitanjali Dabhade Monika Ghodake Gayatri
More informationSophos Anti-Virus for Linux configuration guide. Product version: 9
Sophos Anti-Virus for Linux configuration guide Product version: 9 Document date: September 2015 Contents 1 About this guide...5 2 About Sophos Anti-Virus for Linux...6 2.1 What Sophos Anti-Virus does...6
More informationCryptography and Network Security Prof. D. Mukhopadhyay Department of Computer Science and Engineering Indian Institute of Technology, Kharagpur
Cryptography and Network Security Prof. D. Mukhopadhyay Department of Computer Science and Engineering Indian Institute of Technology, Kharagpur Module No. # 01 Lecture No. # 40 Firewalls and Intrusion
More informationDigital Forensics Lecture 3. Hard Disk Drive (HDD) Media Forensics
Digital Forensics Lecture 3 Hard Disk Drive (HDD) Media Forensics Current, Relevant Topics defendants should not use disk-cleaning utilities to wipe portions of their hard drives before turning them over
More informationWe mean.network File System
We mean.network File System Introduction: Remote File-systems When networking became widely available users wanting to share files had to log in across the net to a central machine This central machine
More informationSystem Security Fundamentals
System Security Fundamentals Alessandro Barenghi Dipartimento di Elettronica, Informazione e Bioingegneria Politecnico di Milano alessandro.barenghi - at - polimi.it April 28, 2015 Lesson contents Overview
More informationContents III: Contents II: Contents: Rule Set Based Access Control (RSBAC) 4.2 Model Specifics 5.2 AUTH
Rule Set Based Access Control (RSBAC) Linux Kernel Security Extension Tutorial Amon Ott Contents: 1 Motivation: Why We Need Better Security in the Linux Kernel 2 Overview of RSBAC 3 How
More informationUNISOL SysAdmin. SysAdmin helps systems administrators manage their UNIX systems and networks more effectively.
1. UNISOL SysAdmin Overview SysAdmin helps systems administrators manage their UNIX systems and networks more effectively. SysAdmin is a comprehensive system administration package which provides a secure
More informationSnare System Version 6.3.4 Release Notes
Snare System Version 6.3.4 Release Notes is pleased to announce the release of Snare Server Version 6.3.4. Snare Server Version 6.3.4 New Features The behaviour of the Snare Server reflector has been modified
More informationSystem Calls Related to File Manipulation
KING FAHD UNIVERSITY OF PETROLEUM AND MINERALS Information and Computer Science Department ICS 431 Operating Systems Lab # 12 System Calls Related to File Manipulation Objective: In this lab we will be
More informationLinux Security on HP Servers: Security Enhanced Linux. Abstract. Intended Audience. Technical introduction
Linux Security on HP Servers: Security Enhanced Linux Technical introduction This white paper -- one in a series of Linux security white papers -- discusses Security Enhanced Linux (SELinux), a mandatory
More informationIT6203 Systems & Network Administration. (Optional)
Systems & Network Administration (Optional) INTRODUCTION This is one of the Optional courses designed for Semester 6 of the Bachelor of Information Technology Degree program. This course on Systems & Network
More informationLSN 10 Linux Overview
LSN 10 Linux Overview ECT362 Operating Systems Department of Engineering Technology LSN 10 Linux Overview Linux Contemporary open source implementation of UNIX available for free on the Internet Introduced
More informationIntroduction. What is an Operating System?
Introduction What is an Operating System? 1 What is an Operating System? 2 Why is an Operating System Needed? 3 How Did They Develop? Historical Approach Affect of Architecture 4 Efficient Utilization
More informationConcepts of digital forensics
Chapter 3 Concepts of digital forensics Digital forensics is a branch of forensic science concerned with the use of digital information (produced, stored and transmitted by computers) as source of evidence
More informationPractical Online Filesystem Checking and Repair
Practical Online Filesystem Checking and Repair Daniel Phillips Samsung Research America (Silicon Valley) d.phillips@partner.samsung.com 1 2013 SAMSUNG Electronics Co. Why we want online checking: Fsck
More informationReview from last time. CS 537 Lecture 3 OS Structure. OS structure. What you should learn from this lecture
Review from last time CS 537 Lecture 3 OS Structure What HW structures are used by the OS? What is a system call? Michael Swift Remzi Arpaci-Dussea, Michael Swift 1 Remzi Arpaci-Dussea, Michael Swift 2
More informationRyusuke KONISHI NTT Cyberspace Laboratories NTT Corporation
Ryusuke KONISHI NTT Cyberspace Laboratories NTT Corporation NILFS Introduction FileSystem Design Development Status Wished features & Challenges Copyright (C) 2009 NTT Corporation 2 NILFS is the Linux
More informationPORTABLE STORAGE DEVICE MANAGEMENT IN LINUX
PORTABLE STORAGE DEVICE MANAGEMENT IN LINUX Tushar B. Kute 1 and Kabita Ghosh 2 1 2 Department Department of Information Technology Sandip Institute of Technology and Research Centre, Nashik ABSTRACT The
More informationNetwork Based Intrusion Detection Using Honey pot Deception
Network Based Intrusion Detection Using Honey pot Deception Dr.K.V.Kulhalli, S.R.Khot Department of Electronics and Communication Engineering D.Y.Patil College of Engg.& technology, Kolhapur,Maharashtra,India.
More informationIS TEST 3 - TIPS FOUR (4) levels of detective controls offered by intrusion detection system (IDS) methodologies. First layer is typically responsible for monitoring the network and network devices. NIDS
More informationSQL SERVER Anti-Forensics. Cesar Cerrudo
SQL SERVER Anti-Forensics Cesar Cerrudo Introduction Sophisticated attacks requires leaving as few evidence as possible Anti-Forensics techniques help to make forensics investigations difficult Anti-Forensics
More informationMultiprogramming. IT 3123 Hardware and Software Concepts. Program Dispatching. Multiprogramming. Program Dispatching. Program Dispatching
IT 3123 Hardware and Software Concepts Operating Systems II October 26 Multiprogramming Two or more application programs in memory. Consider one CPU and more than one program. This can be generalized to
More informationChapter 23. Database Security. Security Issues. Database Security
Chapter 23 Database Security Security Issues Legal and ethical issues Policy issues System-related issues The need to identify multiple security levels 2 Database Security A DBMS typically includes a database
More informationA User-Oriented Approach to Scheduling Collection Building in Greenstone
A User-Oriented Approach to Scheduling Collection Building in Greenstone Wendy Osborn 1, David Bainbridge 2,andIanH.Witten 2 1 Department of Mathematics and Computer Science University of Lethbridge Lethbridge,
More informationEnsuring Security in Cloud with Multi-Level IDS and Log Management System
Ensuring Security in Cloud with Multi-Level IDS and Log Management System 1 Prema Jain, 2 Ashwin Kumar PG Scholar, Mangalore Institute of Technology & Engineering, Moodbidri, Karnataka1, Assistant Professor,
More informationNetwork File System (NFS) Pradipta De pradipta.de@sunykorea.ac.kr
Network File System (NFS) Pradipta De pradipta.de@sunykorea.ac.kr Today s Topic Network File System Type of Distributed file system NFS protocol NFS cache consistency issue CSE506: Ext Filesystem 2 NFS
More informationIBM Endpoint Manager Version 9.2. Patch Management for SUSE Linux Enterprise User's Guide
IBM Endpoint Manager Version 9.2 Patch Management for SUSE Linux Enterprise User's Guide IBM Endpoint Manager Version 9.2 Patch Management for SUSE Linux Enterprise User's Guide Note Before using this
More informationRed Hat Linux Internals
Red Hat Linux Internals Learn how the Linux kernel functions and start developing modules. Red Hat Linux internals teaches you all the fundamental requirements necessary to understand and start developing
More informationForensic Analysis of Internet Explorer Activity Files
Forensic Analysis of Internet Explorer Activity Files by Keith J. Jones keith.jones@foundstone.com 3/19/03 Table of Contents 1. Introduction 4 2. The Index.dat File Header 6 3. The HASH Table 10 4. The
More informationSome basic features of UNIX
4 Case Study: UNIX 2009 Springer-Verlag Berlin Heidelberg / 2010 Joachim Biskup TU Dortmund Security in Computing Systems: Case Study: UNIX - 04. 02. 2010 115 Some basic features of UNIX UNIX supports
More informationTPM Key Backup and Recovery. For Trusted Platforms
TPM Key Backup and Recovery For Trusted Platforms White paper for understanding and support proper use of backup and recovery procedures for Trusted Computing Platforms. 2006-09-21 V0.95 Page 1 / 17 Contents
More informationTELE 301 Lecture 7: Linux/Unix file
Overview Last Lecture Scripting This Lecture Linux/Unix file system Next Lecture System installation Sources Installation and Getting Started Guide Linux System Administrators Guide Chapter 6 in Principles
More informationCompliance Response Edition 07/2009. SIMATIC WinCC V7.0 Compliance Response Electronic Records / Electronic Signatures. simatic wincc DOKUMENTATION
Compliance Response Edition 07/2009 SIMATIC WinCC V7.0 Compliance Response Electronic Records / Electronic Signatures simatic wincc DOKUMENTATION Compliance Response Electronic Records / Electronic Signatures
More informationFull Compliance Contents
Full Compliance for and EU Annex 11 With the regulation support of Contents 1. Introduction 2 2. The regulations 2 3. FDA 3 Subpart B Electronic records 3 Subpart C Electronic Signatures 9 4. EU GMP Annex
More informationCSE 120 Principles of Operating Systems. Modules, Interfaces, Structure
CSE 120 Principles of Operating Systems Fall 2000 Lecture 3: Operating System Modules, Interfaces, and Structure Geoffrey M. Voelker Modules, Interfaces, Structure We roughly defined an OS as the layer
More information15 AFS File Sharing. Client/Server Computing. Distributed File Systems
15 AFS File Sharing Adapted from the Open AFS Guide, http://openafs.org/doc/ AFS makes it easy for people to work together on the same files, no matter where the files are located. AFS users do not have
More informationAcronis Backup & Recovery 10 Server for Linux. Command Line Reference
Acronis Backup & Recovery 10 Server for Linux Command Line Reference Table of contents 1 Console mode in Linux...3 1.1 Backup, restore and other operations (trueimagecmd)... 3 1.1.1 Supported commands...
More informationStorage and File Systems. Chester Rebeiro IIT Madras
Storage and File Systems Chester Rebeiro IIT Madras 1 Two views of a file system system calls protection rwx attributes Application View Look & Feel File system Hardware view 2 Magnetic Disks Chester Rebeiro
More informationCSC 2405: Computer Systems II
CSC 2405: Computer Systems II Spring 2013 (TR 8:30-9:45 in G86) Mirela Damian http://www.csc.villanova.edu/~mdamian/csc2405/ Introductions Mirela Damian Room 167A in the Mendel Science Building mirela.damian@villanova.edu
More informationDistributed File Systems Part I. Issues in Centralized File Systems
Distributed File Systems Part I Daniel A. Menascé File Naming Issues in Centralized File Systems c:\courses\cs571\procs.ps (MS-DOS) /usr/menasce/courses/cs571/processes.ps (UNIX) File Structure bitstream
More informationtechnical brief browsing to an installation of HP Web Jetadmin. Internal Access HTTP Port Access List User Profiles HTTP Port
technical brief in HP Overview HP is a powerful webbased software utility for installing, configuring, and managing networkconnected devices. Since it can install and configure devices, it must be able
More information