Hi Stephen/Paul,
This issue was discovered using https://android.googlesource.com/kernel/common -b android-4.9-o, but I've verified the code path exists in msm-4.4. It likely exists in other kernel versions as well.
As a privileged user, one can override the current SELinux context via a call to setfscreatecon() or by writing directly to /proc/self/attr/fscreate. The context is then used to label the next newly created file object, e.g. mknod(). Upon handling the
creation of the new object on the EXT4 FS we end up calling selinux_inode_init_security() to create a new xattr object for the inode. This will end up calling context_struct_to_string() to convert the SID back to the string version of the SELinux security
context that was stored.
static int context_struct_to_string(struct context *context, char **scontext, u32 *scontext_len)
{
char *scontextp;
if (scontext)
*scontext = NULL;
*scontext_len = 0;
if (context->len) {
*scontext_len = context->len;
if (scontext) {
*scontext = kstrdup(context->str, GFP_ATOMIC);
if (!(*scontext))
return -ENOMEM;
}
return 0;
}
scontext is populated with the context length, directly from the context structure, and using kstrdup() to copy the string. Much later down the call stack ext4_xattr_set_entry() is called with the SELinux xattr object.
if (i->value == EXT4_ZERO_XATTR_VALUE) {
memset(val, 0, size);
} else {
/* Clear the pad bytes first. */
memset(val + size - EXT4_XATTR_PAD, 0,
EXT4_XATTR_PAD);
memcpy(val, i->value, i->value_len);
}
Can you please let me know if my analysis is correct.
As per me, it looks like there is problem in the code.
Regards,
Sachin Grover
|
_______________________________________________ Selinux mailing list Selinux@xxxxxxxxxxxxx To unsubscribe, send email to Selinux-leave@xxxxxxxxxxxxx. To get help, send an email containing "help" to Selinux-request@xxxxxxxxxxxxx.