Hi Stephen, Thanks very much for your feedback.
One possible issue in your approach may be the explosion of labels and contexts. In Android, every app may use the service of keystore daemon, and apps may request to generate many key files. Also, we do not know how many apps may be installed into your device and how many key files will generated by each app. Can SEAndroid dynamically add a new key file label to the access policy for one app's context? According to your approach, SEAndroid should manage a mapping from each app to its child keystore process context. When an app sends different requests for keystore, the child process should be switched to the same context. In this point, my approach can be better. 2015-03-30 8:28 GMT-04:00 Stephen Smalley <[email protected]>: > On 03/30/2015 07:52 AM, Stephen Smalley wrote: > > On 03/29/2015 10:05 PM, Cong Zheng wrote: > >> Hi guys, > >> > >> We recently redesigned the keystore daemon with "seccomp" mode for > >> providing a stronger data isolation protection. This new keystore daemon > >> can strictly prevent malicious apps from accessing other apps' data > >> (like key pairs) stored in keystore by exploiting keystore > vulnerabilities. > >> > >> We hope anyone who may be interested in this project can have a look and > >> give us feedback. Thanks very much! > >> > >> https://github.com/shellcong/seccomp_keystore > >> <https://github.com/shellcong/seccomp_keystore> > >> > >> > >> 1. OVERVIEW > >> > >> In recent years, a lot of vulnerabilities in Android native daemons have > >> been revealed in AOSP, not to mention OEM customized daemons. A stack > >> buffer overflow vulnerability (CVE-2014-3100) was found in keystore > >> daemon before 4.4 version last year. This vulnerability could be > >> exploited for the arbitrary code execution after bypass the DEP, ASLR > >> and stack cookie. Due to the serious fragmentation problem of Android, > >> there are still many old devices under the threat of this vulnerability > >> now, and more vulnerabilities in Android native daemons will be revealed > >> in the future, especially for OEM daemons. Currently, we are only > >> focusing on the keystore daemon, and will expand it to other vulnerable > >> daemons in the future. > >> > >> The threat model: One vulnerability exists in keystore and attackers can > >> exploit this vulnerability to execute arbitrary codes after bypassing > >> the DEP, ASLR and stack cookie protection. Let's see this legitimate app > >> (uid:10053), which sends a request to keystore for generating a key pair > >> (alias: a). The keys are stored in the path > >> "/data/misc/keystore/user_0/10053_USRCERT_a" and > >> "/data/misc/keystore/user_0/10053_USRPKEY_a" (the permission are > >> "-rw------- keystore keystore" ). Now, attackers can easily write a > >> malicious app, which can send a malformed or overflowed request message > >> to keystore to trigger that vulnerability and execute malicious codes. > >> Then, the malicious app can read the 10053_USRCERT_a key file. In fact, > >> this malicious app is not allowed to read this key file according to the > >> current data isolation mechanism in keystore daemon. But, this mechanism > >> will be nothing once attackers can trigger keystore's vulnerabilities. > >> > >> Even though SEAndroid is applied into Android after version 4.4, the > >> above attack can still not be prevented by SEAndroid. In SEAndroid, > >> each file and process are labeled, and the file operation is restricted > >> by policies. Obviously, the keystore process is allowed to > >> create/read/write all key files in the "/data/misc/keystore/" directory > >> for each app in SEAndroid policies, even when keystore process has been > >> compromised. The SEAndroid cannot dynamically adjust policies to > >> restrict file operations on different files according to different > >> requested apps. So, this attack can bypass the defense of SEAndroid. > >> > >> We propose a new design for keystore daemon, whose capabilities will be > >> restricted strictly by the seccomp mode. For each service request for > >> keystore daemon, we fork a new keystore process. Before the new keystore > >> process executes, the seccomp is enabled to prohibit the "open" system > >> call. So, the new keystore process can only read and write > >> already-opened file descriptors, which are created in the dispatcher > >> process. The dispatcher checks the requesting app when it opens key > >> files. In this defense, even if keystore can be exploited, it can not > >> read or write other apps' data for the current app. > > > > Why not have the child process call the libselinux setcon() call to > > switch to a more restrictive SELinux domain that lacks open permission? > > Also, a more general architecture would be to label the individual key > files based on the security context of the client that created them, and > have the child process setcon() to a context derived from that of the > client. Then you wouldn't necessarily have to take away open altogether > but could simply control which files could be opened by the child via > policy. This however might not achieve your desired granularity since > we are not doing per-app unique labels. > > -- You received this message because you are subscribed to the Google Groups "Android Security Discussions" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/android-security-discuss. For more options, visit https://groups.google.com/d/optout.
