TransCrypt File Server Enhancements for Secure Remote Access

Transcription

1 TransCrypt File Server Enhancements for Secure Remote Access Salih K A Department of Computer Science & Engineering Indian Institute of Technology Kanpur July 2009

2 TransCrypt File Server Enhancements for Secure Remote Access A Thesis Submitted In Partial Fulfillment of the Requirements For the Degree of Master of Technology by Salih K A to the Department of Computer Science & Engineering Indian Institute of Technology Kanpur July 2009

3

4 Abstract Many organizations keep a great deal of confidential information on computers. Such information is to be stored securely, while giving the convenience of accessibility from any part of the world. For data security, one can make use of encrypting filesystems such as File Vault, ecryptfs, dmcrypt etc. Another encrypting file system TransCrypt [25] was designed to provide a very strong solution to the problem of securing data in a manner transparent to the user. It provides stronger security compared to other existing encrypting file systems and restricts its trust only to instructions in the kernel mode of execution. All processes in user space including processes with super user privileges, are excluded from its trust model. TransCrypt provides per-user access control, per-file encryption and per-volume managerial control. However, it was not designed to work over network and hence could not address the security issues when data was accessed over network. In this thesis, we re-architecture TransCrypt to make it work over network as a network file system. The major security breaches while accessing the files over network are carefully analyzed and the proposed design counters all these attacks using strong cryptographic methods. We also discuss the implementation of the design at the File Server side, where TransCrypt volumes are hosted. Additionally, the earlier TransCrypt implementations had made a set of modifications to the Virtual File System (VFS) layer in the Linux kernel. The Linux kernel code undergoes changes periodically and hence causes problems while porting Trans- Crypt to newer versions. This work also moves the TransCrypt VFS modifications to a Linux Security Module (LSM), which makes TransCrypt largely independent of Linux Kernel code changes. In addition to this, design and implementation of a certificate cache is discussed which makes the perfomance of TransCrypt based filesystem a lot better than the earlier implementations [18, 30, 24].

5 Acknowledgments I wish to express my gratitude to Prof. Rajat Moona, without whom this thesis would not have been possible. His constant support, advise and guidance made it a pleasure to work on this project. I also thank the Prabhu Goel Research Center for Computer and Internet Security for supporting me and providing me with the excellent facilities to complete this project. I also thank Abhay Khoje and Satyam Sharma for their help and suggestions throughout my work. Thanks are also due to Ajin George Joseph, Sijumon K, Harish B, Sanjoy C, Binesh J, Deepak Luckose and Hari for patiently listening to me and helping me flesh out my ideas. I also thank my entire class, the M.Tech batch of CSE it was a pleasure to be surrounded by a set of such helpful, fun-loving and talented individuals. Finally, I thank my mother, father and sisters whose love, support and encouragement made all of this possible. i

6 Contents 1 Introduction Motivation Related Work Distributed File Systems Andrew File System (AFS) CODA Network File System (NFS) NFS and Security Traditional NFS security methods NFS version 4 Security Enhancements Encrypted File Systems Contribution of this Thesis Organization Background Network File System (NFS) NFS Protocol NFS Architecture Linux Security Module (LSM) Overview LSM Architecture Interface for security functions Kernel security hook functions Security fields in kernel objects Module Registration Process capabilities ii

7 2.3 Configfs User space View Kernel space View TransCrypt Architecture TransCrypt in a Nutshell TransCrypt Implementation Kernel space Components VFS Changes Configuration Manager Public Key Infrastructure (PKI) manager Keyring Manager Communication Manager Device Mapper module (dm-transcrypt) Userspace Programs TransCrypt Daemon (transcryptd) TransCrypt Authserver (transcrypt-auth) TransCrypt Utilities Enhancements for Modularity and Performance TransCrypt-LSM Module File open File Creation File Sharing Mount filesystem File Delete Certificate Caching Protocol to Cache Certificates Caching details Invalidation Details TransCrypt as a Network File System Remote access threats for TransCrypt Threats on the File Server Offline attacks iii

8 Online attacks Threats from untrusted network Eavesdropping Man-in-the-middle attack Replay Attack Approach Preventing Attacks on the File Server Preventing Attacks from the Network Eavesdropping Man-in-the-middle attack Replay Attack Additional TransCrypt Modifications Protocols Negotiation Protocol Secure Protocol PKS Registration Authenticated session between workstation kernel and smart card Authenticated session between workstation and file server kernels Trust Model NFS operations Implementation Modifications in User space Programs Modifications in Kernel space File server Programs Protocol Messages Message Formats Performance Evaluation Experimental Setup Results and Analysis Create Performance Setfacl Performance iv

9 7 Conclusion Summary Future Work v

10 List of Figures 1.1 Model of file access NFS Architecture LSM Hook Architecture [31] TransCrypt Architecture Model of File Access Man-in-the-middle attack Negotiation Protocol Authentication between Workstation (WS) & File Server (FS) NFS file operations Protocol Headers Performance Results vi

11 Abbreviations used in the thesis FS : File Server - Normally referred to a computer hosting TransCrypt services. WS : Work Station - The host from where a user access his files on a FS. PKS : Private Key Store - The PKS stores the private key of the subject and provides cryptographic operations related to the private key. SCURI : Smart Card Uniform Resource Identifier - This identifier is used to identify the location of SmartCard uniquely and includes the IP address of the machine and part of the SmartCard reader, where the user s SmartCard is inserted. FEK : File Encryption Key - The randomly generated symmetric key for a newly created file to encrypt and decrypt file data. FSK : File System Key - This symmetric key is unique for each volume and is used to provide further security to FEK. Eu P (M) : Asymmetric key encryption of the message, M with the public key of the entity, u. EK(M) S : Symmetric key encryption of the message, M with the key K. 1

12 Chapter 1 Introduction 1.1 Motivation Security is quickly becoming a mandatory feature of data storage systems. Today, storage space is typically provided by complex networked systems. These networks have traditionally been confined to data centers in physically secured locations. But with the availability of high-speed Local Area Networks (LANs) and storage networking protocols, these networks are becoming virtualized and open to access from user machines. Hence, clients may access the storage devices directly, and the existing static security methods are no longer sufficient to protect the data from intruders. New, dynamic security mechanisms are required for protecting data in networked storage systems. For data security, several solutions have been devised. This include File Vault [1], ecryptfs [12], dm-crypt [9], Microsoft EFS [14] etc. These encrypting file 2

13 systems provide security by encrypting and decrypting user data thereby addressing the problem of data security in many different ways [25]. However these encrypting file systems do not address the problem of accessing files over network from networked computers. Another encrypting file system TransCrypt [25] was designed to provide a very strong solution to the problem of securing data in a user transparant manner. TransCrypt is an enterprise-class, kernel-space encrypting file system for the Linux operating system. It provides per-user access control, per-file encryption and per-volume managerial control. However it is not designed to work over network and hence does not address the security issues when the data is accessed over network from networked computers. Hence a need was felt for re-architecting TransCrypt so as to make it work over network as a network file system. In addition, the TransCrypt implementation [18, 30] made a set of modifications to the Virtual File System (VFS) layer in the Linux kernel. The Linux kernel code undergoes changes periodically and hence causes problems while porting Trans- Crypt to newer versions. Hence a need was felt for an improved TransCrypt file system which avoids the approach of VFS system call interposition for incorporating its access control methods. 1.2 Related Work For remote file access, one can make use of any distributed file systems such as Andrew File System (AFS), CODA and Network File System (NFS). Encrypted File Systems (EFS) can be used to protect the file servers from intruders. This section explains in brief about the commonly used DFSs and EFSs. 3

14 1.2.1 Distributed File Systems Andrew File System (AFS) AFS [22] is a distributed filesystem that permits clients and servers to share filesystem resources across LANs and Wide Area Networks (WANs). One of the main design goal of AFS was scalability. Whenever an AFS client access any file on the server, the server passes the complete file to the client, which the client caches locally. Thereafter, all the operations are performed on the local copy. When the client saves the file, the local copy is sent to the server. Cache consistency is maintained by using a call back mechanism, in which the server informs the client whenever the file is updated by some one else. Some features of the AFS are mentioned below. Caching at clients to improve performance. Provides location Independence by mapping File names to location at server. Integrates security features like Kerberos for user authentication. Provides access control based authentication methods. The AFS has however certain disadvantages. It is a complex system to develop and costly to setup. Further AFS does not support UNIX like permissions model which makes it hard to support UNIX semantics CODA CODA [23] is a distributed filesystem developed at Carnegie Mellon University. It is the descendant of the Andrew File System (AFS). The main design goal for CODA 4

15 was to provide continuous data availability. This feature is achieved by using server replication and disconnected operations. A volume in a CODA filesystem can be shared among multiple servers. The clients can download files from any available servers. Whenever a client saves a file, it propagates the modifications to all the available servers. While servers are available, clients can also specify to cache some files for future use (a feature known as hoarding). Later when a client is disconnected from the servers, it can continue to work with the cached files. Once the client gets back the connectivity, it plays the cached operations log (i.e. file modifications) to the server. These modifications are merged at the servers. Sometimes human intervention is required if conflicts occurs while merging. The main features of coda are the following. It is designed for high scalability. It provides better data availability than other distributed file systems by server replication and hoarding techniques. It is mainly used by mobile users. It incorporates Kerberos [16] based authentication mechanisms for security It provides Access Control Lists for authentication. CODA has certain disadvantages such as being slower than AFS and the fact that it trusts the underlying network for not altering the client authentication credentials. 5

16 Network File System (NFS) NFS [19] is one of the DFS that is standard, matured and supported robustly across a variety of platforms. It is a client-server model filesystem, developed by Sun Micro system. NFS uses Remote Procedure Call (RPC) [27] for communication between servers and clients. RPC is built over external Data Representation (XDR) [26] which provides portability across platforms. NFS provides centralized administration. NFS v4 [20] incorporated various features like delegation of files to clients for caching, mandates use of various strong security mechanisms NFS and Security When NFS was originally designed, the main focus was to provide a simple mechanism for transparent remote file access. Hence little emphasis was placed on security concerns. A trusted network was assumed. Every host and every user were who they said they were. The server could specify which all hosts could mount its file systems and how to access the files. But, an attacker with control of an NFS Client could impersonate any other user if he is permitted to mount a file system. Due to the widespread acceptance of the NFS these days, security became an important concern. It leads to redesigning its authentication and access control methods. 6

17 Traditional NFS security methods NFS has evolved through time. The version 3 of NFS [4] provided the following security capabilities. Server authentication - None. The NFS v3 does not require any server authentication. Client authentication - Server is provided with a set of authorized clients (listed by either hostname or IP address). Thereafter the source IP address of the network file request packets will be validated by the server. This is a weak security mechanism as an attacker could falsify the source IP address and can get access to some other user s files. User authentication - NFS used RPC authentication methods to determine whether the user requesting the operation is authorized to perform it or not. The available methods include AUTH NONE - No authentication. AUTH UNIX - here the server trusts the UIDs and GIDs provided by a client. But if the attacker can become a superuser on the client, he can use su command to trivially send any GID or UID. Besides communication between NFS server and client are not encrypted and hence could give attackers information about valid GIDs and UIDs in clients and servers. 7

18 NFS version 4 Security Enhancements One of the main factors to develop NFS v4 [20] was to provide strong security. A number of sophisticated security mechanisms were proposed in NFS v4 and mandated for implementation by all conforming clients. One of the main security enhancements was mandatory Kerberos [16] support. NFS servers can be authenticated by a client by comparing server s certificate with a list of trusted Certification Authorities. For user authentication, clients are required to present valid Kerberos credentials ie, a service ticket issued by Kerberos Key Distribution Center (KDC). For a secure implementation, the KDC must be protected against attacks to maintain the integrity of the system. It is generally very hard to provide such a Kerberos setup in a public environment Encrypted File Systems To prevent the attack on File Servers, encrypted file systems such as the Encrypting File System (EFS) [14], dmcrypt [9], ecryptfs [12], TransCrypt [25] can be used. EFS implements encryption at the kernel level, but all key-management operations are done at user space. This hybrid feature makes it vulnerable to user-space attacks. dmcrypt is a encrypting file system that is volume based and is part of the standard Linux kernel. But it lacks flexibility due to the use of a common mount-wide key. Additionally dmcrypt addresses a narrow threat model. ecryptfs is a kernel-native cryptographic file system for Linux. It is a stacked file system that encrypts and decrypts the files as they are written to or read from the lower file system. It is vunerable to user space attacks as it uses a user space daemon for key management. Additionally, super users are trusted in ecryptfs. TransCrypt is a secure, usable, 8

19 Figure 1.1: Model of file access transparent, efficient enterprise-class encrypting file system for Linux. It excludes the super user from the trust model. It uses per-file encryption key and per-user authentication keys for confidentiality and access control. The solutions available for the encrypting filesystem however do not tackle the attacks arising from the network and the user Work Stations, which are more vulnerable in general. 1.3 Contribution of this Thesis TransCrypt was initially not designed to work over network and hence does not address the security issues when the data is accessed over network from remote computers. The earlier implementation of TransCrypt modified the VFS layer system calls to incorporate its permission related operations. This approach presented some drawbacks like lack of flexibility because TransCrypt changes have to be compiled into the kernel, and code maintenance against newer kernel versions. 9

20 This thesis discusses the issues when users access their files over network from a TransCrypt file system and proposes a solution for the same. We assume the model shown in Figure 1.1 to develop our solution. Implementation details of the solution at the File Server side are described. Performance tests conducted on the implementation against the unsecured NFS file access methods are plotted and the results are analyzed. It also discusses how the Linux Security Module (LSM) Framework [31] can be used for TransCrypt for better flexibility and code maintenance. In addition, the design and implementation of an in-kernel certificate cache for performance enhancements at the time of file creation and sharing is discussed. 1.4 Organization The rest of the thesis is organized in the following manner. In chapter 2, we discuss the terminologies used in the remaining thesis. In chapter 3, we provide the overall design and implementation of the earlier TransCrypt version (version 0.2) [28]. In chapter 4, we describe how the LSM framework can be used for TransCrypt for better flexibility and code maintenance. In addition, the design and implementation of a certificate cache for performance enhancements is discussed. In chapter 5, we explore the TransCrypt s vulnerabilities related to network wide usage and provide a mechanism for enabling TransCrypt to work over network as a networked file system. In chapter 6, we provide details about the performance results conducted on the new implementation. The results are compared with the insecure NFS file access methods. Finally this thesis is concluded in chapter 7 with a note on future work. 10

21 Chapter 2 Background In this thesis, a method to enable TransCrypt to work as a network filesystem is discussed. In this scenario, users access TransCrypt volumes hosted on a Server from a public Work Station host using the NFS protocol [19]. Additionally, the new Trans- Crypt implementation makes use of the Linux Security Module (LSM) framework [31] provided by the Linux Kernel to remove the VFS layer system call modifications made by TransCrypt in the earlier implementations [18, 30]. This improves flexibility and code maintenance. The new implementation also provides a certificate cache to improve the performance during file operations. A user-interface is developed as part of the cache framework to make the administrative tasks simpler. TransCrypt uses the Configfs [2] pseudo filesystem to create this interface. In this Chapter, we briefly discuss these components used in the current implementation of TransCrypt. 11

22 2.1 Network File System (NFS) Network File System (NFS) [19] is one of the distributed filesystems that is most popular and widely used. It was originally designed and implemented by Sun Microsystems. NFS allows machines to share files and privileged remote users can access these files as if they were local to the user s machine. NFS is designed to work in a heterogeneous environment in which machines of different architectures, running different operating systems can share resources across network. NFS achieves this through the use of Remote Procedure Call (RPC) [27] primitives built on top of an external Data Representation (XDR) [26] NFS Protocol NFS protocol represents the series of messages exchanged between an NFS server and the client. Information is exchanged between the server and the client using the underlying Remote Procedure Call (RPC) [27] protocol. To start the NFS service on a machine, the NFS server software has to be initiated. This requires a Portmap daemon, the nfs daemon and a mount daemon to run in that order. The Portmap allows NFS clients to discover which port the server is listening to. The nfs daemon services the requests arising from NFS clients. The mount daemon checks to see if mount requests from NFS clients match with a currently exported filesystem. Before accessing the files on an NFS server, the clients must mount the NFS filesystem locally. The client specifies the following arguments in the mount command. 12

23 The IP address or the hostname of the server. The directory path name on the server that it wants to mount. The local mount point. The authentication mechanism to be used. The network protocol to be used (ie, TCP or UDP). The server will then check the configuration files (/etc/exports, /etc/hosts.allow and /etc/hosts.deny) with the identification of the client host to determine whether access should be granted or not. Entries in the /etc/exports [11] file on the server indicates a volume that is shared and the mode in which it is shared. This file serves as access control list for file systems which are exported to NFS clients. Entries in the hosts.allow and hosts.deny specify the clients that can use services on the server. If the access is granted, the server provides a filehandle to the client. The filehandle has certain fields that uniquely represent the filesystem type, the inode of the file, the disk and the security information. Subsequent NFS requests take the form of write and read requests, file creation and deletion, modifying file permissions etc. These requests carry the following arguments to the server. The filehandle of the object on which to perform the operation. The identity of the user performing operation. The type of operation to be performed (write, set attribute etc.). 13

24 Procedure specific arguments like the offset within the file to read from, data to be written etc. When a client requests for an operation on a specific filehandle, the server verifies the permissions and the Access Control Lists (ACLs) associated with the file that this filehandle represents. This along with the user and client details is used to determine whether access should be granted or not NFS Architecture Figure 2.1 shows the architecture diagram of the NFS. It contains mainly three layers. 1. System calls interface: This layer handles filesystem related calls like open, read, close etc. from the processes. 2. VFS interface: This layer decides whether the file being accessed is local or remote. If the file location is on a remote location, the VFS interface transfers the control to the corresponding NFS procedure. 3. NFS Client: This layer implements the NFS protocol described earlier. It is the bottom layer of the architecture. The NFS clients cache the filehandles obtained from servers for performance enhancements. All the requests from NFS clients are handled by the NFS servers. RPC protocol is used for the communication between the NFS servers and clients. 14

25 Figure 2.1: NFS Architecture 15

26 2.2 Linux Security Module (LSM) Overview Historically in Linux kernels prior to Linux version 2.6, there were no direct support for enhanced access control mechanisms in the Linux kernel. There was no infrastructure to mediate access to kernel objects externally. Enhanced access control mechanisms were implemented as kernel patches. It brought changes to the kernel source and hence was not a flexible solution. Hence, under the guidance of Linus Torvalds, LSM framework [31] was created with the following principles. The Linux kernel continues to do the normal security checks as being done earlier. When Linux kernel needs to decide whether the access should be granted or not, it also checks with the security modules to determine whether the action is okay. An administrator can pick the security module depending upon the needs and policy of the installation. LSM was designed to provide for specific needs to successfully implement a mandatory access control module, while imposing the fewest possible changes to the Linux kernel [13]. It inserted hooks in the kernel code just before accessing important kernel objects such as task control blocks and inodes (figure 2.2). LSM modules provide the functions called by these hooks. LSM framework provides APIs to allow kernel modules to register or unregister as security modules. 16

27 Figure 2.2: LSM Hook Architecture [31] LSM Architecture Five components were added or modified to support LSM [31] in the Linux kernel. 1. A generic interface for security functions. 2. Calls to security functions at various parts in the kernel. 3. Security related data structure components to various kernel data structures. 4. Functions to be called by kernel modules to register and unregister as security modules. 17

28 5. Capabilities [5] logic migration into an optional security module Interface for security functions The security operations structure in the kernel code defines the supported security functions as function pointers. It defines a global variable extern struct security operations security ops. It has a set of static functions each of which correspond to a security related function Kernel security hook functions The LSM framework inserts hooks to security functions at critical points in the kernel code to perform access control and to manage the security fields. An example of the first category of hooks is the inode permission hook, which checks permissions when accessing an inode. Examples of the second category hooks include the free security hooks and alloc security, which are used to free and allocate security structures for kernel objects Security fields in kernel objects Security related data structure components are generic pointers which are added to various kernel data structures to associate security information. For example, fields are added in task struct data structure for supporting task related access control. The manipulation and use of these security fields are carried out by various security modules. 18

29 Module Registration LSM framework is initialized with a set of dummy functions during the kernel boot sequence. When a security module is loaded, it registers with the LSM framework using the register security function. It causes the global security ops table to point to the module s hook function pointers, resulting the kernel to call the security module for access control decisions. When the module wants to unload, it must call unregister security to unregister with the framework. The framework only registers one module as primary module. It provides mechanisms for stacking more security modules with a primary security module. The decision of module stacking is left to primary module. It can determine when to call other modules and it combines the results from other modules Process capabilities Capabilities are a partitioning of the all powerful root privileges [5]. A process has three sets of bitmaps to implement permitted, inheritable and effective capabilities. A capability is implemented as a bit in these bitmaps which is either set or unset. The LSM project developed a separate security module for capabilities and migrated the earlier capabilities logic implementation to this security module. 2.3 Configfs Configfs is one of the various methods available for communication between the kernel and user space. It is a virtual file system in which the lifetime of objects is 19

30 completely managed by processes in user space. This is the widely accepted method for configuring a kernel subsystem from user space [7] in modern Linux kernels User space View Any kernel subsystem that wants to use configfs for communication creates one or more directories within configfs. Directories in configfs represent objects in kernel [7]. Directories contain files, which represent the object attributes. Privileged user space processes can create or delete directories (using mkdir and rmdir) under the subsystem. This leads to a call back within the kernel and hence the corresponding action on the objects. Attributes can be seen or set from within user space using read or write system calls. Default directories can be made under any subsystem. These directories (and the files inside) will be created automatically, when the subsystem is loaded initially Kernel space View Objects are represented as a config item [8] (represented by struct config item) in the kernel. Each config item has a type associated with it (represented by struct config item type), which describes the attributes (files in userspace) and the operations permitted on those attributes. These operations are the call back methods in kernel that correspond to specific user actions in userspace. struct config_item {...other parameters... 20

31 struct config_group *ci_group; struct config_item_type *ci_type; }; A config item cannot exist by itself, it resides on a config group (represented as config group structure). It itself is a config item and can contain other config groups or items. It can create child items or groups through the group operations specified in group s config item type. These methods will be called when a user performs mkdir in the group s directory in userspace. struct config_group { struct config_item cg_item; struct configfs_subsystem *cg_subsys; struct config_group **default_groups;...other parameters... }; default groups under config group will be automatically created when the parent group is created. They are removed automatically when the parent group dies. Config subsystem (represented by struct configfs subsystem) is the top level config group and it represents the client subsystem as a whole. struct configfs_subsystem { struct config_group su_group;...other parameters... }; 21

32 Chapter 3 TransCrypt Architecture 3.1 TransCrypt in a Nutshell TransCrypt is a secure, usable, transparent, enterprise-class encrypting file system for Linux. It provides stronger security compared to other existing encrypting file systems and restricts its trust only to the kernel by excluding userspace (including processes with super user privileges) from the trust model. The architecture diagram of the TransCrypt is shown in Figure 3.1. When a new file is created by a user on a transcrypt filesystem, a random File Encryption Key (FEK) is generated. This key itself is protected by providing confidentiality through encryption with a File System Key (FSK). FSK is a per-volume secret key provided during file system mount time, known only to the filesystem administrator. The protected FEK is then further encrypted with the public key of the user to form a token, which is then stored as the file metadata. 22

33 When a user opens a file, the kernel retrieves the token from the file metadata. It then sends the token to the user s Private Key Store (PKS) for decryption through a userspace daemon, transcryptd. The token is decrypted at the PKS using the private key of the user to retrieve protected FEK. This protected key is then sent back to the kernel. The kernel recovers the FEK by decrypting this protected key. FEK is then stored in a kernel data structure and used for data encryption and decryption during file write and read operations, respectively. When a user (file owner) wishes to share a file with another user usr1, the protected FEK is acquired using the owner s token (as done during open). Then a token for usr1 is created by encrypting the blinded FEK with the public key of usr1 (as done during create). It is then stored along with the owner s token in the file metadata. 3.2 TransCrypt Implementation In the initial version of TransCrypt [25], the implementation was tightly coupled with the ext3 file system [29]. TransCrypt modified on-disk structures to store additional meta-data required for its functionality. These modifications also included changes to the userspace e2fsprogs package [10] which contains tools and libraries to work with ext3 volumes. A tight integration with ext3 file system made TransCrypt incompatible with other advanced file systems. The newer version of TransCrypt was re-architectured [18] to employ a layered architecture, with its layers being filesystem independent. It used the extended attributes support provided by the file systems 23

34 Figure 3.1: TransCrypt Architecture 24

35 for meta data storage. With this mechanism, a great deal of flexibility and code maintainability was achieved. In addition, the earlier implementation of TransCrypt [25] also modified the file I/O functionality of the kernel. Hence it had several performance and maintenance related limitations. The implementation used page cache for its operations. The direct I/O operations where page cache is bypassed, were not supported by TransCrypt. For performance reasons, some applications such as database management systems, use direct Input/Output operations frequently. The new version of TransCrypt [28] uses a layer of cryptography to achieve modularity and direct I/O support [30]. This support is based on the device-mapper infrastructure [9] of the Linux kernel. During the implementation of TransCrypt [28], modifications were carried out on the existing kernel space components as well as in userspace softwares. This following section discusses the TransCrypt implementation for Linux kernel version Kernel space Components VFS Changes The Linux kernel VFS layer was modified to incorporate transcrypt s access control methods. It mainly included token and key-management functions. Changes were also made to store and retrieve configuration parameters to and from the extended attributes of the super block (user.transcrypt.params) during mkfs and mount time respectively. 25

36 File creation semantics of transcrypt were incorporated in the open namei create() procedure. File open semantics were incorporated in the may open() procedure. Similarly, file sharing semantics of transcrypt were incorporated in the vfs setxattr() procedure in the VFS layer Configuration Manager This module in the TransCrypt implementation manages the global and per-volume user configurable parameters. It uses a configfs [2] interface to pass parameters to the kernel. The per-volume secret key of TransCrypt (FSK) is passed to the kernel via this interface. FSK is generated from the passphrase given by the administrator at the time of creating the filesystem Public Key Infrastructure (PKI) manager This module maintains an in-kernel storage of certificates for the trusted Certifying Authorities (CAs). The public key in these certificates are used to verify the user certificates. PKI manager provides support for parsing and verification of X.509 certificates by porting XySSL library to the kernel. PKI manager extended the Crypto APIs [6] provided by the Linux Kernel to allow the use of asymmetric key cryptographic operations. TransCrypt uses asymmetric key cryptographic operations for user authentication and symmetric key operations for encryption and decryption of file data. 26

37 Keyring Manager For every file opened by a user, transcrypt needs to store the FEK in memory. This is used for encryption and decryption during subsequent read and write operation on the file by the user. Linux kernel provides a keyring infrastructure [15] to store keys and search them using a key description. It provides security through permission checks during every key access or store. TransCrypt uses this keyring infrastructure to implement a new keyring named TransCrypt keyring where various FEKs are stored. The key description used in TransCrypt keyring is the inode address of the file being accessed. If the keyring does not have enough space to add new keys (FEKs), the keyring is purged by removing keys which are not used recently Communication Manager This module takes care of the communication between the transcrypt-enabled kernel and the userspace daemon, transcryptd. It interacts with transcryptd to retrieve user certificates and to get the tokens decrypted during file operations. Kernel uses netlink sockets [21] to communicate with the userspace. When a file is created on a transcrypt volume, kernel needs the public key certificate of the user to create the token. Hence, the kernel interacts with transcryptd. Transcyptd retrieves the certificate from a public repository and sends it back to the kernel. When a user opens a file, the kernel retrieves the token from the file metadata 27

38 and sends it to the user PKS via transcryptd in a secure channel. The PKS decrypts the token using the private key and sends back the result to the kernel in the same channel through transcryptd Device Mapper module (dm-transcrypt) This module incorporates a device mapper target that maps the transcrypt enabled volumes to another volume. Any further file operations will be performed on the logical volume. It implements fast bulk encryption (or decryption) at the bock layer. A virtual block device is created using the dmsetup [9] utility. This virtual device is mapped to one or more real block devices. When the user does dm-setup, dm-transcrypt will be loaded into the kernel and it registers with the Device Mapper infrastructure. Thereafter it receives notifications about any I/O performed on the logical volume to which the target is attached Userspace Programs TransCrypt uses some userspace utilities for its functioning as described here TransCrypt Daemon (transcryptd) This daemon interacts with the kernel using netlink sockets and communicates with the user PKS using TCP connections. This daemon retrieves user certificates from public repositories and sends to the kernel when needed. It also acts as a router of messages between the kernel and the user PKS. 28

39 TransCrypt Authserver (transcrypt-auth) This daemon acts as an interface to the user s PKS. The PKS can be smart card, usb drive etc. In the current implementation, transcrypt uses a file based PKS. When a request for token decryption comes to transcrypt-auth, it checks in a certtab file and retrieves the private key file. transcrypt-auth decrypts the token using the private key and sends the result back to the kernel through transcryptd TransCrypt Utilities TransCrypt uses some utilities to make administrative tasks simpler. These include two wrapper utilities (mkfs.transcrypt and mount.transcrypt) above the standard mke2fs and mount programs. mkfs.transcrypt accepts a passphrase from the administrator who creates the filesystem to derive FSK. FSK is derived using passphrase based key derivation method. The derived key is then passed to the mke2fs utility, which initializes the superblock accordingly. mount.transcrypt accepts a passphrase from the user who mounts a transcrypt volume and then computes FSK as done in mkfs.transcrypt. This key is then passed to the kernel through the configuration manager. The kernel compares this key to the one stored in the superblock and gives access only if both the hashes match. Apart from the above wrapper utilities, transcrypt also makes use of some scripts to manage user certificates and private keys. 29

40 Chapter 4 Enhancements for Modularity and Performance TransCrypt implementation was carried out by modification of a set of system calls to incorporate its access control methods. This approach presented certain drawbacks such as lack of flexibility and code maintenance in consonance with newer kernel versions. This chapter discusses the suitability of LSM framework [31] used by TransCrypt to overcome these drawbacks. Additionally, in the transcrypt implementation (version 0.2), whenever a new file is created or is being shared with another user, the kernel communicates with the userspace daemon, transcryptd to retrieve the certificate of the user. A huge performance improvement can be achieved, if the certificate are cached by the kernel. This reduces the interactions between kernel and user mode processes and therefore fewer context switches. This chapter also discusses the design and implementation of a certificate cache for TransCrypt. 30

41 4.1 TransCrypt-LSM Module TransCrypt LSM module registers a set of call back functions with kernel to implement security operations (named as transcrypt security ops). This is done by invoking the register security() API provided by the LSM framework [31] in the kernel. The functions from the list of functions in transcrypt security ops are invoked by the kernel through File System hooks implemented by the LSM. As discussed in chapter 2, LSM interface has incorporated security fields in important file system objects (super block, inode, file) and placed hooks to support fine grain access control methods at different places in the kernel code. Some of these are discussed here File open While opening a file on a transcrypt volume, the kernel needs to retrieve the token from the extended attributes of the file and needs to derive the FEK from the token. Earlier TransCrypt implementation was through modifications in may open() functions in the kernel to incorporate token acquisition and FEK retrieval as shown in the following code. int may_open(struct nameidata *nd, int acc_mode, int flag) {...other code snippets... error = vfs_permission(nd, acc_mode); if (error) return error; 31

42 #ifdef CONFIG_TRANSCRYPT /* TransCrypt modifications */ if (is_transcrypt_file(inode)) { error = transcrypt_get_and_store_fek(nd->path.dentry);...other code snippets... } #endif...other code snippets... } This patch is now restored and implemented through security inode permission() security hook present in the vfs permission() function (which is called from the may open() system call during any file open operation) inside the kernel, as shown below. int permission(struct inode *inode, int mask, struct nameidata *nd) {...other code snippets... return security_inode_permission(inode, mask, nd); /* LSM hook used by TransCrypt */ } 32

43 4.1.2 File Creation When a user creates a file under a transcrypt volume, transcrypt has to create a token for that user and add that to the extended attribute of the file. TransCrypt implementation had earlier modified the open namei create() system call to incorporate this logic as shown in the following code. static int open_namei_create(struct nameidata *nd, struct path *path, int flag, int mode) {...other code snippets... error = vfs_create(dir->d_inode, path->dentry, mode, nd);...other code snippets... nd->path.dentry = path->dentry; if (error) return error; #ifdef CONFIG_TRANSCRYPT /* TransCrypt modifications */ if (is_transcrypt_file(path->dentry->d_inode)) { error = transcrypt_init_token(path->dentry);...other code snippets... } #endif...other code snippets... } 33

44 TransCrypt requires the inode of the file to add the token to the extended attribute. The existing security hooks in the VFS create() path (security inode create() in the vfs create() function) don t have access to the valid inode of the file. Hence a new LSM hook is created (named as security inode post create()) and the transcrypt modifications are carried out through this LSM hook as shown below. int vfs_create(struct inode *dir, struct dentry *dentry, int mode, struct nameidata *nd) {...other code snippets... error = security_inode_create(dir, dentry, mode);...other code snippets... error = dir->i_op->create(dir, dentry, mode, nd); /* this is where the inode is instantiated */ if (!error) fsnotify_create(dir, dentry); if (!error) error = security_inode_post_create(dir, dentry); /* The new LSM hook added*/ } File Sharing When a file is to be shared with another user, token for the new user is created and added to the extended attribute of the file. TransCrypt implementation had modified 34

45 vfs set xattr() system call to incorporate this functionality as shown below. int vfs_setxattr(struct dentry *dentry, const char *name, const void *value, size_t size, int flags) {...other code snippets... security_inode_post_setxattr(dentry, name, value, size, flags);...other code snippets... #ifdef CONFIG_TRANSCRYPT /* TransCrypt modifications */...other code snippets... error = transcrypt_update_tokens(dentry, value, size);...other code snippets... #endif...other code snippets... } This code is now restored and an existing security inode post setxattr() hook is used that is already present in the vfs set xattr() system call as shown below. int vfs_setxattr(struct dentry *dentry, const char *name, const void *value, size_t size, int flags) {...other code snippets... security_inode_post_setxattr(dentry, name, value, size, flags); /* LSM hook used by TransCrypt */ 35

46 }...other code snippets Mount filesystem When a user mounts a transcrypt volume with an encrypt option [18], kernel should match the FSK stored in the extended attribute of the root directory of the filesystem with the one passed by the user (through dmsetup). TransCrypt implementation had modified vfs kern mount() system call to incorporate this logic as shown in the following code. struct vfsmount* vfs_kern_mount(struct file_system_type *type, int flags, const char *name, void *data) {...other code snippets... #ifdef CONFIG_TRANSCRYPT /* TransCrypt modifications */ int encrypt = 0; #endif...other code snippets... error = security_sb_copy_data(data, secdata);...other code snippets... #ifdef CONFIG_TRANSCRYPT /* TransCrypt modifications */ if (data) { /* check for -o encrypt, eat it up if it exists */ 36

47 encrypt = transcrypt_check_encrypt_option(data); } #endif...other code snippets... error = security_sb_kern_mount(mnt->mnt_sb, secdata);...other code snippets... mnt->mnt_mountpoint = mnt->mnt_root; mnt->mnt_parent = mnt; #ifdef CONFIG_TRANSCRYPT /* TransCrypt modifications */ if (encrypt) { error = transcrypt_get_volume_params(mnt);...other code snippets... } #endif...other code snippets... } The check for an encrypt option in the mount parameters is now removed and instead security sb copy data(data, secdata) security hook is used. In this hook, the parameter data contains all parameters for mount. Security sb copy data() hook implementation for TransCrypt now retrieves the encrypt option (if present) from data and copies it to the parameter, secdata. TransCrypt also needs access to the root directory of the filesystem to compare the FSK with the values provided by the dmsetup. However the existing security hook 37

48 functions available in VFS mount() (security sb kern mount()) doesn t have access to the root directory of the filesystem. Hence, a new LSM hook is created (named as security sb kern post mount()) and the TransCrypt modifications are moved into it as shown below. struct vfsmount* vfs_kern_mount(struct file_system_type *type, int flags, const char *name, void *data) {...other code snippets... error = security_sb_copy_data(data, secdata); /* LSM hook used by TransCrypt */...other code snippets... error = security_sb_kern_mount(mnt->mnt_sb, secdata);...other code snippets... mnt->mnt_mountpoint = mnt->mnt_root; mnt->mnt_parent = mnt; error = security_sb_kern_post_mount(mnt, secdata); /* LSM hook used by TransCrypt */...other code snippets... } File Delete When a file is deleted from a transcrypt volume, the FEK of the file has to be removed from the keyring structure. TransCrypt implementation had modified the 38