Bug 913175

static int verify_directory(const char *dir, struct stat *st_in, struct stat *st_out) {
	struct stat sb;

	if (st_out == NULL) st_out = &sb;

	if (lstat(dir, st_out) == -1) {
		fprintf(stderr, _("Failed to stat %s: %s\n"), dir, strerror(errno));
		return -1;
	}
	if (! S_ISDIR(st_out->st_mode)) {
		fprintf(stderr, _("Error: %s is not a directory: %s\n"), dir, strerror(errno));
		return -1;
	}
	if (st_in && !equal_stats(st_in, st_out)) {
		fprintf(stderr, _("Error: %s was replaced by a different directory\n"), dir);
		return -1;
	}

	return 0;
}

We are verifying that you are mounting on a directory.  Which is what is probably causing you the problem.

I guess if we changed this code to stat instead of lstat this would be work.
Or did not check if the object was a directory, but I would have to check with the security team here.

You could verify this by temporarily changing your homedir to /n/fs/staff/benrose

You are indeed correct good sir. We made the change and it seems to have worked perfectly:

[benrose@spin ~]$ getent passwd benrose
benrose:*:*:*:*:/n/fs/staff/benrose:/bin/bash
[benrose@spin ~]$ sandbox -t sandbox_x_t -M bash
bash: cannot set terminal process group (-1): Inappropriate ioctl for device
bash: no job control in this shell
bash-4.1$ ls
bash-4.1$ exit
[benrose@spin ~]$

I had to also have /n/fs/staff set as a HOMEDIR in /etc/sysconfig/sandbox.

We need to use our symlink setup in production, can we get this change merged mainline (once the proper course of change is determined) or will we need to roll our own patched version?

Tomas what do you think?

We chould change the code to follow the link to the file directory if that is owned by the user would could mount on the link inode.

I think lstat was used instead of stat to avoid symlink issues.  We'd have to check all relevant code paths for issues this may expose.

Which makes me wonder, would it make more sense to modify (non-suid) sandbox to resolve symlink and pass that to seunshare, keeping the strict check in seunshare?

Not that easy since the homedir is read from the trusted database /etc/passwd, not sure how the user can attack this.  How about if we run the homedir through realpath before checking and mount on that directory.

Created attachment 703151 [details]
Patch to use real_path for homedir.

(In reply to comment #7)
> Not that easy since the homedir is read from the trusted database
> /etc/passwd, not sure how the user can attack this.

Agree for sandbox, but seunshare accepts arbitrary paths for home and tmp directories via -h and -t.

THose are directories to mount over $HOME as specified in /etc/passwd.  The problem we are seeing is the entry in /etc/passwd for this user is a symbolic link not a directory.  Using realpath on pw_dir is not running it on content specified by the user.

This request was not resolved in time for the current release.
Red Hat invites you to ask your support representative to
propose this request, if still desired, for consideration in
the next release of Red Hat Enterprise Linux.

Any word on this? Have some users asking for an ETA.

Well we have allowed this in RHEL6 and Latest Fedoras, is there any way you could check it out on Fedora 18, to make sure it matches your needs, then I could back port the fixes for RHEL6.5.

This is not working on my fully-updated 6.4 boxes. Setting up a Fedora instance would be non-trivial given that all of this is done through automount and puppet and such. I tried to find your patch to do the backport - the one attached to this ticket doesn't appear to be an actual patch, and I can't find anything relevant in the RPM from the F18 updates SRPM directory. Visiting the trac page here: http://userspace.selinuxproject.org/trac/log/policycoreutils/sandbox I see that the most recent changes were on Feb 5, and this ticket was reported Feb 20. If you can somehow point me in the direction of the changes you made, I would be most happy to take a stab at backporting the changes myself and submitting them back to you.

fixed in policycoreutils-2.0.83-19.31.el6

This request was evaluated by Red Hat Product Management for
inclusion in a Red Hat Enterprise Linux release.  Product
Management has requested further review of this request by
Red Hat Engineering, for potential inclusion in a Red Hat
Enterprise Linux release for currently deployed products.
This request is not yet committed for inclusion in a release.

Dan,
would it be possible to point the reporter to a particular patch so he can test it?

Created attachment 781193 [details]
Patch to allow use sandbox to follow homedirs symlinks.

Did you get an AVC?

Got this one:
----
type=SYSCALL msg=audit(10/17/2013 16:04:59.507:5945) : arch=x86_64 syscall=setpgid success=no exit=-13(Permission denied) a0=0 a1=192e a2=0 a3=20 items=0 ppid=6445 pid=6446 auid=unknown(507) uid=unknown(507) gid=unknown(507) euid=unknown(507) suid=unknown(507) fsuid=unknown(507) egid=unknown(507) sgid=unknown(507) fsgid=unknown(507) tty=pts2 ses=331 comm=bash exe=/bin/bash subj=unconfined_u:unconfined_r:sandbox_t:s0:c207,c996 key=(null) 
type=AVC msg=audit(10/17/2013 16:04:59.507:5945) : avc:  denied  { setpgid } for  pid=6446 comm=bash scontext=unconfined_u:unconfined_r:sandbox_t:s0:c207,c996 tcontext=unconfined_u:unconfined_r:sandbox_t:s0:c207,c996 tclass=process 
----

Well I guess you added a second level of indirection here, which is causing the tool problems.  Not sure if this is a real world situation though.

at this time engineering does not believe this can or should be resolved during the 6.5 release.  Moving to 6.6

Development Management has reviewed and declined this request.
You may appeal this decision by reopening this request.

This request was evaluated by Red Hat Product Management for
inclusion in a Red Hat Enterprise Linux release.  Product
Management has requested further review of this request by
Red Hat Engineering, for potential inclusion in a Red Hat
Enterprise Linux release for currently deployed products.
This request is not yet committed for inclusion in a release.

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

http://rhn.redhat.com/errata/RHBA-2014-1569.html