SELinux: fix an issue about "context_to_sid returned 12"
前方用户提了个故障说手机发热低电下重启后发现有SD掉卡提示，Android_N/Kernel_3.18，离线日志找了半天，logcat日志里发现：
434 439 E vold : Failed to pclose /system/bin/sgdisk --android-dump /dev/block/vold/disk:179:64 : Success
434 439 W vold : disk:179:64 has unknown partition table; trying entire device代码在system/vold/Disk.cpp：
status_t Disk::readPartitions() {
...
// Ugly last ditch effort, treat entire disk as partition
if (table == Table::kUnknown || !foundParts) {
LOG(WARNING) << mId << " has unknown partition table; trying entire device";
std::string fsType;
std::string unused;
if (ReadMetadataUntrusted(mDevPath, fsType, unused, unused) == OK) {
createPublicVolume(mDevice);
} else {
LOG(WARNING) << mId << " failed to identify, giving up";
}
}
}这个函数往上再看看：
status_t Disk::readPartitions() {
...
// Parse partition table
std::vector<std::string> cmd;
cmd.push_back(kSgdiskPath);
cmd.push_back("--android-dump");
cmd.push_back(mDevPath);
std::vector<std::string> output;
LOG(WARNING) << "ForkExe before";
status_t res = ForkExecvp(cmd, output);
if (res != OK) {
LOG(WARNING) << "sgdisk failed to scan " << mDevPath;
notifyEvent(ResponseCode::DiskScanned);
mJustPartitioned = false;
return res;
}它是用sgdisk工具来分析分区表，只不过分析失败了，内核log里mmc1啥错也没有，不过有sgdisk权限出错：
[ 4.064447] SELinux: inode_doinit_with_dentry: context_to_sid(u:object_r:sgdisk_exec:s0) returned 12 for dev=dm-0 ino=666
[ 4.064656] type=1400 audit(1726218.699:6): avc: denied { execute } for pid=441 comm="sh" name="sgdisk" dev="dm-0" ino=666 scontext=u:r:vold:s0 tcontext=u:object_r:unlabeled:s0 tclass=file permissive=0怎么会有sgdisk这个错，看了下正常的log里是没有的。我决定复现看看，在尝试了多次后尽然让我复现了，和低电量就没有关系，复现以后拔出SD卡再插入仍然提示SD corrupted，dmesg多出来：
[ 459.510818] mmc1: new ultra high speed SDR25 SDHC card at address 0001
[ 459.514104] mmcblk1: mmc1:0001 SD16G 14.4 GiB
[ 459.518791] mmcblk1: p1
[ 459.545324] type=1400 audit(1515436020.539:39): avc: denied { execute } for p
id=4850 comm="sh" name="sgdisk" dev="dm-0" ino=666 scontext=u:r:vold:s0 tcontext
=u:object_r:unlabeled:s0 tclass=file permissive=0内核已经检测出来mmc1，不过sgdisk权限出错，我们再看下出错时sgdisk权限：
xxx:/ # ls -Z /system/bin/sgdisk
u:object_r:unlabeled:s0 /system/bin/sgdisksgdisk文件权限确是在system/sepolicy/file_contexts定义过的：
/system/bin/sgdisk u:object_r:sgdisk_exec:s0
/system/bin/blkid u:object_r:blkid_exec:s0
/system/bin/tzdatacheck u:object_r:tzdatacheck_exec:s0再看看其他的：
xxx:/ # ls -Z /system/bin/blkid
u:object_r:blkid_exec:s0 /system/bin/blkid
xxx:/ # ls -Z /system/bin/ | grep unlabel
u:object_r:unlabeled:s0 sgdisk
xxx:/ #点背，只有sgdisk有问题，file_contexts是被编译到file_contexts.bin里的，参考Android.mk:
LOCAL_MODULE := file_contexts.bin
local_fc_files := $(LOCAL_PATH)/file_contextsok, sgdisk为什么没有权限明明已经定义，注意前面还有个内核态错误：
[ 4.064447] SELinux: inode_doinit_with_dentry: context_to_sid(u:object_r:sgdisk_exec:s0) returned 12 for dev=dm-0 ino=666这是什么意思？暂且不管，我们先跟下代码在security/selinux/hooks.c：
1271 /* The inode's security attributes must be initialized before first use. */
1272 static int inode_doinit_with_dentry(struct inode *inode, struct dentry *opt_dentry)
1273 {
...
1377 } else {
1378 rc = security_context_to_sid_default(context, rc, &sid,
1379 sbsec->def_sid,
1380 GFP_NOFS);
1381 if (rc) {
1382 char *dev = inode->i_sb->s_id;
1383 unsigned long ino = inode->i_ino;
1384
1385 if (rc == -EINVAL) {
1386 if (printk_ratelimit())
1387 printk(KERN_NOTICE "SELinux: inode=%lu on dev=%s was found to have an invalid "
1388 "context=%s. This indicates you may need to relabel the inode or the "
1389 "filesystem in question.\n", ino, dev, context);
1390 } else {
1391 printk(KERN_WARNING "SELinux: %s: context_to_sid(%s) "
1392 "returned %d for dev=%s ino=%ld\n",
1393 __func__, context, -rc, dev, ino);
1394 }
1395 kfree(context);
1396 /* Leave with the unlabeled SID */
1397 rc = 0;
1398 break;
1399 }
1400 }
1401 kfree(context);
1402 isec->sid = sid;
1403 break;1391行出错，continue to track:
1486 /**
1487 * security_context_to_sid_default - Obtain a SID for a given security context,
1488 * falling back to specified default if needed.
1489 *
1490 * @scontext: security context
1491 * @scontext_len: length in bytes
1492 * @sid: security identifier, SID
1493 * @def_sid: default SID to assign on error
1494 *
1495 * Obtains a SID associated with the security context that
1496 * has the string representation specified by @scontext.
1497 * The default SID is passed to the MLS layer to be used to allow
1498 * kernel labeling of the MLS field if the MLS field is not present
1499 * (for upgrading to MLS without full relabel).
1500 * Implicitly forces adding of the context even if it cannot be mapped yet.
1501 * Returns -%EINVAL if the context is invalid, -%ENOMEM if insufficient
1502 * memory is available, or 0 on success.
1503 */
1504 int security_context_to_sid_default(const char *scontext, u32 scontext_len,
1505 u32 *sid, u32 def_sid, gfp_t gfp_flags)
1506 {
1507 return security_context_to_sid_core(scontext, scontext_len,
1508 sid, def_sid, gfp_flags, 1);
1509 }读下注释，return就是三个：0, -EINVAL, -ENOMEM。ENOMEM刚好是12。啥，insufficient memory？ ENOMEM太多了，加了打印最后发现是在security/selinux/ss/sidtab.c:
198 int sidtab_context_to_sid(struct sidtab *s,
199 struct context *context,
200 u32 *out_sid)
201 {
...
206 *out_sid = SECSID_NULL;
207
208 sid = sidtab_search_cache(s, context);
209 if (!sid)
210 sid = sidtab_search_context(s, context);
211 if (!sid) {
212 spin_lock_irqsave(&s->lock, flags);
213 /* Rescan now that we hold the lock. */
214 sid = sidtab_search_context(s, context);
215 if (sid){
216 goto unlock_out;
217 }
218 /* No SID exists for the context. Allocate a new one. */
219 if (s->next_sid == UINT_MAX || s->shutdown) {
220 ret = -ENOMEM;
221 printk(KERN_INFO
222 "SELinux: next_sid=%d, shutdown=%d ret=%d.\n",
223 s->next_sid, s->shutdown, ret);
224 goto unlock_out;
225 }
226 sid = s->next_sid++;
227 if (context->len)
228 printk(KERN_INFO
229 "SELinux: Context %s is not valid (left unmapped).\n",
230 context->str);
231 ret = sidtab_insert(s, sid, context);
232 if (ret)
233 s->next_sid--;
234 unlock_out:
235 spin_unlock_irqrestore(&s->lock, flags);
236 }
237
238 if (ret){
239 printk("return ret is %d\n", ret);
240 return ret;
241 }
242
243 *out_sid = sid;
244 return 0;
245 }s->shutdown = 1，这个才是关键，这个为啥是no memory？ 查看代码发现只有sidtab_shutdown会设置为1:
317 void sidtab_shutdown(struct sidtab *s)
318 {
319 unsigned long flags;
320
321 spin_lock_irqsave(&s->lock, flags);
322 s->shutdown = 1;
323 spin_unlock_irqrestore(&s->lock, flags);
324 }那我们看下sidtab_shutdown call stack:
sel_write_load -> security_load_policy -> sidtab_shutdownstatic const struct file_operations sel_load_ops = {
.write = sel_write_load,
.llseek = generic_file_llseek,
};可以看出来sel_write_load应该是由app通过write接口触发的，具体是在external/libselinux, call stack：
selinux_android_load_policy -> selinux_android_load_policy_helper -> security_load_policy -> write( "%s/load"在它的上面init在call:
init main -> selinux_initialize -> selinux_android_load_policy(in kernel_domain)回过头来再细看下kernel的security_load_policy：
sel_write_load :
|-> copy_from_user
|-> security_load_policy
|-> policydb_read -> avtab_read -> avtab_alloc : print "SELinux: %d avtab hash slots, %d rules"
|-> sidtab_shutdown (set shutdown=1)
|-> sidtab_set (set shudown=0)
|-> print "policy loaded"也就说在vold执行sgdisk时，因为shutdown=1导致内核selinux报错，我们再看下报错log:
[ 4.064447] SELinux: inode_doinit_with_dentry: context_to_sid(u:object_r:sgdisk_exec:s0) returned 12 for dev=dm-0 ino=666这里的sgdisk的context应该已经识别到了，就是sgdisk_exec，只不过在内核处理to sid时出错了，导致最终写到内核失败。
sgdisk的权限在file_contexts.bin里，可以看下logcat:
01-07 12:08:33.715 1860 1860 I auditd : type=1400 audit(0.0:19): avc: denied { execute } for comm="sh" name="sgdisk" dev="dm-0" ino=666 scontext=u:r:vold:s0 tcontext=u:object_r:unlabeled:s0 tclass=file permissive=0
01-07 12:08:31.346 1459 1613 I SELinux : SELinux: Loaded file_contexts contexts from /file_contexts.bin.能看到，在12:08:31.346时file_contexts.bin已经loaded了，而权限报错是在2s后发生的，所以和load file_contexts时间无关，问题就是shutdown=1为什么会抛出来。
我在shutdown的地方加些打印，发现security_load_policy走了2遍，一是在init first stage，一个是在init second stage，first stage是load的/sepolicy文件，second stage是load的/sepolicy_B。
从加的打印能看出来，在load sepolicy_B流程中shutdown=1后面会shutdown=0,而vold刚好踩在这个中间，这也证明了为啥偶尔会出现这个问题：
[ 4.090567] SELinux: Class can_socket not defined in policy.
[ 4.090574] SELinux: the above unknown classes and permissions will be denied
[ 4.090579] shutdown=1 in sidtab_shutdown
[ 4.091293] SELinux: next_sid=294, shutdown=1 ret=-12.
[ 4.091305] SELinux: inode_doinit_with_dentry: context_to_sid(u:object_r:sgdisk_exec:s0) returned 12 for dev=dm-0 ino=666
[ 4.091391] shutdown=0 in sidtab_set
[ 4.091491] type=1400 audit(4328788.739:6): avc: denied { execute } for pid=444 comm="sh" name="sgdisk" dev="dm-0" ino=666 scontext=u:r:vold:s0 tcontext=u:object_r:unlabeled:s0 tclass=file permissive=0
[ 4.147648] type=1403 audit(4328788.789:7): policy loaded auid=4294967295 ses=4294967295sepolicy_B是我们自己添加的，原生流程只有sepolicy是在kernel domain完成。是不是有问题？带着这个问题我们重看下init main：
static void selinux_initialize(bool in_kernel_domain) {
Timer t;
selinux_callback cb;
cb.func_log = selinux_klog_callback;
selinux_set_callback(SELINUX_CB_LOG, cb);
cb.func_audit = audit_callback;
selinux_set_callback(SELINUX_CB_AUDIT, cb);
if (in_kernel_domain) {
ERROR("Loading SELinux policy...\n");
if (selinux_android_load_policy() < 0) {
ERROR("failed to load policy: %s\n", strerror(errno));
security_failure();
}
bool kernel_enforcing = (security_getenforce() == 1);
bool is_enforcing = selinux_is_enforcing();
if (kernel_enforcing != is_enforcing) {
if (security_setenforce(is_enforcing)) {
ERROR("security_setenforce(%s) failed: %s\n",
is_enforcing ? "true" : "false", strerror(errno));
security_failure();
}
}
if (write_file("/sys/fs/selinux/checkreqprot", "0") == -1) {
security_failure();
}
NOTICE("(Initializing SELinux %s took %.2fs.)\n",
is_enforcing ? "enforcing" : "non-enforcing", t.duration());
} else {
ERROR("init all handles...\n");
selinux_init_all_handles();
}
}
int main(int argc, char** argv) {
...
NOTICE("init %s started!\n", is_first_stage ? "first stage" : "second stage");
...
// Set up SELinux, including loading the SELinux policy if we're in the kernel domain.
selinux_initialize(is_first_stage);
} 也就是selinux的初始化分两部分，一在first stage完成sepolicy加载，二是second stage会load file_contexts.bin等，这是本来的流程。而我们在second stage又添加了一个sepolicy加载，这个会把内核的load policy在用户态再走一边，比如shutdown=1就会干扰用户态执行权限，应该是错误的，那我去掉这个sepolicy_B，测了多遍，故障消失:]
把这个sepolicy_B放到first stage加载应该也能解决问题，没测了。
本站采用CC BY-NC-SA 4.0进行许可 | 转载请注明原文链接 - SELinux: fix an issue about "context_to_sid returned 12"
