On 04/17/2014 05:39 PM, Will Woods wrote: > Hey all. I have a few questions for you! > > * Is it OK to load policy more than once? (e.g. load new policy after > chroot/switch-root to new system) It is certainly ok to load policy any number of times. > * If so (and I'm pretty sure that's OK), are we supposed to call > selinux_init_load_policy for each switch-root, or is > selinux_mkload_policy supposed to be sufficient? As you note below, only selinux_init_load_policy() does all of the (re-)initialization required for reloading policy from a new root; selinux_mkload_policy() is only for reloading policy afterward. > * What should happen if we switch-root from a system with SELinux > enabled/permissive to one that has SELINUX=disabled? That's not a scenario we've ever considered/supported. It is not possible to disable SELinux at runtime (via /sys/fs/selinux/disable) after policy has been loaded; that's a security feature. > The problem: Currently, we try to load policy during initramfs. This > turns out to be a bad idea: nothing in initramfs is labeled, every > process ends up with kernel_t, and so files created in /run or /dev may > have the wrong labels. Yes, this can only truly work if you put the policy in the initramfs (as in Android). > So a saner plan would seem to be to let the system load policy as normal > (i.e.: do nothing during initramfs, load policy when entering real > root), then load the *new* policy when switching to upgrade.img. Where does upgrade.img live? Are you switching to the real root to get access to it initially, mounting it, and then switching to it? > But: systemd refuses to load policy more than once, for reasons that > seem unrelated to loading policy itself[2]. Yes, we only ever considered/supported the scenario of one "initial" policy load followed by subsequent reloads with an already established root. selinux_init_load_policy is actually what used to be directly in the init program code, ripped out of it and taken to libselinux. > So: maybe it would make sense to have call selinux_init_load_policy() > after *every* switch-root? Possibly, although obviously that hasn't been tested. > We can't just use selinux_mkload_policy() because (as the comment in > selinux_init_load_policy() points out) we need to do things like reset > the config and re-mount selinuxfs after a chroot. Agreed. > But it also seems like selinux_init_load_policy() assumes it will only > be called once; a later comment says: > > /* > * If we failed to disable, SELinux will still be > * effectively permissive, because no policy is loaded. > * No need to call security_setenforce(0) here. > */ > > Except: if we were enforcing in the previous root, and the new root > requests SELINUX=disabled.. then policy *is* loaded, and we *do* need > security_setenforce(0). > > So: is that just a bug, or is selinux_init_load_policy() really not > intended to be called more than once? And if that's the case, how should > I re-load config/policy/etc. after a switch-root? I guess it is a bug, but note that you cannot truly disable SELinux at this point. So while we could trivially add a security_setenforce(0) call here, and that seems harmless, SELinux won't be disabled at that point, just permissive and operating under the real root policy? In which case newly created files will be labeled in accordance with that policy, and non-permission-related SELinux failures can still occur. > Any help / suggestions / comments / questions / expert guidance is very > welcome here. > > Thanks in advance, > > -w > > [1] initramfs and upgrade.img are actually the same image in the current > implementation, but that's not really important here. Oh, in that case, why do we need to switch to the real root before switching to upgrade.img? Why can't we just switch to upgrade.img directly? > [2] The original code[3] seems to be avoiding an infinite loop: > * when systemd v12 starts, it tries to load policy > * if policy loads OK, systemd restarts > So in *that* case, yes, systemd needed to load policy *only* once. > But these days, selinux_setup() is only called at system startup and > after each switch-root, and it doesn't restart systemd. So that's not a > problem. > > [3] http://cgit.freedesktop.org/systemd/systemd/commit?id=c4dcdb9 The original init model was to load policy and then re-exec so that init would transition into the correct domain, but I think systemd (and definitely Android init) now use setcon() to switch into the correct security context directly and do not re-exec. So, yes, we likely do not need to restart systemd after policy load. _______________________________________________ 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.
