From: Eric Paris <eparis@redhat.com>
To: selinux@tycho.nsa.gov
Cc: sds@tycho.nsa.gov,
"rhel6-cc-external-list@redhat.com >> RHEL6-CC"
<rhel6-cc-external-list@redhat.com>
Subject: mounting cgroupfs causes directory search before sb initialization
Date: Wed, 25 May 2011 15:43:44 -0400 [thread overview]
Message-ID: <4DDD5BF0.2080904@redhat.com> (raw)
Running the RHEL6 MLS policy we find that we have trouble mounting
cgroupfs with denials that look like so:
time->Wed May 25 13:24:28 2011
type=PATH msg=audit(1306347868.791:11): item=0 name="/cgroup/freezer" inode=24658 dev=fd:00 mode=040755 ouid=0 ogid=0 rdev=00:00 obj=system_u:object_r:cgroup_t:s0
type=CWD msg=audit(1306347868.791:11): cwd="/"
type=SYSCALL msg=audit(1306347868.791:11): arch=c000003e syscall=165 success=yes exit=0 a0=7f9561cb0481 a1=7f9561ebe414 a2=7f9561cb0481 a3=0 items=1 ppid=944 pid=945 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="cgconfigparser" exe="/sbin/cgconfigparser" subj=system_u:system_r:cgconfig_t:s0-s15:c0.c1023 key=(null)
type=AVC msg=audit(1306347868.791:11): avc: denied { search } for pid=945 comm="cgconfigparser" name="/" dev=cgroup ino=9436 scontext=system_u:system_r:cgconfig_t:s0-s15:c0.c1023 tcontext=system_u:object_r:unlabeled_t:s15:c0.c1023 tclass=dir
After quite a bit of code inspection I think I understand the problem (although not completely). I believe the problem is that during the get_sb() call cgroupfs creates not only the root directory inode but also creates files inside that directory. During that creation of other files (like in this case "freezer") the code does:
vfs_kern_mount()
cgroup_get_sb()
cgroup_populate_dir()
cgroup_add_files()
lookup_one_len()
alloc_dentry()
d_instantiate()
It seems to use lookup_one_len() to make sure it isn't adding
the same file twice. Now the problem is that since we are still
inside get_sb() we haven't made it to security_sb_kern_mount()
which actually initializes the superblock security struct (and the
root inode). Thus sbsec->flags & SE_SBINITIALIZED isn't set, so
the root inode will not have been initialized. Now when
lookup_on_len() tries to search the new root inode it's going to
get SECINITSID_UNLABELED.
I honestly am not sure how to fix it. I could mark the root inode
PRIVATE while get_sb() was taking place, but that wouldn't work if
they ever started creating directory structures during mount.
Maybe we can somehow force the cgroup people to do the creation of
the files inside cgroupfs root inode after the sb is initialized?
I'm just not sure how to solve it. Any ideas?
-Eric
--
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.
next reply other threads:[~2011-05-25 19:43 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-05-25 19:43 Eric Paris [this message]
2011-05-25 20:19 ` mounting cgroupfs causes directory search before sb initialization Stephen Smalley
[not found] ` <201105252221.06631.stephan.mueller@atsec.com>
2011-05-25 20:23 ` [Rhel6-cc-external-list] " Eric Paris
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4DDD5BF0.2080904@redhat.com \
--to=eparis@redhat.com \
--cc=rhel6-cc-external-list@redhat.com \
--cc=sds@tycho.nsa.gov \
--cc=selinux@tycho.nsa.gov \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.