Policy source and initial ramdisk

Policy source and initial ramdisk

[Karl MacMillan]

It appears that users are required to call mkinitrd whenever the policy
is modified. If this is the case it seems that users might be unaware
that make install /etc/security/selinux/src/policy doesn't change the
policy loaded during the next boot. Additionally, it is problematic for
tools that modify the policy source. The quickest solution would be to
modify the install target to call mkinitrd, but this has some issues
(like reliably determining the name of the ramdisk image). Does anyone
have any thoughts about the best way to approach this problem?

Karl
-- 
Karl MacMillan
Tresys Technology
kmacmillan@tresys.com
(410)290-1411x134


--
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: Policy source and initial ramdisk

[Diyab]

Karl MacMillan wrote:
> It appears that users are required to call mkinitrd whenever the policy
> is modified. If this is the case it seems that users might be unaware
> that make install /etc/security/selinux/src/policy doesn't change the
> policy loaded during the next boot. Additionally, it is problematic for
> tools that modify the policy source. The quickest solution would be to
> modify the install target to call mkinitrd, but this has some issues
> (like reliably determining the name of the ramdisk image). Does anyone
> have any thoughts about the best way to approach this problem?
> 
> Karl

I think everything needed to make the initrd should be in with the 
policy source directory.

1) It will eliminate problems with distribution differences.

2) Since the initrd is required the user should have everything he/she 
needs when the selinux archives are downloaded.

3) We can set a standard initrd image name and note it in the README.

The user can still make a different initrd with different contents and a 
different name etc. if they want.

Also there are distributions that don't include mkinitrd and I'm willing 
to be there are slight differences between the actual script of the 
distros that do.  Just have a selinux specific version installed into 
/usr/local/selinux/sbin with the policycore utils or something.

Timothy,

-- 
I put instant coffee in a microwave and almost went back in time.
		-- Steven Wright


--
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: Policy source and initial ramdisk

[Dale Amon]

On Tue, Sep 16, 2003 at 10:50:48PM -0400, Diyab wrote:
> Also there are distributions that don't include mkinitrd and I'm willing 
> to be there are slight differences between the actual script of the 
> distros that do.  

"Slight" is putting it mildly. You're really getting into "vendor"
dependencies here. The debian mkinitrd uses run-parts on two different
directories for instance.

This is mostly a package issue. Whether RPM or DEB there will have to be
a mkinitrd dependency. And for TGZ installs... well if you install via
tarballs you're supposed to know these things. Tarballs are for
real OS programmers :-)





--
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: Policy source and initial ramdisk

[Russell Coker]

On Wed, 17 Sep 2003 07:22, Karl MacMillan wrote:
> It appears that users are required to call mkinitrd whenever the policy
> is modified. If this is the case it seems that users might be unaware
> that make install /etc/security/selinux/src/policy doesn't change the
> policy loaded during the next boot. Additionally, it is problematic for
> tools that modify the policy source. The quickest solution would be to
> modify the install target to call mkinitrd, but this has some issues
> (like reliably determining the name of the ramdisk image). Does anyone
> have any thoughts about the best way to approach this problem?

My solution to this is to have a base policy in the initrd which defines every 
type for a file that may be accessed in the early stages of the boot process 
(up until the root fs is re-mounted read-write), and all the policy for those 
parts of the boot.

Then in the early stage of boot the real policy will be loaded from the root 
fs.

This avoids re-building an initrd every time the policy is changed (which 
incurs danger of making the maching non-bootable if there is an error and 
which is difficult in the case of updating several kernels at the same time).

I'll release some sample policy for this soon.

-- 
http://www.coker.com.au/selinux/   My NSA Security Enhanced Linux packages
http://www.coker.com.au/bonnie++/  Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/    Postal SMTP/POP benchmark
http://www.coker.com.au/~russell/  My home page


--
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: Policy source and initial ramdisk

[Stephen Smalley]

On Tue, 2003-09-16 at 17:22, Karl MacMillan wrote:
> It appears that users are required to call mkinitrd whenever the policy
> is modified. If this is the case it seems that users might be unaware
> that make install /etc/security/selinux/src/policy doesn't change the
> policy loaded during the next boot. Additionally, it is problematic for
> tools that modify the policy source. The quickest solution would be to
> modify the install target to call mkinitrd, but this has some issues
> (like reliably determining the name of the ramdisk image). Does anyone
> have any thoughts about the best way to approach this problem?

Chris PeBenito posted a patch to add an initrd target to the policy
Makefile, see
http://marc.theaimsgroup.com/?l=selinux&m=106013650824010&w=2.
Russell Coker suggested that it was better left as a distribution patch
due to differences in mkinitrd scripts.  However, it wasn't clear to me
whether the mkinitrd invocation itself is distribution-dependent.  

-- 
Stephen Smalley <sds@epoch.ncsc.mil>
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.