2 * @defgroup SLP_PG_SECURITY Security and Permissions
5 * @brief <em class="ref">Also see </em> [ @ref SecurityFW ]
6 * @defgroup CertificateManager_PG
7 * @defgroup Security_Server_PG
8 * @defgroup SecureStorage_PG
10 * @defgroup SLP_PG_SECURITY
14 <h1 class="pg">Security Requirements</h1>
16 <p>All processes MUST have least privilege to operate their own purpose. middleware daemons might run as root to satisfy their functional requirements, but there MUST BE NO application process which is running as root. In this document application represents all processes which has user interface to the end user.</p>
17 <p>Each application process should have different privileges to satisfy least privilege, therefore there should be an entity to take care of process privileges.</p>
18 <p>If an application process requires higher (system or root) privilege to provide some function, the function must be implemented in a middleware daemon and the function must be provided as an API to application</p>
19 <h2>Application Sandboxing</h2>
20 <p>All applications MUST NOT interfere each other. Interference covers killing other processes, modify or delete other application's files, overwrite or read other application process' memory area, masquerading other applications, and reading other application's sensitive files.</p>
21 <h2>Middleware Resource Protection</h2>
22 <p>All middleware resources MUST be protected by unauthorized access from applications. If the middleware is a daemon process, the process must not be interfered by applications, if the middleware is a library and the resources of the middleware are files, then the files must not be modified by unauthorized process.</p>
23 <p>The resources must be protected at the resource level, not API level because API could be easily detoured</p>
24 <h2>Privilege Escalation</h2>
25 <p>There should be no privilege escalation, but by some management and/or manufacturing reason, unpredicted privilege escalation might be necessary. In this situation the modules which require privilege escalation MUST be highly reviewed and managed by developers and security manager.</p>
26 <h1 class="pg">Security Model</h1>
27 <h2>Background Information</h2>
28 <h3>Discretionary Access Control</h3>
29 <p>Linux kernel have supported discretionary access control (DAC) from the very beginning which controls access based on user ID, group ID of a process and owner of file that the process tries to access. This access control mechanism has been evolved with the Linux system evolution, additionally, SLP is not an embedded Linux platform but a normal Linux platform, therefore SLP has full support on DAC.</p>
30 <p>In Linux all process is executed with user ID and groups, normally inherited by parent process. The processes which are executed in booting script will be executed as root user because the parent process "init" is root process. Any other user processes including user shell will be executed as an user that is logged in by the console login process. The groups that the process belongs to are also inherited by parent process, the list of group ID is assigned when the user is logged in based on "/etc/group" file. A process can be belonged more than thousand of groups (max 65,536 but I think too many groups might occur some problem).</p>
31 <p>Only root process can change user ID and groups of the process by calling setuid() and setgroups() function, so if a root process is changed user to non root, then it can never change its user ID and groups again.</p>
32 <p>There is a special feature to change user ID even the process is not owned by root user. If the executable file has setuid sticky bit, then the process will be executed as the owner of executable files. This is very important for access control because it can produce "privilege escalation" which can harm the platform security. In Linux PC, utilities such as "sudo" and "su" has this feature because these command need to change user to root or other user ID. These utilities first executed as root user and then changes to other user ID if needed.</p>
33 <p>In Linux file system, all files are labeled with security context which describes owner user ID and group ID of the file and the permission of each accessible entity which are owner, group, and others. Permissions are consisting of read, write, and execute for each entity. If accessing process's user ID is same to owner of the file to be accessed, then the owner's permission is applied, if the process has the group that is labeled on the file, then the group's permission is applied, if not, then the other's permission is applied. All these functions are implemented in Linux kernel, so you don't need anything more for the feature. By the way, root process bypasses all the permission checking, that is root process can access all files. You can refer to Linux fundamental documents for this feature.</p>
34 <p>The owner of a file can change permission of the file but, cannot change owner of the file. Only root process can change owner of the file, so if you want to change owner of a file, you have to be root.</p>
35 <h3>Mandatory Access Control</h3>
36 <p>DAC is great security feature of Linux, but sometime DAC is not sufficient to protect platform. DAC is based on user ID, group and file’s permissions, the granularity is limited to user ID level, in some way platform may need more precise access control than DAC. Mandatory Access Control (MAC) provides this security feature to give better and precise access control based on labeling and policy.</p>
37 <p>MAC was not a part of standard Linux in the beginning, but since there were several requirements, so from kernel 2.6 version, some of the MAC mechanisms have been added to main line kernel source as optional features.</p>
38 <p>MAC needs security context labeling and policy to control. Usually, all files have its security context described in extended attribute(xattr) of file system or some other places if xattr is not supported. Policy describes which subject (process) has permission to do something (operation) to some object. It doesn’t refer to owner and permission of the DAC field, just refer to security context of subject and object, and then searches allowed operations. Object can be files, directories, system calls, sockets and so on, each MAC mechanism has different set of objects.</p>
39 <p>Using MAC, even root process can be denied to access some important object and some chosen root process can be allowed. Currently there are many MAC mechanisms such as SELinux, App-Armor, SMACK, RBAC, grsecurity and so on, and each of them has different objectives and approach.</p>
40 <h2>Security Model</h2>
41 <p>Since SLP is a Linux platform, its security model is similar to other Linux platform’s security model. In SLP, DAC and MAC are used, but biggest difference is that we need user space access control such as telephony, system management and so on.</p>
42 <h3>Discretionary Access Control</h3>
43 <p>- <b><i>User ID policy for processes</i></b></p>
44 <p>All middleware daemons are running as root user ID, it's natural because daemons are executed by init process which is root process. There are a few exceptions that are not running as root even though the process is executed by init process. They are menu-screen, voice-call-daemon, and indicator. The reason is that the exceptional processes are executed by init process but they are not middleware, but applications. These special processes maybe increased at any time.</p>
45 <p>Normal applications are executed as non root user ID. To achieve application sandboxing, all applications should run as all different user IDs, but it might occur complexity to the platform, so all the inhouse applications are executed as same user, and each 3rd party application will be executed as each different user ID.</p>
46 <p><b><i>- Group ID for fine grained access control</i></b></p>
47 <p>In Linux, a single process can be owned by a single user ID, but it can be belonged to multiple group IDs (max 65,536). In current desktop Linux such as Ubuntu, they use group ID to enforce access control for shared objects, such as CD-ROM, printer, audio, and so on. In SLP, we will use group ID as same usage, but the object will be different than normal desktop Linux, such as telephony, contact, and so on.</p>
48 <p>As a result, each application will be given different group IDs based on its required privilege.</p>
49 <p><i><b>- Security context on files</b></i></p>
50 <p>For security and safety reason, basically all files in SLP owned by root as other Linux platform does, and then, non root user process cannot modify any files. The permission of normal files will be "rw-r--r--" which means only owner can modify or delete and the group member and others only can read, this is also same as other Linux platform. Lastly permission of executive files will be "rwxr-xr-x", so anybody can execute them, and also same as others.</p>
51 <p>But there are many special files to be shared and modified by non root processes for example database files and device files in dev file system. In these cases, group ID of file is used. A shared file is owned by root but belonged to proper group ID which describes the file's content or object. The permission of the file could be "rw-rw-r--" to allow the processes belonged to the group can modify the file.</p>
52 <p>There are some secret files to be protected by unauthorized read operation, then we can use same method as above but only difference will be no read permission to others, such as "rw-------", or "rw-rw----".</p>
53 <p>Finally, there will be newly created files from middleware daemons and applications. There is default umask "022" , so if the created file is from middleware daemon, then the context of the file will be "root:root rw-r--r--", which means only root can modify and other users can read the file, if an application creates a file, then context wiil be "app_user:app_user rw-r--r--", so only the application can modify the file. This is normal usage but there must be some special cases which the file should be shared within applications. But, chown command and function only works under root privilege so applications cannot change owner of created files, so only thing possible is to change permission by chmod function. But there is only one option, share to none or share to all.</p>
54 <h3>Mandatory Access Control</h3>
55 <p>Mandatory access control(MAC) is currently out of scope of the SLP because there is almost no concrete threat which could be protected by MAC. Only one possible threat is that the network access by unauthorized process when there is a connected interface is already created. The adversary can monitor network interface status and if there is a new interface created, then it can use socket directly and it's possible to send some data by the socket. It's not possible to protect only by DAC.</p>
57 <p>There are many objects in user space such as making a phone call, sending a SMS message, which are not recognizable by kernel because thses objects are implemented in a daemon process, applications will request access by IPC and the kernel cannot manage inside of IPC messages. In these cases we must have a user space trusted entity which judges and controls access to such objects, which sits between applications and middleware daemons.</p>
58 <p>To enable this, the entity must get identity of the subject application and object to be accessed, but it's not easy because some of the IPC mechanisms don't support peer's identity acquisition. For example all the dbus messages are routed by dbus daemon, so the receiver only guarantees dbus daemon sent the message, not the original sender of the message. Therefore, we have to support such mechanism to guarantee the original sender's identity to the final receiver along with reliable and secure access decision mechanism.</p>
59 <p>To enforce access control, there must be an access policy which should be stored securely and it must be reliable. In SLP we utilized group ID for this policy. All processes have their user ID and groups which are controlled by kernel, each user space object is described as a group ID and the subject process will have the group ID if the application process has corresponding group ID then the access to be allowed, if not, the access will be denied.</p>
60 <p>One more function required is that the enforcing entity needs to know other processes groups information. proc file system can be used. In proc file system, there is a file named "status", which describes various information about a process including all groups that the process belong to.</p>
61 <h1 class="pg">Implementation</h1>
62 <h2>User ID and Group ID Administration for Processes</h2>
63 <p>As described above, all the daemons will be run by root, this is natural because all the booting scripts are executed by init process which is a root process, so all the processes executed by booting scripts will be run as root automatically. But there are some exceptions. There are some processes which are executed by booting scripts but not actually daemons such as menu screen and indicator. These processes must drop their privilege to a normal user, so in the beginning of their code, they change their user ID and groups to a normal user.</p>
64 <p>All other applications will be executed by AUL (application utility library). When a new application process is requested to be executed, AUL daemon (launchpad) which is a root process receives the request, fork() and execute requested application in the child process. During this process, after forking a process, the launchpad child process changes its user ID to a corresponding user ID, changes matching groups, changes home directory, and execute the application. This is similar to su command in Linux environment.</p>
65 <p>When a new application is installed, package manager adds a new user which has same user name with package name but substituting dot '.' to underscore '_'. But this feature is currently out of scope of the SLP.</p>
66 <p>The group ID will be described as manifest permission item which described in control file of the debian package. Manifest permission items and group IDs will not correspond 1 to 1, basically one permission item will mean a set of group IDs to enable the permission, the sets might consist of 1 group ID or many group IDs. When a new application is installed, these groups will be assigned to the user ID, this could be implemented by adduser command. But this feature is currently out of scope of the SLP.</p>
67 <h2>Changing Owner, Group and Permissions for Files</h2>
68 <p>Since SLP uses debian package for the internal build system, all files which are installed by debian are automatically owned by root and their permissions set to 0644 (rw-r--r--), which means only root can modify and other processes only can read. But in the platform there are various files which should be modified by applications also, so we need to modify the ownership and permission intentionally.</p>
69 <p>The only way to do this is by using postinst script of each of the debian package. On each package if there are some files should be shared, the package developer should add a few line to postinst file to change owner ship and permission to the files. To change owner, of a file, you have to be a root, if you are using fakeroot, the chown will not be affected.</p>
projects / framework / security / security-server.git / blob