On 07/21/2014 10:34 AM, Steve Lawrence wrote: > On 07/18/2014 02:10 PM, Stephen Smalley wrote: >> On 07/18/2014 12:00 PM, Steve Lawrence wrote: >>> On 07/10/2014 02:51 AM, Dominick Grift wrote: >>>> On Wed, 2014-07-09 at 15:21 -0400, Steve Lawrence wrote: >>>>> In January, we sent an RFC [1] to update userspace to integrate CIL >>>>> [2] and source policy. And in April, we sent an updated RFC [3] which >>>>> added support for high level languages and a tool to convert policy >>>>> package (pp) files to CIL. After getting some good feedback, we have >>>>> made some more changes, mostly to maintain ABI compatibility. The >>>>> major changes made since the last patchset are: >>>> >>>> <snip> >>>> >>>> >>>> After associating user john with staff_u, johns home directory is >>>> properly labeled (staff_u associated with /home/john). However, what is >>>> strange here is that i cannot see staff_u home dir context specs >>>> in /var/lib/selinux/targeted/active/modules/file_contexts.homedirs >>>> >>>> Am i looking in the wrong place? How does SELinux know that staff_u >>>> needs to be associated with /home/john >>>> >>> >>> In the current upatream, file_contexts.homedirs is autogenerated and >>> created in /etc/selinux/targeted/modules/active/ before it is copied to >>> /etc/selinux/targeted/contexts/files. This file is not removed from the >>> store, so it actually exists in two places. >>> >>> However, with the new source policy work, file_contexts.homedirs is >>> generated in a temporary sandbox (not the policy store). The contents of >>> the sandbox are copied to /etc/selinux, and then deleted at the end of >>> the transaction. So the new source policy infrastructure no longer >>> stores intermediate/final build files in the policy store. >>> >>> However, the migration script copies all the files from the old store to >>> the new store, even including autogenerated files that the new source >>> policy infrastructure will never look at or touch. This is just a bug in >>> the migration script. We've updated the migration script to only migrate >>> the files that actually need to be migrated (mostly *.local files). This >>> has been rebased/pushed to github #integration branch. >> >> If I run semanage_migrate_etc_to_var.py -n on a clean (no >> /var/lib/selinux at all) system, the /var/lib/selinux/targeted/active >> directory contains a homedir_template and a netfilter_contexts file in >> addition to the modules (and commit_num). The first file is >> automatically extracted from all of the file contexts during build and >> the second is unused these days. If I then run semodule -B (or omit the >> -n option on migration), I further have file_contexts.template and >> users_extra files under active, both of which are also generated. I can >> delete all four files and regenerate all but netfilter_contexts via >> semodule -B. >> > > This has been fixed. Just needed to remove a couple more paths from the > migration script and add a couple of unlink()'s in direct_commit(). Thanks. I had a question though about the approach being used in the new libsemanage for populating /var/lib/selinux/tmp/targeted initially (not to be confused with /var/lib/selinux/targeted/tmp, which frankly I do find rather confusing even though I understand it now). libsemanage copies the entire /etc/selinux/targeted directory layout (but not all the files) under /var/lib/selinux/tmp/targeted, even directories that it will never use (including e.g. the old modules directory), and then copies the files it manages from /etc/selinux/targeted to the corresponding /var/lib/selinux/tmp/targeted location before generating the new policy. This raises a few questions in my mind: - Is it a good idea to depend on an already existing and populated /etc/selinux/targeted directory tree? - Why copy the entire directory structure rather than just creating the directories we know we will need? - What exactly is the dependency here? If there is a mismatch between the built files in /etc/selinux/targeted and the /var/lib/selinux/targeted/active tree, can bad things happen? Is libsemanage depending on those prebuilt files being identical to what would be generated if it did a rebuild from /var/lib/selinux/targeted/active? If not, why does it need them at all? It looks to me as if possibly the old libsemanage relied on having policy.kern locally available in the sandbox, then RH switched it to a symlink to the installed file (wrongly, I think, as this would seemingly break a revert to prior policy), and this made it also depend on the installed policy file. And it appears to assume that the directory structure at least already exists under /etc/selinux/targeted. But this seems to take it a step further. How do I bootstrap a policy install with no prior /etc/selinux/targeted directory? _______________________________________________ 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.
