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@xxxxxxxxxx] > > > > Sent: Thursday, July 24, 2008 8:07 PM > > > > To: Vikram Ambrose > > > > Cc: selinux@xxxxxxxxxxxxx; 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. -- This message was distributed to subscribers of the selinux mailing list. If you no longer wish to subscribe, send mail to majordomo@xxxxxxxxxxxxx with the words "unsubscribe selinux" without quotes as the message.
