On Tue, 2008-06-17 at 10:52 -0400, Vikram Ambrose wrote: > Stephen Smalley wrote: > > On Tue, 2008-06-17 at 09:52 -0400, Vikram Ambrose wrote: > > > >> Stephen Smalley wrote: > >> > >>> On Mon, 2008-06-16 at 17:35 -0400, Vikram Ambrose wrote: > >>> > >>> > >>>> Stephen Smalley wrote: > >>>> > >>>> > >>>>> On Mon, 2008-06-16 at 13:56 -0400, Vikram Ambrose wrote: > >>>>> > >>>>> > >>>>> > >>>>>> Stephen Smalley wrote: > >>>>>> > >>>>>> > >>>>>> > >>>>>>> Note that they get installed to $DESTDIR/usr/share/selinux/$SELINUXTYPE > >>>>>>> by make install. In Fedora, they are packaged as such, then when you > >>>>>>> install the package on the target host, they are unpacked > >>>>>>> to /usr/share/selinux/$SELINUXTYPE by the package manager and then a % > >>>>>>> post scriptlet runs semodule on them to install them under /etc/selinux > >>>>>>> and load them. > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>> In Fedora, does anaconda chroot into the sysroot and call semodule > >>>>>> during installation? > >>>>>> > >>>>>> > >>>>>> > >>>>> Some combination of anaconda and rpm, yes. semodule runs from a %post > >>>>> scriptlet in the selinux-policy-targeted package at package install > >>>>> time. > >>>>> > >>>>> > >>>>> > >>>>> > >>>>>>> Options for you might include: > >>>>>>> 1) Run semodule_link and semodule_expand at build time to link and > >>>>>>> expand the modules to a kernel policy up front. Then you can just put > >>>>>>> the files into place without running semodule later. > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>> I will investigate this option further, thank you. > >>>>>> > >>>>>> > >>>>>> > >>>>> Ok. You can see an example of it in the 'make validate' target, > >>>>> although that is just to check that they will link and expand > >>>>> successfully; it isn't used to install the policy normally and likely > >>>>> doesn't keep the final result around. > >>>>> > >>>>> > >>>>> > >>>>> > >>>> I am getting a bit confused between "modular" and "monolithic", in both > >>>> cases a policy.X file is needed to load the policy into the kernel, right? > >>>> > >>>> and in the modular case, the policy.X file simply points to the various > >>>> .pp files and in the monolithic case everything is in the policy.X file? > >>>> Analogous to shared library and static library link (modular/monolithic)? > >>>> > >>>> > >>> In either case, we ultimately need a complete policy.N file that > >>> contains all of the information for loading into the kernel. The kernel > >>> only knows about the policy.N format; it knows nothing of policy > >>> modules. > >>> > >>> The difference is whether we need to compile a complete set of policy > >>> sources directly into the policy.N file, or whether we can separately > >>> compile and package each policy module into a .pp file and then later > >>> link and expand the set of installed policy modules to create a policy.N > >>> file. > >>> > >>> The modular policy support was introduced later (first appeared in > >>> Fedora Core 5), to allow for local customization of policy without > >>> requiring complete policy sources and to enable third party policy and > >>> decomposition of distribution policy among the packages. > >>> > >>> In a monolithic policy build, you take the entire set of policy sources, > >>> apply various preprocessing steps, combine the result into a single > >>> policy.conf file, and then feed that to the checkpolicy program to > >>> generate the policy.N file for the kernel. And you likewise preprocess > >>> and combine the .fc files to form the complete file_contexts > >>> configuration. Later if you want to add more policy, you drop it into > >>> the policy source tree and repeat the entire process. > >>> > >>> In the modular policy build, you take each policy module's sources (.te > >>> file), apply various preprocessing steps, feed the result to the > >>> checkmodule program to generate a binary module (.mod) file, then feed > >>> the .mod file and the .fc file to semodule_package to generate the > >>> policy package (.pp) file. Then you ship the .pp files to the target > >>> host, run semodule to insert them into the policy module store, link > >>> them together, and expand them into a policy.N file on that host. Later > >>> if you want to add more policy, you compile it as a module separately, > >>> ship the resulting .pp file to the target host, and then run semodule on > >>> it, which will add it to the policy store and generate an updated > >>> policy.N file. > >>> > >>> > >>> > >> hmm, that somewhat explains it, but the terminology used across man > >> pages and the internet doesn't seem to be consistent so it's a bit > >> difficult to understand whats what. > >> So to avoid semodule's affinity for /etc/selinux i can get away with > >> semodule_link and semodule_expand? > >> I don't understand what the output of each command is. I did a > >> semodule_link of all my .pp files and then did a senodule_expand of that > >> file into another file, and then cat'ed that into /selinux/load and i > >> got an error about a map. > >> > >> [600793.305757] security: ebitmap: truncated map > >> > >> Also, once the policy.X file is loaded, does the system need access to > >> /etc/selinux/$POLICY ? > >> > > > > You can do that, but I'm still not clear on why you are doing it. It > > seems like you should be doing one of the following instead: > > 1) run semodule on the target system to install the .pp files and load > > the resulting policy rather than trying to do it all on the build host, > > -or- > > > Yes this works, however i'd like to have it running out of the box > without this step. Up to you, of course, but note that at least in Fedora, this happens naturally via a %post scriptlet in the selinux-policy packages and isn't fundamentally different than other %post actions performed for system setup when a package is installed. > > 2) run semodule within a chroot on the build system to install the .pp > > files and create the kernel policy. Eric Paris has been getting such > > builds to work for Fedora live CD creation. > > > I'm not a fan of the chroot environment, but now that i have learned > that i can manually semodule_link/expand to create my policy.X file, i > can do the whole operation without using /etc/, this makes > packaging/building out of the target system much easier, as well as > deployment is a simple: > 1. untar the .pp files to /usr/share/selinux/policy/ for devs to use > 2. refpolicy make install, stuff untar'ed to > /etc/selinux/policy/contexts and > 3. copy my policy.X file that was produced by link/expand (also from the > build host), to /etc/selinux/policy/policy > 4. edit semanage.conf and selinux.conf, throw in load_policy into > sysvinit and i'm done! You may also need to manually generate the file_contexts file and put it into place, as semodule_link/expand doesn't presently handle that for you. > > -or- > > 3) perform a monolithic policy build in the first place and thus avoid > > the entire indirection of modules and semodule in the first place. > > > > Also, you said you didn't want to load the policy on the build host so > > I'm not sure why you are trying to do that. The reason that it is > > failing is not that the policy is invalid but because the cat program > > writes it in fixed size chunks rather than atomically in one write call, > > and /selinux/load requires that the entire policy be fed to it in a > > single write call. The load_policy program does this by opening the > > policy file, fstat'ing it to get the size, mmap'ing it into memory, and > > then write'ing the entire memory region to /selinux/load in a single > > write() call. You can see that logic in libselinux/src/load_policy.c; > > it was once directly implemented in the load_policy program but later > > moved into the library and further encapsulated. > > > > > Yes i just found out myself too. so I used dd with a big block size and > it worked beautifully. Ok, a useful workaround to know. > > semodule_link/expand are developer tools for manually applying the link > > +expand phases, and thus will operate on whatever inputs you provide > > rather than only operating on a policy store under /etc/selinux. > > > > The kernel doesn't care where the policy originates; it is only > > userspace that has the convention that it lives under /etc/selinux. > > > > > thanks Stephen. I think I have found my solution. -- Stephen Smalley National Security Agency -- This message was distributed to subscribers of the selinux mailing list. If you no longer wish to subscribe, send mail to majordomo@xxxxxxxxxxxxx with the words "unsubscribe selinux" without quotes as the message.
