Stephen Smalley wrote:
On Mon, 2008-07-28 at 11:59 -0400, Vikram Ambrose wrote:
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@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.
Is there a temporary work around for this? audit2* is basically the only
debug tools available for selinux n00bs.
I would think that you could just change default_level="" in the
to_string definition in class SecurityContext in refpolicy.py. Or make
it dynamically determine it based on is_selinux_mls_enabled().
You mean that in a non-MCS/MLS policy level=""?
and its fine for that function to append "" to the context (without the
":" added on) ?
--
Vikram Ambrose | Linux Products Division | WindRiver Corporation
--
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.
