On 07/21/2014 01:50 PM, Steve Lawrence wrote: > On 07/21/2014 10:51 AM, Stephen Smalley wrote: >> 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? > > Wouldn't hurt to just create the directories we need. > >> - Why copy the entire directory structure rather than just creating the >> directories we know we will need? > > Yeah, seems unnecessary. > Sorry for the delay in getting back to these issues. Took a little time to look into. We've fixed the creation of the directory structure. It now creates the required directories rather than copying the entire directory structure. >> - 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? > > From what I can tell, I think the files in /etc/selinux/targeted are > copied over for the cases where it doesn't rebuild policies (e.g. > changes to local fcontexts, seusers, ports, etc), but needs the current > policy files for validation. We'll look into how how drastic this change > would be. This is actually not a simple fix. I think we would either need to make changes to how dbase structures work (which isn't trivial considering all the function pointers). We could alternatively add symlinks in /var/lib/selinux/tmp/targeted that point to the correct locations in /etc/selinux/targeted, and if we need to change any files in /var/lib/selinux/tmp/targeted then we delete the symlinks and write the new content. Though, this seems kindof hacky to me. Unless you have any other ideas, or the symlink seems reasonable, maybe we could hold of on this issue for now, and work on the properly solution once everything is merged? > Another thing that I think is incorrect is how file_context.local is > handle. That is stored in /etc/selinux/targeted/contexts/files, but it > seems like that should just be stored in > /var/lib/selinux/targeted/active/ just like other local modification > files, and merged into the file_contexts file. Not sure the reasoning > for keeping it separate. > >> 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? > > I think all you really need is the directory structure set up, but it > should be a pretty simple fix so even that isn't required. > This has been fixed. The integration branch now creates all the directories it needs, so nothing should need to be done to bootstrap the system. In addition to these changes, we've also fixed the name of the semodule --ignore-module-cache option (it used to be --ignore_module_cache). We have rebased the #integration branch onto github/next (fixing conflicts with the recent boolean changes). I think that fixes all the known issues, aside from the two that I think would best be dealt with after upstreaming the integration branch (the two issues being 1) copying files from /etc/selinux/targeted to /var/lib/selinux/tmp/targeted and 2) a way to delete hll files after converted to cil to save space if needed). Unless there are any more questions/concerns, perhaps it's time to start talks about merging into upstream and what needs to be done to help distributions integrate the changes? - Steve _______________________________________________ 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.
