12:26 p.m.
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
1:17 p.m.
New subject: Another error message in current test kernel
On Thu, 2005-11-17 at 12:26 -0600, Randy Zagar wrote:
As it stands now, only the SELinux developers and people who are
expert
at crafting SELinux policy rules will understand this log entry.
Not to argue against improving the message, but note that this
particular error is typically aimed at exactly the people you list
above, because it only occurs upon policy changes that invalidate a
security context (or mounting of media that has files labeled with
contexts are not valid under the policy). Not typical usage. That
Steve encountered it is precisely because he was loading and unloading a
test policy.
Specifically,
What is error 22?
Again, not to argue against improving the message, but this is errno 22
aka EINVAL aka Invalid argument. Kernel convention is to return
negative errno value from functions upon errors, and the caller is
including that bit of information in the log message for completeness.
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.
errno.h is usually present.
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.
More helpful to just apply a bit more testing in this code and provide a
more contextualized message as I suggested.
Which file is inode 3761512?
find -inum
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?
find -inum will find paths to the inode for you, but the pathname is
only of limited help with that determination. The security context that
_should_ be applied should be a function of the file's security
properties, which are unknown at this point and have to be determined.
Blindly relabeling it to the default install-time security context for
that path isn't a good idea.
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.
The syscall audit messages include pathname information, and this
particular error would ultimately lead to one of those syscall audit
messages being generated (because the file will be left unlabeled, and
subsequent access attempts will fail, thereby triggering syscall audit
records on syscall exit). Further, if we change this error message to
use audit_log rather than printk, it will end up triggering a syscall
audit message as well. But at this particular point in processing, we
don't have the path information readily available, and pathnames are
_not_ objects (nor are they a reliable means of identifying objects).
Inodes are the objects, and the log messages should always at least
include their identifiers, and also include path information as
supplemental data when available.
--
Stephen Smalley
National Security Agency
6974
days inactive
6974
days old
linux-audit@lists.linux-audit.osci.io
1 comments
2 participants
participants (2)
-
Randy Zagar -
Stephen Smalley