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@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-selinux-list

On Thu, 2008-05-15 at 15:30 -0400, Stephen Smalley wrote:
> On Thu, 2008-05-15 at 13:50 -0400, Eric Paris wrote:
> > So I'm still stumbling along in the dark trying to get livecd-creator to
> > build me a nice new F10 image inside an F10 host. I've actually got an
> > image that built and runs, but not without its issues.
> >
> > my kickstart file has:
> > auth --enableshadow --enablemd5
> > rootpw redhat
> >
> > but the livecd always has x for the password in /etc/password and * for
> > the password in /etc/shadow. No ideas here I must admit. I'm highly
> > doubtful its selinux since it happens in permissive and enforcing. I
> > have just been booting into single user, calling passwd, init 3, and
> > logging in to play around in my live image....
>
> No ideas here - hopefully the livecd folks can help you with that one.

turns out it was an selinux issue.

passwd does 2 different checks to see if selinux is going to allow it.
Dan, what were you thinking? I see your name written all of this.

Anyway selinux_check_passwd_access() calls security_getenforce() and
allows things if it gets 0. Since security_getenforce can't
open /selinux/enforce (it doesn't exist) it returned -1, we then
proceeded to try to do the access check which obviously also bombed (do
to another ENOENT) and passwd gave us that useless "Only root can do
that" message.

First try was to change selinux_check_passwd_access() to return a
success if security_getenforce() < 1. Which then turned up that passwd
has its own secondary check (WTF?) called check_selinux_access() which
basically did the same thing as the libselinux function. I changed it
to use < 1 and finally got passwd to run inside my chroot.

I think the best solution here is to explicitly set a /selinux/enforce =
0 in the chroot rather than hack everything that could possibly call
security_getenforce() what do others think?

-Eric

--
fedora-selinux-list mailing list
fedora-selinux-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-selinux-list

On Fri, 2008-05-16 at 14:25 -0400, Eric Paris wrote:
> On Thu, 2008-05-15 at 15:30 -0400, Stephen Smalley wrote:
> > On Thu, 2008-05-15 at 13:50 -0400, Eric Paris wrote:
> > > So I'm still stumbling along in the dark trying to get livecd-creator to
> > > build me a nice new F10 image inside an F10 host. I've actually got an
> > > image that built and runs, but not without its issues.
> > >
> > > my kickstart file has:
> > > auth --enableshadow --enablemd5
> > > rootpw redhat
> > >
> > > but the livecd always has x for the password in /etc/password and * for
> > > the password in /etc/shadow. No ideas here I must admit. I'm highly
> > > doubtful its selinux since it happens in permissive and enforcing. I
> > > have just been booting into single user, calling passwd, init 3, and
> > > logging in to play around in my live image....
> >
> > No ideas here - hopefully the livecd folks can help you with that one.
>
> turns out it was an selinux issue.
>
> passwd does 2 different checks to see if selinux is going to allow it.
> Dan, what were you thinking? I see your name written all of this.
>
> Anyway selinux_check_passwd_access() calls security_getenforce() and
> allows things if it gets 0. Since security_getenforce can't
> open /selinux/enforce (it doesn't exist) it returned -1, we then
> proceeded to try to do the access check which obviously also bombed (do
> to another ENOENT) and passwd gave us that useless "Only root can do
> that" message.
>
> First try was to change selinux_check_passwd_access() to return a
> success if security_getenforce() < 1. Which then turned up that passwd
> has its own secondary check (WTF?) called check_selinux_access() which
> basically did the same thing as the libselinux function. I changed it
> to use < 1 and finally got passwd to run inside my chroot.
>
> I think the best solution here is to explicitly set a /selinux/enforce =
> 0 in the chroot rather than hack everything that could possibly call
> security_getenforce() what do others think?

Given the approach being taken here, that is likely harmless, as all we
care about within the chroot is that SELinux is seen as enabled (which
is independent of enforce) and that files are labeled properly.

--
Stephen Smalley
National Security Agency

--
fedora-selinux-list mailing list
fedora-selinux-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-selinux-list

Eric Paris wrote:
> On Thu, 2008-05-15 at 15:30 -0400, Stephen Smalley wrote:
>> On Thu, 2008-05-15 at 13:50 -0400, Eric Paris wrote:
>>> So I'm still stumbling along in the dark trying to get livecd-creator to
>>> build me a nice new F10 image inside an F10 host. I've actually got an
>>> image that built and runs, but not without its issues.
>>>
>>> my kickstart file has:
>>> auth --enableshadow --enablemd5
>>> rootpw redhat
>>>
>>> but the livecd always has x for the password in /etc/password and * for
>>> the password in /etc/shadow. No ideas here I must admit. I'm highly
>>> doubtful its selinux since it happens in permissive and enforcing. I
>>> have just been booting into single user, calling passwd, init 3, and
>>> logging in to play around in my live image....
>> No ideas here - hopefully the livecd folks can help you with that one.
>
> turns out it was an selinux issue.
>
> passwd does 2 different checks to see if selinux is going to allow it.
> Dan, what were you thinking? I see your name written all of this.
>
> Anyway selinux_check_passwd_access() calls security_getenforce() and
> allows things if it gets 0. Since security_getenforce can't
> open /selinux/enforce (it doesn't exist) it returned -1, we then
> proceeded to try to do the access check which obviously also bombed (do
> to another ENOENT) and passwd gave us that useless "Only root can do
> that" message.
>
> First try was to change selinux_check_passwd_access() to return a
> success if security_getenforce() < 1. Which then turned up that passwd
> has its own secondary check (WTF?) called check_selinux_access() which
> basically did the same thing as the libselinux function. I changed it
> to use < 1 and finally got passwd to run inside my chroot.
>
> I think the best solution here is to explicitly set a /selinux/enforce =
> 0 in the chroot rather than hack everything that could possibly call
> security_getenforce() what do others think?
>
> -Eric
>
Well the code was written 100 years ago or it feels that way anyways. I
think the multiple checks are to see if you are root when changing a
password and to check whether the domain executing passwd has the rootok
passwd access.


--
fedora-selinux-list mailing list
fedora-selinux-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-selinux-list