Re: new kernel patch

Re: new kernel patch

[Stephen D. Smalley]

[-- Attachment #1: Type: TEXT/plain, Size: 1404 bytes --]


> The new version seems to have a bug related to file labelling that affects
> devfs.
<snip>
> You can see the log entry below, it does not log the action, and it claims
> that there is a file named /dev/floppy which is bogus.  There can be
> no file under /dev on a devfs system so any reference to tclass=file and
> dev=00:06 means a kernel bug.  Without reading the kernel code in question
> I guess that file is the default tclass (defined to 0?).
<snip>
> avc:  denied  { } for  pid=65 exe=/sbin/devfsd path=/floppy dev=00:06 ino=527 
scontext=system_u:system_r:devfsd_t tcontext=system_u:object_r:unlabeled_t 
tclass=file

When an inode is allocated, its SID is initialized to the unlabeled
initial SID (=> system_u:object_r:unlabeled_t), and its security class
is initialized to the file class by default.  This log message indicates
that a devfs inode reached a permission check without first being
initialized by inode_doinit, likely due to a race between 
selinux_inode_post_lookup and a cached lookup.  The empty permission
set is due to an inability to map the requested permission (likely search)
to a permission in the file class.

As a short term fix, I'd suggest the attached patch.  A proper fix requires
adjusting the inode_init call in d_instantiate and the SELinux hook function
to properly handle filesystems that rely on genfs_contexts.

--
Stephen Smalley, NSA
sds@epoch.ncsc.mil

[-- Attachment #2: perminit.patch --]
[-- Type: TEXT/plain, Size: 526 bytes --]

Index: lsm-2.4/security/selinux/hooks.c
===================================================================
RCS file: /cvsroot/selinux/nsa/lsm-2.4/security/selinux/hooks.c,v
retrieving revision 1.23
diff -u -r1.23 hooks.c
--- lsm-2.4/security/selinux/hooks.c	4 Dec 2002 17:54:52 -0000	1.23
+++ lsm-2.4/security/selinux/hooks.c	16 Dec 2002 17:19:42 -0000
@@ -2033,6 +2033,8 @@
 		return 0;
 	}
 
+	inode_doinit(inode);
+
 	return inode_has_perm(current, inode, 
 			       file_mask_to_av(inode->i_mode, mask), NULL, NULL);
 }

Re: new kernel patch

[Russell Coker]

On Mon, 16 Dec 2002 19:27, Stephen D. Smalley wrote:
> When an inode is allocated, its SID is initialized to the unlabeled
> initial SID (=> system_u:object_r:unlabeled_t), and its security class
> is initialized to the file class by default.  This log message indicates
> that a devfs inode reached a permission check without first being
> initialized by inode_doinit, likely due to a race between
> selinux_inode_post_lookup and a cached lookup.  The empty permission
> set is due to an inability to map the requested permission (likely search)
> to a permission in the file class.
>
> As a short term fix, I'd suggest the attached patch.  A proper fix requires
> adjusting the inode_init call in d_instantiate and the SELinux hook
> function to properly handle filesystems that rely on genfs_contexts.

This works.  I'll add it to my kernel-patch package for Debian.

Also I've updated my kernel-patch-2.5-lsm package to include your latest 
patch.

-- 
http://www.coker.com.au/selinux/   My NSA Security Enhanced Linux packages
http://www.coker.com.au/bonnie++/  Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/    Postal SMTP/POP benchmark
http://www.coker.com.au/~russell/  My home page


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

new kernel patch

[Russell Coker]

The new version seems to have a bug related to file labelling that affects
devfs.

If I type "ls -l /dev/floppy/0" on a devfs system and the floppy.o module is
not loaded then the kernel will signal the devfsd daemon (through
/dev/.devfsd) that this has been attempted.  In a default configuration the
devfsd will then run "modprobe /dev/floppy/0" and as the modutils config has
an alias for /dev/floppy/0 to "floppy" the floppy.o device driver is loaded.

With this new kernel it appears that the labelling takes place at a different
stage such that the devfsd gets to access a device that is not fully
labelled.

You can see the log entry below, it does not log the action, and it claims
that there is a file named /dev/floppy which is bogus.  There can be
no file under /dev on a devfs system so any reference to tclass=file and
dev=00:06 means a kernel bug.  Without reading the kernel code in question
I guess that file is the default tclass (defined to 0?).

But interestingly after logging >20 of the following messages the kernel
then proceeds to assign the right type to the device nodes that have been
created and then everything goes fine.  Of course I expect this to fail
catastrophically in the case of device nodes that need my devfs shared
object to label them, but I haven't got around to testing this yet.

avc:  denied  { } for  pid=65 exe=/sbin/devfsd path=/floppy dev=00:06 ino=527 scontext=system_u:system_r:devfsd_t tcontext=system_u:object_r:unlabeled_t tclass=file



PS  The reason my system is unable to run my usual email program is due
to a conflict between unofficial Debian KDE packages that I've been using
and the new official Debian package og QT.  Just in case you were
wondering. ;)

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.