On 10/21/2015 02:09 PM, Jeffrey Vander Stoep wrote:
FWIW we have seen the same denials on another device running a 3.18 kernel.Notice that the mounted cache filesystem is labeled cache_file, but the empty mount point directory is labeled rootfs (because it is part of the rootfs, which was unpacked from the initramfs and has no per-file labeling information). So at the point that init mounts /cache, it is mounting on rootfs, not on cache_file. I would only expect to see your denial if init or the init.rc (wrongly) did a restorecon /cache prior to mounting the cache filesystem (thereby labeling the empty mount point directory with cache_file) or if you were using an ext4 filesystem as your root, and that image was labeled at build time based on file_contexts. IIUC, the latter was the motivation for the changes that jeff cited for allowing init to mount on cache_file, but you said you aren't doing that. Init's built in mkdir command sets the selinux file context <https://android.googlesource.com/platform/system/core/+/android-6.0.0_r1/init/util.cpp#441> on the created directory. So the following lines in init.rc mkdir /cache 0770 system cache <https://android.googlesource.com/platform/system/core/+/android-6.0.0_r1/rootdir/init.rc#52> mkdir /storage 0755 root root <https://android.googlesource.com/platform/system/core/+/android-6.0.0_r1/rootdir/init.rc#7> effectively create and restorecon the new directories to cache_file and storage_file respectively. /data and /system which similarly have mkdir commands in init.rc aren't causing denials because these directories are created <https://android.googlesource.com/platform/system/core/+/android-6.0.0_r1/rootdir/Android.mk#29> in the bootimage. What happens is the mkdir command fails early because the directories already exist and returns before hitting the labeling function so they keep the original rootfs label. All that to say, it makes sense that we are seeing these denials on /cache and /storage, what doesn't make sense is why we don't seem them on N9 (or other Nexi).
Probably using ramfs for the rootfs with older kernels and using tmpfs with the newer kernels? That would explain it. ramfs does not call security_inode_init_security(), so new files don't get labeled the same way. We never had a need to support such behavior with ramfs previously since it was always just mapped to a single label and quickly replaced with the real root.
_______________________________________________ Seandroid-list mailing list [email protected] To unsubscribe, send email to [email protected]. To get help, send an email containing "help" to [email protected].
