Re: Another error message in current test kernel
On Thu, 2005-11-17 at 09:03:58 -0500 sds(a)tycho.nsa.gov wrote:
Message: 5
Date: Thu, 17 Nov 2005 09:03:58 -0500
From: Stephen Smalley <sds(a)tycho.nsa.gov>
Subject: Re: Another error message in current test kernel
To: Steve Grubb <sgrubb(a)redhat.com>
Cc: Linux Audit Discussion <linux-audit(a)redhat.com>
Message-ID: <1132236238.17726.20.camel(a)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(a)arlut.utexas.edu Applied Research Laboratories
Phone: 512 835-3131 Univ. of Texas at Austin
Attachments:
- signature.asc (application/pgp-signature — 189 bytes)