On Tue, 2005-06-28 at 17:15 +1000, Russell Coker wrote: > I've just tried reproducing this on a P4-1.5GHz machine specifically installed > for the purpose. > > I upgraded to all the latest packages including kernel-2.6.11-1.35_FC3 and > selinux-policy-targeted-sources-1.17.30-3.13. Things worked fine. > > Until I get more detail on this (type of CPU, kernel version, etc) I'll > conclude that it was a broken configuration. That doesn't reproduce the sequence for real users, because they would have gone through a series of policy and kernel updates over time, with any potential pairing of released policies and kernels running at any given time. If you look at the diffs between successive policy updates for FC3, there are some obvious issues there. I started with 2.96 and did incremental diffs up to 3.13. Note that: - shlib_t is a type alias for lib_t in 2.96, but in 3.13, is suddenly changed to a separate type. So if you booted your kernel any policy prior to 3.13 and just did policy reload for the update to 3.13, you will have incore inodes that have already been mapped to lib_t internally that should be shlib_t, and any rules on shlib_t will no longer be applied to them. - texrel_shlib_t is a separate type in 3.2, is changed to a type alias for lib_t in 3.9, and is changed back to a separate type in 3.13. Similar issues, albeit with lesser impact. - allow rules for execmem/execmod that were added for backward compatibility in FC3 when the 2.6.11-based kernel update was released are suddenly dropped in 3.13. These were necessary because 2.6.11 lacked the checkreqprot and ppc32 compatibility code that was included in early FC4/devel kernels and ultimately upstreamed into 2.6.12, and for whatever reason, the FC3 update kernel for 2.6.11 did not include that patch, so the policy had to include those allow rules instead. However, I'm still not clear as to why FC3 users are seeing the particular denials that they are seeing (e.g. on x86, for /sbin/init, execmod to /lib/tls/libc.*), and that would be worth investigating further. -- Stephen Smalley National Security Agency
