On Thu, 2008-05-15 at 15:30 -0700, Douglas McClendon wrote:
> Stephen Smalley wrote:
> > On Thu, 2008-05-15 at 13:50 -0400, Eric Paris wrote:
> >> 3) When booting I get 3 messages that say:
> >> inode_doinit_with_dentry: no dentry for dev=dm-0 ino=8345
> >> The 3 inodes in question correspond to
> >> /etc/udev
> >> /etc/udev/rules.d
> >> /etc/udev/rules.d/50-udev-default.rules
> >
> > Happens when SELinux is setting up pre-existing inodes upon initial
> > policy load and it cannot find a dentry for the inode and thus cannot
> > invoke the ->getxattr method on it. Likely harmless. When/if the
> > files are subsequently looked up, the inodes should get set up at that
> > time upon the d_instantiate/d_splice_alias.
>
> I've seen these messages forever, though didn't realize till now that
> they were an selinux related issue. If they are truly harmless, can
> someone remove the code that spits out the message please?
I'm ok with reducing them to KERN_DEBUG. They do represent a
non-optimal aspect of the ->getxattr interface that we were hoping to
resolve some day (requires passing a dentry even though it immediately
extracts the inode and uses that for everything). The only thing really
blocking us is CIFS reliance on pathname reconstruction ;)
> FYI- note that what is going on with that file is that it is being
> modified by the initramfs before policy is loaded-
>
> see do_live_from_base_loop in /usr/lib/livecd-creator/mayflower, i.e.
> stuff like this-
>
> echo "KERNEL==\"hd[a-z]\", BUS==\"ide\", SYSFS{removable}==\"1\",
> ATTRS{media}==\"cdrom\", PROGRAM=\"/lib/udev/vol_id -l %N\",
> RESULT==\"\$CDLABEL\", SYMLINK+=\"live\"" >>
> /sysroot/etc/udev/rules.d/50-udev*
Ah, thanks - that makes sense. So the files get accessed before policy
load, are left with the unlabeled SID for that period of time, but
should get fixed up upon next lookup/d_instantiate.
> >
> >> no clues where this is coming from. I don't see it when I booted my
> >> host system....
> >>
> >>
> >>
> >> Anyway, at this point I want clues/help/suggestions on how to create my
> >> hacked up /selinux inside the chroot.
>
> Out of curiosity, if someone feels like answering- are there any plans
> for selinux to support chroots in the sense of policy and even
> enabled/disabled being completely different between the host and the
> chroot? Seems like "chroot /mnt/sysimage rpm <some rpm commoand>" ought
> to 'just work(tm)'. But maybe I'm expecting too much functionality from
> a default fedora system.
I've given that some thought, but it appears to be rather complex to
support it, and it runs counter to our general goal of being able to
specify and enforce security goals for the entire platform (which is the
point of MAC). I was thinking of introducing per-process policy
pointers that would initially all reference the same policy object, then
provide an interface to "unshare" policy analogous to other forms of
unshare(2) and clone(2), at which point a process could load a different
policy that would only apply to itself and its descendants. However,
that doesn't resolve how to handle objects, and it doesn't deal with
accesses that cross the boundaries, especially as both processes (like
rpm) and files (like the files installed into the chroot environment)
will be accessible and accessed both from within the chroot and from
without. In the end, I'm not sure it is worth it, and it certainly
won't be trivial.
--
Stephen Smalley
National Security Agency
--
fedora-selinux-list mailing list
fedora-selinux-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-selinux-list
