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 ?
thanks.
--
Vikram Ambrose | Linux Products Division | WindRiver Corporation
--
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.
