Another error message in current test kernel

[Stephen Smalley]

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