Re: [FC3] kernel panic after selinux-policy-targeted update

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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


[Index of Archives]     [Current Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Yosemite News]     [Yosemite Photos]     [KDE Users]     [Fedora Tools]     [Fedora Docs]

  Powered by Linux