On Fri, 2008-02-08 at 09:54 -0500, Stephen Smalley wrote: > On Fri, 2008-02-08 at 07:42 -0700, Forrest Taylor wrote: > > I am running into a strange occurrence running RHEL5.1 with an updated > > policy (2.4.6-106.el5_1.3). By default, it runs the targeted policy. I > > install the mls and the strict policy and touch /.autorelabel. The > > first time that I boot to one of these other policies, I get a kernel > > panic, and I have to use enforcing=0. The strange thing is that I can > > then go back and forth between any policy without setting permissive > > mode--that is, I only have to set enforcing=0 the first time that I make > > a policy change, but subsequent times it is not required. Does fixfiles > > change something the first time that allows the relabel to work > > subsequent times in enforcing mode? Any thoughts? > > IIRC, RHEL5 still had separate shlib_t vs. lib_t types in the strict/mls > policies, which means that when you first switch from targeted, you > can't execute shared objects in enforcing mode until you've first > relabeled. targeted policy aliases them into a single type, and > upstream policy has done away with the distinction now as well, I > believe. > > So, on the first conversion, the xattrs get reset from lib_t to shlib_t, > then they stay that way because targeted views them as identical. AH! I knew it was something like that. I couldn't find the difference because shlib_t is a typealias to lib_t, so it always shows lib_t. Is there any way in the targeted policy to verify that it actually is shlib_t instead of lib_t? It obviously must have some difference for strict/mls to work. Thanks, Forrest
Attachment:
signature.asc
Description: This is a digitally signed message part
-- fedora-selinux-list mailing list fedora-selinux-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-selinux-list