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@xxxxxxxxxxxxxx> National Security Agency
