Bug 913175 - sandbox cant use symlink homedirs
Summary: sandbox cant use symlink homedirs
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: policycoreutils
Version: 6.3
Hardware: All
OS: Linux
unspecified
unspecified
Target Milestone: rc
: ---
Assignee: Miroslav Grepl
QA Contact: Milos Malik
URL:
Whiteboard:
Depends On:
Blocks: 947775 1070830 1085231
TreeView+ depends on / blocked
 
Reported: 2013-02-20 15:17 UTC by Benjamin Rose
Modified: 2014-10-14 08:04 UTC (History)
6 users (show)

Fixed In Version: policycoreutils-2.0.83-19.41.el6
Doc Type: Bug Fix
Doc Text:
Clone Of:
: 1085231 (view as bug list)
Environment:
Last Closed: 2014-10-14 08:04:22 UTC
Target Upstream Version:


Attachments (Terms of Use)
Patch to use real_path for homedir. (606.87 KB, patch)
2013-02-26 21:56 UTC, Daniel Walsh
no flags Details | Diff
Patch to allow use sandbox to follow homedirs symlinks. (1.97 KB, patch)
2013-07-31 14:58 UTC, Daniel Walsh
no flags Details | Diff


Links
System ID Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2014:1569 normal SHIPPED_LIVE policycoreutils bug fix update 2014-10-14 01:27:36 UTC

Description Benjamin Rose 2013-02-20 15:17:58 UTC
Description of problem:
Homedirs in my shop are setup as such:

[benrose@spin ~]$ echo ~
/u/benrose
[benrose@spin ~]$ ll / | grep u
lrwxrwxrwx.   1 root root       7 Mar 22  2012 u -> /auto/u
[benrose@spin ~]$ ll /auto/u/ | grep `whoami`
lrwxrwxrwx. 1 root root 20 Mar 20  2012 benrose -> /n/fs/staff/benrose

So you can see we have a few levels of symlinks. Well, regardless of what I put in HOMEDIRS in /etc/sysconfig/sandbox, I cannot get a sandbox shell to run when I use the -M flag:

[benrose@spin ~]$ sandbox bash
bash: initialize_job_control: setpgid: Permission denied
bash: /u/benrose/.bashrc: Permission denied
bash-4.1$ exit
[benrose@spin ~]$ sandbox -M bash
Error: /u/benrose is not a directory: No such file or directory

Any hints? I can provide whatever else information is needed to get this resolved. Not sure where else to look for debugging info. If I try running it through strace, it dies for a different reason entirely:

[benrose@spin ~]$ strace -o stracesandbox -f sandbox -M bash
Error: /tmp/.sandbox-benrose-xhcMLg not owned by UID 0
Failed to create runtime temporary directory



Version-Release number of selected component (if applicable):
[abenrose@spin ~]$ sandbox --version
sandbox .1
[abenrose@spin ~]$ rpm -aq | grep sandbox
policycoreutils-sandbox-2.0.83-19.24.el6.x86_64



How reproducible:
Always

Steps to Reproduce:
1. Run sandbox with -M
  
Actual results:
Errors out


Expected results:
Obtain bash shell


Additional info:
None.

Comment 2 Daniel Walsh 2013-02-22 13:31:25 UTC
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.

Comment 3 Daniel Walsh 2013-02-22 13:32:36 UTC
You could verify this by temporarily changing your homedir to /n/fs/staff/benrose

Comment 4 Benjamin Rose 2013-02-22 16:18:32 UTC
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?

Comment 5 Daniel Walsh 2013-02-22 16:43:37 UTC
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.

Comment 6 Tomas Hoger 2013-02-25 13:32:03 UTC
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?

Comment 7 Daniel Walsh 2013-02-26 21:55:28 UTC
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.

Comment 8 Daniel Walsh 2013-02-26 21:56:40 UTC
Created attachment 703151 [details]
Patch to use real_path for homedir.

Comment 9 Tomas Hoger 2013-02-27 04:31:40 UTC
(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.

Comment 10 Daniel Walsh 2013-02-27 14:38:05 UTC
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.

Comment 11 RHEL Product and Program Management 2013-03-03 06:48:37 UTC
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.

Comment 13 Benjamin Rose 2013-03-21 18:48:43 UTC
Any word on this? Have some users asking for an ETA.

Comment 14 Daniel Walsh 2013-03-22 14:41:44 UTC
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.

Comment 15 Benjamin Rose 2013-03-22 16:06:08 UTC
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.

Comment 16 Daniel Walsh 2013-03-25 16:37:56 UTC
fixed in policycoreutils-2.0.83-19.31.el6

Comment 17 RHEL Product and Program Management 2013-06-12 12:42:01 UTC
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.

Comment 23 Karel Srot 2013-07-31 14:28:13 UTC
Dan,
would it be possible to point the reporter to a particular patch so he can test it?

Comment 24 Daniel Walsh 2013-07-31 14:58:12 UTC
Created attachment 781193 [details]
Patch to allow use sandbox to follow homedirs symlinks.

Comment 27 Daniel Walsh 2013-10-17 13:43:54 UTC
Did you get an AVC?

Comment 28 Milos Malik 2013-10-17 14:07:28 UTC
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 
----

Comment 29 Daniel Walsh 2013-10-17 15:51:39 UTC
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.

Comment 32 Eric Paris 2013-10-25 16:52:18 UTC
at this time engineering does not believe this can or should be resolved during the 6.5 release.  Moving to 6.6

Comment 33 RHEL Product and Program Management 2013-10-25 16:56:32 UTC
Development Management has reviewed and declined this request.
You may appeal this decision by reopening this request.

Comment 35 RHEL Product and Program Management 2014-03-26 00:20:30 UTC
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.

Comment 38 errata-xmlrpc 2014-10-14 08:04:22 UTC
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


Note You need to log in before you can comment on or make changes to this bug.