/proc mounted in chroot breaks su

[Stephen Smalley]

On Thu, 2005-01-27 at 17:13, Steve Brueckner wrote:
> Hello, I've got what I think might be a real zinger for y'all:
> 
> I've got a chrooted environment that's pretty much a duplicate of my primary
> file system (I copied almost everything into it).  I've also got /proc
> mounted in the chroot environment.  Yes, I realize what a security risk that
> is, but I need the Java to work in the chrooted environment, and that
> requires access to /proc for heap and thread information.  I'm using FC3
> with SELinux enabled but in permissive mode (targeted policy).  Since it's
> in permissive mode, I don't think the SELinux is coming into play here.
> 
> My problem is that I can't drop privilege once I'm in the chrooted
> environment unless I umount /proc from the chrooted environment.  For
> example:
> 
> # /usr/sbin/chroot /chrootdir
> # su steve
> Password: (I enter it correctly)
> could not open session
> #
> 
> But if I umount /chrootdir/proc I get this:
> 
> # /usr/sbin/chroot /chrootdir
> # su steve
> $
> 
> Note that in the first case, su prompts for my password and in the second
> case it doesn't.
> 
> Outside of the chrooted environment, su behaves (correctly) just like su
> inside the chrooted environment with /chrootdir/proc unmounted.  This is an
> apparent paradox: outside the chrooted environment su has access to /proc
> and behaves correctly, but inside the chrooted environment su behaves
> incorrectly when it has access to /proc, and only works when its access to
> /proc is removed!
> 
> Any thoughts, ideas, or solutions are welcome.  Thanks.

This could actually be an SELinux issue.  If /proc is mounted, then
libselinux can tell that SELinux is enabled in the kernel (via a check
for selinuxfs in /proc/filesystems), so pam_selinux will run upon an
attempted su.  But pam_selinux needs to interrogate /selinux (selinuxfs)
to get the set of reachable security contexts for the new user.  Hence,
mounting /proc without mounting /selinux in your chroot could yield the
behavior you describe.  Now, you could certainly modify your
/etc/pam.d/su in your chroot to remove pam_selinux from it so that it
doesn't attempt to run pam_selinux at all.  Of course, having su in your
chroot is begging for trouble in the first place...

-- 
Stephen Smalley <sds at epoch.ncsc.mil>
National Security Agency