FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Redhat > Fedora SELinux Support

 
 
LinkBack Thread Tools
 
Old 04-14-2008, 02:44 AM
Joe Nall
 
Default Rawhide MLS policy.22 and policy.23

I have an MLS policy.22 and policy.23 on current rawhide. The system
boots and runs policy.22. sedispol doesn't like policy.23. What
controls which policy is in use? Is 22 the correct policy to be
running today?


joe

--
fedora-selinux-list mailing list
fedora-selinux-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-selinux-list
 
Old 04-14-2008, 12:31 PM
Stephen Smalley
 
Default Rawhide MLS policy.22 and policy.23

On Sun, 2008-04-13 at 21:44 -0500, Joe Nall wrote:
> I have an MLS policy.22 and policy.23 on current rawhide. The system
> boots and runs policy.22. sedispol doesn't like policy.23. What
> controls which policy is in use? Is 22 the correct policy to be
> running today?

Known problem. The way it is supposed to work (and used to work prior
to moving initial policy load into the initrd for upstart) is that
libsemanage would always generate the latest policy version supported by
libsepol, and libselinux would always try to load the latest policy
version supported by libsepol, and libselinux could use libsepol to
downgrade that policy to one understood by the kernel as needed.

The problem now in Fedora 9 / rawhide is that initial policy load
happens from nash on the initrd, and uses the libsepol pulled into the
initrd when it was built (i.e. when the kernel was installed). Thus,
you can end up with an older libsepol on the initrd than exists on the
real root, and have a system where nash can NOT load the latest policy
generated by libsemanage.

To fix, either a) rebuild your initrd so that you have the latest
libsepol in it (this should happen automatically on next kernel
install), or b) force the libsepol on the real root to generate
policy.22 instead by putting policy-version = 22
in /etc/selinux/semanage.conf and then run semodule -B to rebuild.

setools should have been rebuilt recently to pick up the new libsepol
(it uses the static lib and has to be rebuilt for newer ones).

--
Stephen Smalley
National Security Agency

--
fedora-selinux-list mailing list
fedora-selinux-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-selinux-list
 
Old 04-14-2008, 06:18 PM
Stephen Smalley
 
Default Rawhide MLS policy.22 and policy.23

On Mon, 2008-04-14 at 08:31 -0400, Stephen Smalley wrote:
> On Sun, 2008-04-13 at 21:44 -0500, Joe Nall wrote:
> > I have an MLS policy.22 and policy.23 on current rawhide. The system
> > boots and runs policy.22. sedispol doesn't like policy.23. What
> > controls which policy is in use? Is 22 the correct policy to be
> > running today?
>
> Known problem. The way it is supposed to work (and used to work prior
> to moving initial policy load into the initrd for upstart) is that
> libsemanage would always generate the latest policy version supported by
> libsepol, and libselinux would always try to load the latest policy
> version supported by libsepol, and libselinux could use libsepol to
> downgrade that policy to one understood by the kernel as needed.
>
> The problem now in Fedora 9 / rawhide is that initial policy load
> happens from nash on the initrd, and uses the libsepol pulled into the
> initrd when it was built (i.e. when the kernel was installed). Thus,
> you can end up with an older libsepol on the initrd than exists on the
> real root, and have a system where nash can NOT load the latest policy
> generated by libsemanage.
>
> To fix, either a) rebuild your initrd so that you have the latest
> libsepol in it (this should happen automatically on next kernel
> install), or b) force the libsepol on the real root to generate
> policy.22 instead by putting policy-version = 22
> in /etc/selinux/semanage.conf and then run semodule -B to rebuild.
>
> setools should have been rebuilt recently to pick up the new libsepol
> (it uses the static lib and has to be rebuilt for newer ones).

Oops, sedispol comes from checkpolicy, not setools. And it doesn't look
like checkpolicy has been rebuilt for the newer libsepol (checkpolicy -V
only reports version 22). Dan?

--
Stephen Smalley
National Security Agency

--
fedora-selinux-list mailing list
fedora-selinux-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-selinux-list
 

Thread Tools




All times are GMT. The time now is 03:15 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org