From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <5416D791.7090902@tresys.com> Date: Mon, 15 Sep 2014 08:12:01 -0400 From: Steve Lawrence MIME-Version: 1.0 To: Sven Vermeulen Subject: Re: SELinux Userspace Release: 20140826-rc1 References: <53FCA845.1030001@tresys.com> <20140827150608.GA6701@siphos.be> <53FE02E5.6080506@tresys.com> <53FF8DE9.6070302@tycho.nsa.gov> <54006DD4.6040706@tycho.nsa.gov> <54007889.90706@tresys.com> <54008AC4.6080600@tycho.nsa.gov> <54008C93.5060300@tresys.com> In-Reply-To: Content-Type: text/plain; charset="utf-8" Cc: Stephen Smalley , SELinux List-Id: "Security-Enhanced Linux \(SELinux\) mailing list" List-Post: List-Help: We will definitely push out an rc3. We have some fixes in the CIL and userspace repos that we just need to finalize and clean up. We should have an rc3 out this week. Thanks, - Steve On 09/14/2014 05:31 AM, Sven Vermeulen wrote: > Hi Steve & co > > Will you be pushing out an rc3 release? If not, can I get the fix for > this particular situation so I can continue testing? > > Wkr, > Sven Vermeulen > > On Fri, Aug 29, 2014 at 4:22 PM, Steve Lawrence wrote: >> On 08/29/2014 10:14 AM, Stephen Smalley wrote: >>> On 08/29/2014 10:00 AM, Sven Vermeulen wrote: >>>> On Fri, Aug 29, 2014 at 2:56 PM, Steve Lawrence wrote: >>>>>>>>> Segmentation fault >>>>>>> [...] >>>>>>>> Can you provide a copy of your original policy prior to conversion? >>>>>>> >>>>>>> If you mean the policy.29 file, certainly. You can wget it from >>>>>>> http://dev.gentoo.org/~swift/tmp/20140828-policy.29 >>>>>> >>>>>> No, the contents of /etc/selinux/mcs. The migration script converts the >>>>>> old policy module store, not the final kernel policy file. >>>>>> >>>>> >>>>> Hmm, I'm unable to reproduce this. I think the policy store that Stephen >>>>> mentions will be help to reproduce it. >>>>> >>>> >>>> Certainly. >>>> >>>> The policy store can be found at >>>> http://dev.gentoo.org/~swift/tmp/20140829-etc-selinux-mcs.tar.gz >>> >>> Hmm...semanage_migrate_store worked for me on that policy store. >>> >>> Can you reproduce the fault? If so, can you get debug info? >>> Build with debug flags and run semanage_migrate_store under valgrind, >>> perhaps? >>> >> >> We are able to get the segfault and have gotten a backtrace. It looks >> like it has to do with how optionals are handled and how we reset state >> when an optional is disabled. The fix in this particular case is pretty >> simple, but I think we need to go through the rest of the reset state >> code and ensure we aren't making similar mistakes. Might take a little >> bit of time. >>