From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mummy.ncsc.mil (mummy.ncsc.mil [144.51.88.129]) by tarius.tycho.ncsc.mil (8.13.1/8.13.1) with ESMTP id m6SGCFPu030780 for ; Mon, 28 Jul 2008 12:12:15 -0400 Received: from mail.wrs.com (jazzhorn.ncsc.mil [144.51.5.9]) by mummy.ncsc.mil (8.12.10/8.12.10) with ESMTP id m6SGC3PO024951 for ; Mon, 28 Jul 2008 16:12:13 GMT Message-ID: <488DECEB.1090607@windriver.com> Date: Mon, 28 Jul 2008 11:59:39 -0400 From: Vikram Ambrose MIME-Version: 1.0 To: Stephen Smalley CC: Chris PeBenito , Karl MacMillan , selinux@tycho.nsa.gov, Daniel J Walsh Subject: Re: libsepol.context_from_record: MLS is disabled, but MLS context"s0" found References: <4888E754.9030504@windriver.com> <1216944435.4931.20.camel@defiant.pebenito.net> <6FE441CD9F0C0C479F2D88F959B015880246B40D@exchange.columbia.tresys.com> <1216997739.5392.14.camel@defiant.pebenito.net> <1216998548.4906.2.camel@defiant.pebenito.net> <1217032502.14295.1.camel@sulphur> In-Reply-To: <1217032502.14295.1.camel@sulphur> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Sender: owner-selinux@tycho.nsa.gov List-Id: selinux@tycho.nsa.gov Stephen Smalley wrote: > On Fri, 2008-07-25 at 11:09 -0400, Chris PeBenito wrote: > >> On Fri, 2008-07-25 at 10:55 -0400, Chris PeBenito wrote: >> >>> On Fri, 2008-07-25 at 10:30 -0400, Karl MacMillan wrote: >>> >>>>> -----Original Message----- >>>>> From: Chris PeBenito [mailto:pebenito@gentoo.org] >>>>> Sent: Thursday, July 24, 2008 8:07 PM >>>>> To: Vikram Ambrose >>>>> Cc: selinux@tycho.nsa.gov; Karl MacMillan >>>>> Subject: Re: libsepol.context_from_record: MLS is disabled, but MLS >>>>> context"s0" found >>>>> >>>>> On Thu, 2008-07-24 at 16:34 -0400, Vikram Ambrose wrote: >>>>> >>>>>> I keep getting this error with audit2why. >>>>>> >>>>>> root@localhost:/root> cat msg >>>>>> type=1400 audit(1216736766.147:35): avc: denied { read write } >>>>>> >>>>> for >>>>> >>>>>> pid=1829 comm="modprobe" name="console" dev=sda ino=344069 >>>>>> scontext=system_u:system_r:insmod_t >>>>>> tcontext=unconfined_u:object_r:default_t tclass=chr_file >>>>>> >>>>>> root@localhost:/root> audit2allow < msg #============= insmod_t >>>>>> ============== allow insmod_t default_t:chr_file { read write }; >>>>>> >>>>>> root@localhost:/root> audit2why < msg >>>>>> libsepol.context_from_record: MLS is disabled, but MLS context "s0" >>>>>> found >>>>>> libsepol.context_from_record: could not create context structure >>>>>> libsepol.context_from_string: could not create context structure >>>>>> libsepol.sepol_context_to_sid: could not convert >>>>>> system_u:system_r:insmod_t:s0 to sid Invalid Source Context >>>>>> system_u:system_r:insmod_t:s0 >>>>>> >>>>> I ran into this last week. Sepolgen incorrectly adds the MLS portion >>>>> of the context regardless if MLS is enabled or not. Then when the >>>>> tool uses the context, libsepol throws the above errors when MLS is >>>>> disabled. >>>>> I haven't had a chance to really look at what would be the right way >>>>> to fix it, since I'm no python expert. Karl? >>>>> >>>>> >>>> Maybe I'm missing something, but from above this looks like an audit2why >>>> bug not an sepolgen bug. >>>> >>> Perhaps. I didn't have a change to analyze the problem fully, so I >>> don't know if sepolgen is supposed to be informed if this is an MLS >>> policy or not, or if sepolgen itself is supposed to figure it out. In >>> the end the offending function is in the SecurityContext class in >>> sepolgen: >>> >>> def to_string(self, default_level="s0"): >>> fields = [self.user, self.role, self.type] >>> if self.level == "": >>> if default_level != "": >>> fields.append(default_level) >>> else: >>> fields.append(self.level) >>> return ":".join(fields) >>> >> To be clear, I couldn't find any example of default_level being set to >> anything when to_string() is called, so in the end it gets a level no >> matter what. >> > > Right - it shouldn't do that if is_selinux_mls_enabled() <= 0. > I think this is a result of the audit2allow / audit2why integration; > previously, audit2why was directly consuming audit messages but now it > is leveraging sepolgen. > > Is there a temporary work around for this? audit2* is basically the only debug tools available for selinux n00bs. Vikram -- This message was distributed to subscribers of the selinux mailing list. If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with the words "unsubscribe selinux" without quotes as the message.