Another error message in current test kernel

[Randy Zagar]

On Thu, 2005-11-17 at 09:03:58 -0500 sds at tycho.nsa.gov wrote:

> Message: 5
> Date: Thu, 17 Nov 2005 09:03:58 -0500
> From: Stephen Smalley <sds at tycho.nsa.gov>
> Subject: Re: Another error message in current test kernel
> To: Steve Grubb <sgrubb at redhat.com>
> Cc: Linux Audit Discussion <linux-audit at redhat.com>
> Message-ID: <1132236238.17726.20.camel at moss-spartans.epoch.ncsc.mil>
> Content-Type: text/plain
> 
> On Wed, 2005-11-16 at 17:12 -0500, Steve Grubb wrote:
> > On Wednesday 16 November 2005 15:04, Stephen Smalley wrote:
> > > > Nov 16 09:21:00 localhost kernel: inode_doinit_with_dentry:  
> > > > context_to_sid(root:object_r:fileop_exec_t:s0) returned 22 for dev=sda7
> > > > ino=3761512
> > >
> > > That just means that you previously had the selinux testsuite policy
> > > loaded, and then later removed it, thereby invalidating that type (and
> > > thus any incore inode labels that contained it).
> > 
> > Correct...how would a normal user know that? Is this an error, warning, or 
> > info? Does this message need to be worded more ominously? What is the fix for 
> > this?
> 
> The message could be clearer, particularly for the common case (e.g.
> SELinux:  inode %ld on dev %s has invalid security context %s, treating
> as unlabeled.)  It is presently a printk in
> hooks.c:inode_doinit_with_dentry; could be converted to using audit_log.
> There are a number of printks performed by hooks.c that are potentially
> candidates for using the audit system instead.
> 
> The fix for the reported error is to relabel the inode to a valid
> security context.  Until that happens, SELinux treats it as having the
> unlabeled context and thus makes it inaccessible to unprivileged
> confined processes.

As one of those pesky end-users who's spent the past 20 years reading
syslog entries, I have to agree with Steve that the above entry not only
fails to inspire me to take action, it fails to give me any indication
of what to do.

As it stands now, only the SELinux developers and people who are expert
at crafting SELinux policy rules will understand this log entry.

Specifically,

        What is error 22?
        
        Am I expected to read selinux.h to find out what that error code
        means?  What if I didn't install kernel development tools?  Can
        you depend on that file actually being present on the system?
        No, you can't.
        
        There is a nice little function called perror() defined in the
        standard C library that translates error codes into human.  You
        might actually consider implementing something similar, and then
        use it.
        
And

        Which file is inode 3761512?
        
        Even if I understand the error message and know I have to
        "relabel the inode to a valid security context", how will I
        determine what security context SHOULD be applied without
        knowing the filename?
        
        For instance, one of the things my systems have to do is
        generate an audit record for "unsuccessful attempts to access
        security-relevant objects" (NISPOM Chapter 8).
        
        Typically, this means catching people trying to read /etc/shadow
        or /var/log/secure.  But I also have to audit accesses to our
        antivirus software and our auditing software.
        
        I don't define security-relevant objects in terms of inodes, so
        error messages that report security policy problems in terms of
        inodes will have no meaning to me.

-RZ

-- 
Randy Zagar                               Sr. Unix Systems Administrator
E-mail: zagar at arlut.utexas.edu            Applied Research Laboratories
Phone: 512 835-3131                       Univ. of Texas at Austin

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/linux-audit/attachments/20051117/caa4d079/attachment.sig>