Bug 180296 - inode_doinit_with_dentry: context_to_sid(unlabeled) returned 22 for dev...
inode_doinit_with_dentry: context_to_sid(unlabeled) returned 22 for dev...
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
5
All Linux
medium Severity medium
: ---
: ---
Assigned To: Dave Jones
Brian Brock
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2006-02-06 17:46 EST by Bill Nottingham
Modified: 2015-01-04 17:25 EST (History)
6 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-05-06 13:05:51 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Disable setting of security attributes on new inodes when no policy is loaded (631 bytes, patch)
2006-02-07 12:16 EST, Stephen Smalley
no flags Details | Diff

  None (edit)
Description Bill Nottingham 2006-02-06 17:46:40 EST
Description of problem:

# dmesg | grep inode
inode_doinit_with_dentry:  context_to_sid(unlabeled) returned 22 for dev=hda2
ino=2023681
inode_doinit_with_dentry:  context_to_sid(unlabeled) returned 22 for dev=hda2
ino=4634881
inode_doinit_with_dentry:  context_to_sid(unlabeled) returned 22 for dev=hda2
ino=1338241
inode_doinit_with_dentry:  context_to_sid(unlabeled) returned 22 for dev=hda2
ino=424321
inode_doinit_with_dentry:  context_to_sid(unlabeled) returned 22 for dev=hda2
ino=3329281
inode_doinit_with_dentry:  context_to_sid(unlabeled) returned 22 for dev=hda2
ino=3721101

These inodes correspond to directories like /dev, /proc, /selinux, /sys.

Version-Release number of selected component (if applicable):

2.6.15-1.1913_FC5smp

How reproducible:

Every time.

Steps to Reproduce:
1. Boot.
2. Watch dmesg.
Comment 1 Bill Nottingham 2006-02-07 11:27:11 EST
CC'ing some SELinux people.
Comment 2 Stephen Smalley 2006-02-07 11:37:02 EST
That suggests that those directories were created before any policy was loaded.
You should be able to relabel them now that you have policy loaded (after
unmounting anything from on top of them), but the question is why were they
created with SELinux enabled but no policy loaded?
Comment 3 Stephen Smalley 2006-02-07 11:49:14 EST
Possibly we should bail from selinux_inode_init_security() immediately if
!ss_initialized, returning -EOPNOTSUPP to the fs code to prevent setting of the
inode security attribute when no policy is loaded, but I think that same
behavior would have occurred prior to that change (from post_create), so I'm not
clear on why we are seeing this now?  Was there a change in the installer to
delay loading of policy (selecting SELinux at firstboot is broken, of course)?
Comment 4 Bill Nottingham 2006-02-07 11:52:40 EST
Not sure. This machine was installed on 1/30, don't recall what the state of
anaconda SELinux was on that day. I can reinstall and try to reproduce.
Comment 5 Stephen Smalley 2006-02-07 12:09:04 EST
If for some reason the directories have to be created prior to policy load, then
the installer could always go back and fix up their contexts via
setfilecon(3)->setxattr(2) afterward prior to mounting over them.
Comment 6 Bill Nottingham 2006-02-07 12:14:56 EST
Fresh install doesn't seem to show it. I guess this can be closed as a transient
installer bug.
Comment 7 Stephen Smalley 2006-02-07 12:16:26 EST
Created attachment 124327 [details]
Disable setting of security attributes on new inodes when no policy is loaded

Possible kernel patch to prevent setting of security attributes on new inodes
when no policy is loaded.  This would prevent the 'unlabeled' tag from being
set on these directories when they are created, leaving them with no selinux
attribute at all.  Then, SELinux would subsequently map them to the context
associated with the file SID once policy is loaded (-> file_t, which is valid).
 James?
Comment 8 Bill Nottingham 2006-02-07 12:17:29 EST
(reopening for kernel patch comments)
Comment 9 James Morris 2006-02-07 12:38:16 EST
(In reply to comment #7)

I'm really not sure on this.
Comment 10 Stephen Smalley 2006-02-14 15:05:21 EST
Any specific concerns?  Patch merely changes inode_init_security logic so that
the kernel doesn't set any xattr value on new inodes when no policy is loaded. 
Userspace can still explicitly set xattrs via setxattr(2), so e.g. rpm et al can
still label the filesystem if desired, but there seems to be no point (and a
problem) in having the kernel assign security labels on-disk when no policy has
been loaded.
Comment 11 James Morris 2006-02-14 21:56:56 EST
(In reply to comment #10)
> still label the filesystem if desired, but there seems to be no point (and a
> problem) in having the kernel assign security labels on-disk when no policy has
> been loaded.

Ok, the patch should be applied then. 

Comment 12 Dave Jones 2006-02-18 18:30:13 EST
applied to cvs.
will be fixed in all kernels newer than 2.6.15-1.1967_FC5

Note You need to log in before you can comment on or make changes to this bug.