Operating System Modifications for User-Oriented Addressing Model

Transcription

1 Operating System Modifications for User-Oriented Addressing Model Dong Zhou and Taoyu Li Department of Electronic Engineering, Tsinghua University Tsinghua University, Beijing, , P R China zhoud@mails.tsinghua.edu.cn, overnitary@gmail.com Maoke Chen and Xing Li Network Research Center, Tsinghua University Tsinghua University, Beijing, , P R China {maoke,xing}@cernet.edu.cn Abstract In both IPv4 and IPv6, IP address is assigned to interface and shared by different users on a same host. This model of addressing is not suitable for future Internet-based computing, where user-oriented accounting, behavior tracing, multi-homing and independent port usage must be supported. Because IPv6 provides a big enough space that everyone in the world can own several addresses, it is believed that a new, user-oriented IP addressing model will appear in the near future. On the other hand, network protocol stacks in current operating systems are designed in the framework of interface-oriented addressing model. To specify a dedicated address to each individual user, the kernel must be modified so that one user can use only its own IP address, either for source or destination of a packet. Secondly, both user and IP address administration tools must contain a map from user ID to a group of address that the user having permission to apply them. Furthermore, the behavior of application programming interface must be modified in order that each user-mode network program binds address properly. Issues of compatibility and security are also discussed. 1 Introduction Current Internet addressing model is host- or interface-oriented. Both IPv4 and IPv6 protocol specifications assume that IP addresses are assigned to network interfaces [1] [2] [3]. One host may have one or more interfaces and each of them can be assigned with several different addresses. When a user in a system is sending a packet to a certain destination, any interface address of the destination can be employed, and the source address is specified with the first one (in IPv4) or following a certain set of conventions (in IPv6, as described in RFC3484 [4]). New applications and techniques raise the problem of changing the addressing model of the Internet. The Source Address Validation Architecture (SAVA) [5] aims at a new solution of global sender identification, for the purpose of both security and accounting, and accordingly requires that IP addresses can identify end users instead of interfaces that shared by several persons. The Site Multi-homing mechanism (shim6)[6] is trying to separate the two roles of the IP address: identifier and locator, in order to get the flexibility of changing service providers on demand of users. The PlanetLab system [7] opens a new computation model that multiple users share multiple personal computers over the Internet, and interface-based addressing model doesn t meet the requirement of independent port utilization for each user. Therefore, a new addressing model is needed to support user-oriented accounting, behavior tracing, multi-homing and independent port space. These needs can be easily satisfied if every user has his own address and this is possible in IPv6, which provides enough addressing capability. In this paper, focusing on the implementation of the user-oriented IPv6 addressing model, we discuss the modifications that 1

2 are needed in the Linux operating system. In the modified operating system, a user can only use the address assigned to it as either sender or receiver of IPv6 packets. Address assigned to other users can be applied only by the super-user (root) of the system. There are several strategies for realizing the modifications. It is possible to put protocol stack into user mode based on a micro-kernel, or to modify the protocol stack within kernel itself, or to utilize some hook mechanisms like netfilter or libpcap [8]. In this paper, we take the second way as the solution and design a new kernel with augmented data structures and updated network stack routines. The rest part of paper is organized as follows. The user-address mapping facilities and corresponding administration tools are designed in Section 2. Kernel and API modifications are presented in Section 3. Then, in section 4, issues of compatibility and security are also discussed, followed by the concluding remarks. In each line of the file, the first term before the semicolon indicates the uid of the user, while the term after it contains all the IP addresses the user has privilege to access, separated with comma. The sequence of the lines are sorted by the uid. A uid of an inexistent user or a user who doesn t need network access can be noted with a blank line or just excluded from the file. When the kernel starts, this configuration file is loaded into memory and stays there until the system halts. The data structure in the memory where user-ip table is stored is described in FIGURE 1. 2 User-Address Mapping The mapping from user-id space to the space of IP address is the key component in the implementation of the user-oriented addressing model. A dedicated data structure for the map must be defined. Throughout this paper, we discuss either IPv4 or IPv6 case but it is suggested that the data structures and functions are separately implemented for IPv4 and IPv6. Commonly we don t specify the v4 or v6 after the word IP unless it is really necessary. FIGURE 1: User-IP Table In Memory As showed in FIGURE 1, the mapping table is implemented with an array of chain lists. Each chain list contains all IP addresses assigned to an individual user. Each uid corresponds to a certain element in the array. The data structure can be described by the following codes: 2.1 Data Structure of User-IP Mapping Table Because it is not useful in practice to get all the users that an IP address is assigned to, the mapping from user ID to IP address is the only data structure that is necessary. The user-address mapping table contains all the IP addresses accessible for each user. In the operating system, this table is stored in a plaintext configuration file under the /etc directory. The configuration file is written in the ASCII text mode, where a set of available IP address is defined for each user ID. A typical file /etc/uamap6.conf may be written as follows ;2001:da8:200:9002:250:4ff:fe98:6291,\ 2001:da8:200:9002::a; 402;; 403;2001:da8:200:9002:250:4ff:fe98:3001; 1001;2001:250:1214:80::8ee8;... struct clip { in6_addr ip; clip* n; } clip* uatable [MAXUID]; A set of functions are defined for manipulating the global variable of uatable and the configuration file /etc/uamap6.conf. Their declarations are as follows. int addip(unsigned int uid, in6_addr* ip); int delip(unsigned int uid, in6_addr* ip); int chkip(unsigned int uid, in6_addr* ip); clip* listip(unsigned int uid); int rmusr(unsigned int uid); int tb2f(); int f2tb(); 2

3 addip() and delip() These two functions carry out the function that add or delete a certain IP address to the mapping of a certain user. They both take the uid of the user and the IP address to be added or deleted as the parameter and return 0 if success or other integer if error occur. chkip() chkip() checks if a certain IP address and a certain user have been mapped in the table. The uid of the user and the IP address are transferred as parameter. Returns 1 if the user and the address have been mapped, 0 if not, and negatives on errors. listip() listip() lists out a chain list containing all the IP address mapping with a certain user. The only parameter indicates the uid of the user. Returns the head pointer of the chain list if success, or NULL if failed. rmusr() The function rmusr() is usually called when a user is deleted from the system. This function removes all the address mapping to a certain user indicated by the parameter as uid. Returns 0 if success or negatives on errors. 2.2 User-IP Mapping Table Administration Since new configuration file has been applied, new administration programs are in demand. Some of the existing administration programs, such as userdel, must also be modified. The user-ip mapping table will be modified in several conditions, such as the first time a user want to connect to network, the time a new IP address is assigned to a user, or the time a user is removed from the system. At these time, there must be certain administration tools to maintain the mapping table. It must be assured that only the super user can modify the mapping table. When modifying user-ip mapping table, first the data structure in memory is renewed, then the new data is written back into the configuration file. To reduce the change of system administration tools, the general tools to add a new user, such as useradd program, are not modified. Instead, a specialized tool, uamap, is developed to maintain the mapping table. It can add, list, or delete each user s IP address. That means, when a new user account is created, it does not has the privilege to access any of the IP addresses until uamap is executed manually. However, when the user is deleted, its IP address table must be cleared, or the mapping table will result into chaos after new users are added. So the tool userdel must be modified to call uamap automatically before actually delete the user. Besides, when adding or deleting users, the administrator can also add or delete term from the mapping table using uamap at any necessary time. tb2f() and f2tb() These two functions preserve the synchronism between configuration file /etc/uamap6.conf and the data structure in the memory,. f2tb() reads the mapping table from configuration file out to the memory, andtb2f() writes the table back to the file. Usually, f2tb() only needs to be called once while the system starts. However, tb2f() must be called after each time when the data structure in the memory is updated by addip(), delip(), or rmusr(). Returns 0 if success or negatives on errors. With this data structure, the former functions can be preformed in a most rapid way. Most functions first locate the user s chain list of mapped IP addresses by taking uid as the tag of the array, and then carry out the work within a simple chain array. This design assures the efficiency of the system. 3 Kernel and API Modification To specify a dedicated address to each individual user, a checking approach must to be added to check if a user has the privilege to send or receive data from an address. If this address has been assigned to this user, the operation will be allowed, otherwise the request will be refused. Furthermore, if the user use IN6ADDR ANY INIT instead of specifying a certain address, we should limit the user only to use the addresses assigned to it instead of all available addresses. According to the discussion in Section 2, our data structure is efficient enough to do packagelevel checking without obviously raising time-cost. 3.1 Location of Modifications Ideally, the checking can be placed at any step between the application(application layer) and the device(physical layer). But actually, only some special 3

4 steps make sense, while the most others are not suitable. Since we want to do an IP address checking, it is impossible to place the checking under IP layer. Furthermore, in order to do a user-address mapping checking, it is necessary to know the user-id. Therefore it is unadvisable to place the checking in the TCP/IP protocol stack because in the stack it is not convenient, and sometimes impossible to get user information. For example, when an interface receives a UDP packet, the protocol stack will deal with this packet automatically, and finally put this packet in socket receive queue, waiting for socketlevel receive. In this whole process, protocol stack knows only which address this packet should be sent to, but it has no information about which user will read this packet. Therefore it is impossible to insert the checking into this process. So the checking should be higher than TCP/IP stack(transport layer). On the other hand, the checking should be under applications since we can not modify the user applications. Therefore the checking is supposed to be placed between transport layer and applications, that is, socket layer. Socket is the interface between the transport layer protocols in the TCP/IP stack and all protocols above.... All data and control functions for the TCP/IP stack pass through the socket interface. In Linux, the socket interface is the only way that applications make use of the TCP/IP suite of protocols.[9] Therefore the socket layer is an ideal place to set the modification, as in FIGURE Some Modification Details After locating the checking at socket layer, we must still consider where of the socket layer should we do this check. Since users may do different operations on a socket, to check all these operations or just part of them is a problem to consider. All possible operation on a socket is defined in the data structure of socket->proto ops as in Table 1. Type Operations Modification Needed unsigned ssize t * release bind connect socketpair accept getname poll ioctl listen shutdown setsockopt getsockopt sendmsg recvmsg mmap sendpage TABLE 1: Socket Operations Among these 16 operations, only those related to local address, including bind, connect, recvmsg and sendmsg, should be checked. The others does nothing to do with the address, so there is no need to check them recvmsg FIGURE 2: Location of Modifications When the application calls any of the read functions on an open socket, the socket layer calls the function pointed to by the recvmsg field in the prot structure. For example, for the SOCK DGRAM type sockets, the receiving function is udp recvmsg, in the file linux/net/ipv4/udp.c. This function dequeues packets from the socket s receive queue by calling the generic datagram receive queue function, skb recv datagram, and then copies packets from kernel space to user space. Therefore we can insert the checking call before the skb recv datagram, in order to prevent the user getting the packets which do not belong to him. Same modification should be made to tcp rcvmsg for SOCK STREAM type sockets. 4

5 3.2.2 bind To prevent the user binding the socket to an address which does not belong to it, the checking should be appended into the bind function. This modification does not only serve for the bind operation, but also infect the sendmsg and connect operation through autobind mechanism. On the other hand, if the user tries to bind to IN6ADDR ANY, the kernel will read from the mapping table to get the list of the addresses accessible for the user, then try to bind to these addresses instead of to all the addresses available in the host sendmsg&connect When user tries to send messege or do connect operation while current socket has not been bound to a special address, the kernel will execute autobind to bind the socket to IN6ADDR ANY. This means we can reuse the checking in bind and don t need to modify the two operations. Therefore, we need to modify the recvmsg and bind function to add the checking module. These two function are both system calls in the kernel. The API is not modified. 4 Compatibility & Security Since we just modify functions in the Linux kernel and don t change the API, most applications can work well with new kernel without any modification or re-compilation. Therefore the proposed scheme of implementation has good compatibility. Calling listip() will help an application to get the addresses assigned to a certain user, if it need these addresses as running parameters. We supposed to do checking in functions of socket layer. Network programs without involving socket communication may escape the checking mechanism and get the privilege of using addresses not assigned to it but belonging to another. In such case the checking mechanism is bypassed. This security issue is still in research. 5 Conclusions User-oriented IPv6 address architecture will be a new revolution for the next generation Internet. Implementing such an addressing model in a operating system is challenged by the issues of efficiency, compatibility and security. The proposed configuration file and kernel data structure for the user-oriented addressing model as well as the routines manipulating them are working in a way as efficient as possible. Issues of compatibility and security are briefly discussed. It is believed that realization in Linux operating systems will encourage the popularity of the user-oriented addressing architecture. References [1] DARPA Internet Program, 1981, Internet Protocol, IETF RFC 791. [2] S. Deering, and R. Hinden, 1998, Internet Protocol, Version 6 (IPv6) Specification, IETF RFC [3] R. Hinden, 1998, IP Version 6 Addressing Architecture, IETF RFC [4] R. Draves, 2003, Default Address Selection for Internet Protocol version 6 (IPv6), IETF RFC [5] Tsinghua University, 2003, Source Address Verification Architecture Framework, draft-savaframework-00, Internet-draft, Work in progress. [6] J. Abley, B. Black, and V. Gill, 2003, Goals for IPv6 Site-Multihoming Architectures, IETF RFC [7] Larry Peterson, Steve Muir, Timothy Roscoe, and Aaron Klingaman, 2006, PlanetLab Architecture: An Overview, [8] V. Jacobson and S. McCanne, libpcap: Packet capture library, ftp://ftp.ee.lbl.gov/libpcap.tar.z. [9] Thomas F Herbert, 2004, The Linux TCP/IP Stack: Networking for embedded systems, Charles River Media, ISBN: