SELinux Bootstrap - without chroot

SELinux Bootstrap - without chroot

[Vikram Ambrose]

Without a chroot environment, How does one go about building/installing, 
well basically the entire process including the bootstrap in a self 
contained build directory?

I have been playing with refpolicy. And from what I have learned, 
refpolicy allows you to define a LOCAL_ROOT but none of the selinux 
userspace tools allow you to make use of a folder other than 
/etc/selinux as that path is hard coded in all the source files.

In essence I want to know how to build a policy and tar it up, extract 
it into a target rootfs and simply call "load_policy" to use it.

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@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: SELinux Bootstrap - without chroot

[Stephen Smalley]

On Mon, 2008-06-16 at 12:49 -0400, Vikram Ambrose wrote:
> Without a chroot environment, How does one go about building/installing, 
> well basically the entire process including the bootstrap in a self 
> contained build directory?
> 
> I have been playing with refpolicy. And from what I have learned, 
> refpolicy allows you to define a LOCAL_ROOT but none of the selinux 
> userspace tools allow you to make use of a folder other than 
> /etc/selinux as that path is hard coded in all the source files.
> 
> In essence I want to know how to build a policy and tar it up, extract 
> it into a target rootfs and simply call "load_policy" to use it.

I'm not sure LOCAL_ROOT is what you think it is; there is a DESTDIR
definition though that gets used by the Fedora policy package build.
Looks like there is even a TEST_TOOLCHAIN definition although I haven't
used that one and it would have the same problems with libsemanage
helpers that you ran into earlier.

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.

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.
2) Build monolithic policy instead of modular policy.  Then there is no
intermediate step and no use of semodule*.

You don't really want to load the policy on the build host, do you?
That's not a good idea - it will disturb the functioning of the build
host, and you still need to restart userspace to get everything into the
right domain.

-- 
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@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: SELinux Bootstrap - without chroot

[Vikram Ambrose]

Stephen Smalley wrote:
> On Mon, 2008-06-16 at 12:49 -0400, Vikram Ambrose wrote:
>   
>> Without a chroot environment, How does one go about building/installing, 
>> well basically the entire process including the bootstrap in a self 
>> contained build directory?
>>
>> I have been playing with refpolicy. And from what I have learned, 
>> refpolicy allows you to define a LOCAL_ROOT but none of the selinux 
>> userspace tools allow you to make use of a folder other than 
>> /etc/selinux as that path is hard coded in all the source files.
>>
>> In essence I want to know how to build a policy and tar it up, extract 
>> it into a target rootfs and simply call "load_policy" to use it.
>>     
>
> I'm not sure LOCAL_ROOT is what you think it is; there is a DESTDIR
> definition though that gets used by the Fedora policy package build.
> Looks like there is even a TEST_TOOLCHAIN definition although I haven't
> used that one and it would have the same problems with libsemanage
> helpers that you ran into earlier.
>   
Yes sorry, i meant to say DESTDIR
> 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?
> 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.
> 2) Build monolithic policy instead of modular policy.  Then there is no
> intermediate step and no use of semodule*.
>
>   
I would like to use a modular build.
> You don't really want to load the policy on the build host, do you?
> That's not a good idea - it will disturb the functioning of the build
> host, and you still need to restart userspace to get everything into the
> right domain.
>
>   
No I dont want to load the policy on the build host, sorry for that 
confusion.


-- 
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@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: SELinux Bootstrap - without chroot

[Stephen Smalley]

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.

-- 
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@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: SELinux Bootstrap - without chroot

[Vikram Ambrose]

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)?


-- 
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@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: SELinux Bootstrap - without chroot

[Stephen Smalley]

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.

-- 
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@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: SELinux Bootstrap - without chroot

[Vikram Ambrose]

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@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: SELinux Bootstrap - without chroot

[Stephen Smalley]

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-
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.
-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.

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.

-- 
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@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: SELinux Bootstrap - without chroot

[Vikram Ambrose]

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.
> 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!

> -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.
> 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.

-- 
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@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: SELinux Bootstrap - without chroot

[Stephen Smalley]

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@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: SELinux Bootstrap - without chroot

[Vikram Ambrose]

Stephen Smalley wrote:
> 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.
>
>   
How is that file created?
>>> -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.
>>     
>
>
>   


-- 
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@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: SELinux Bootstrap - without chroot

[Stephen Smalley]

On Tue, 2008-06-17 at 16:12 -0400, Vikram Ambrose wrote:
> Stephen Smalley wrote:
> > 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.
> >
> >   
> How is that file created?

Normally libsemanage creates it from the .pp files by combining the
individual .fc files, sorting the result based on specificity of the
regexes, then splits the result into two files, the file_contexts file
and the homedir_template.

semodule_link doesn't do that for you presently.

One option would be to just build the file_contexts config
"monolithically" i.e. make MONOLITHIC=y file_contexts.
I expect that would yield the same result as the libsemanage version.

-- 
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@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.