+++ This bug was initially created as a clone of Bug #561881 +++

I'm trying to setup an SFTP "drop box" for a number of users to upload/share files to a central repository, without them being able to see the rest of the system in any way.

OpenSSH supports this through ChrootDirectory. In addition, by using "ForceCommand internal-sftp", the chroot directory doesn't need to contain anything. (no /bin/bash, no libraries etc).

I've used the following configuration in /etc/ssh/sshd_config:

Match Group chroot
        ChrootDirectory /home/ssh-chroot/
        ForceCommand    internal-sftp


I have a user in supplemental group "chroot", home dir /home/user, shell /bin/false and ssh keys.

Using WinSCP (since my clients will be Windows based), I'm able to connect using keys, and get dropped into /home/ssh-chroot/.

# ls -Zlad /home/ssh-chroot/ /home/ssh-chroot/upload/
drwxr-xr-x. 3 system_u:object_r:user_home_dir_t:s0 root root   4096 2010-02-04 14:36 /home/ssh-chroot/
drwxrwx---. 2 unconfined_u:object_r:user_home_t:s0 root chroot 4096 2010-02-04 14:58 /home/ssh-chroot/upload/

# ps Zauxf
unconfined_u:system_r:sshd_t:s0-s0:c0.c1023 root 13677 0.0  0.0 11472 2912 ?   Ss   14:55   0:00 sshd: user [priv] 
unconfined_u:system_r:sshd_t:s0-s0:c0.c1023 user 13680 0.0  0.0 11472 1668 ?    S    14:55   0:00  \_ sshd: user@notty  
unconfined_u:system_r:sshd_t:s0-s0:c0.c1023 user 13681 0.0  0.0 11624 1396 ?    Ss   14:55   0:00      \_ sshd: user@internal-sftp-server

In throry, my user should be able to write to /home/ssh-chroot/upload/.
I practice the user sees a "permission denied", and I get the following audit log entry:

type=AVC msg=audit(1265295095.883:31053): avc:  denied  { write } for  pid=13267 comm="sshd" name="upload" dev=dm-2 ino=6553602 scontext=unconfined_u:system_r:sshd_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:user_home_t:s0 tclass=dir

Of course, "setenforce 0" allows this to work with no issues, although other avc messages are seen relating to this (add_name, create, write for the actual file).

--- Additional comment from mgrepl on 2010-02-05 02:50:23 EST ---

Mark,

Could you give me some information ?

# rpm -qa selinux-policy\*

Is there anything in the /var/log/secure ?

# grep setcon /var/log/secure

--- Additional comment from m.watts on 2010-02-05 04:13:11 EST ---

selinux-policy-3.6.32-78.fc12.noarch
selinux-policy-targeted-3.6.32-78.fc12.noarch

Nothing in /var/log/secure

--- Additional comment from mgrepl on 2010-02-05 05:29:51 EST ---

We have been talking about that with Mark and now I am trying to reproduce it.

--- Additional comment from mgrepl on 2010-02-08 05:08:44 EST ---

Mark, 

could you try to install 

selinux-policy-3.6.32-85.fc12.noarch.rpm 
selinux-policy-targeted-3.6.32-85.fc12.noarch.rpm

packages from koji.

http://koji.fedoraproject.org/koji/buildinfo?buildID=154841

--- Additional comment from m.watts on 2010-02-08 11:34:08 EST ---


Same issues:

# rpm -q selinux-policy selinux-policy-targeted
selinux-policy-3.6.32-85.fc12.noarch
selinux-policy-targeted-3.6.32-85.fc12.noarch



type=AVC msg=audit(1265646794.315:32282): avc:  denied  { write } for  pid=5172 comm="sshd" name="upload" dev=dm-2 ino=6553602 scontext=unconfined_u:system_r:sshd_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:user_home_t:s0 tclass=dir
type=SYSCALL msg=audit(1265646794.315:32282): arch=40000003 syscall=5 success=no exit=-13 a0=27a53f8 a1=82c1 a2=1b6 a3=d5ab14 items=0 ppid=5171 pid=5172 auid=502 uid=502 gid=504 euid=502 suid=502 fsuid=502 egid=504 sgid=504 fsgid=504 tty=(none) ses=305 comm="sshd" exe="/usr/sbin/sshd" subj=unconfined_u:system_r:sshd_t:s0-s0:c0.c1023 key=(null)

--- Additional comment from jchadima on 2010-06-07 08:26:11 EDT ---

ping, is there still someone alive?

--- Additional comment from m.watts on 2010-06-09 14:54:11 EDT ---

Yes?

--- Additional comment from jchadima on 2010-09-14 06:08:48 EDT ---

Miroslav, what is the progress?

--- Additional comment from mgrepl on 2010-09-15 10:09:14 EDT ---

Unfortunately I am not able to reproduce it. There was a lot of policy updates. 

Mark,
are you still seeing this issue?

--- Additional comment from m.watts on 2010-09-16 04:47:20 EDT ---

Yes I am.

I'm using Fedora 13 now with openssh-server-5.4p1-3.fc13.x86_64

The following is how I'm testing:

# groupadd chroot
# useradd -G chroot -s /bin/false test_ssh
# mkdir -p /home/ssh-chroot/upload
# chmod g+w /home/ssh-chroot/upload
# chown root.chroot /home/ssh-chroot/upload
# chcon unconfined_u:object_r:user_home_t:s0 /home/ssh-chroot/upload
# chcon unconfined_u:object_r:user_home_dir_t:s0 /home/ssh-chroot

Create SSH keys on windows box and add them to /home/test_ssh/.ssh/authorized_keys

Add the following to /etc/ssh/sshd_config:

Subsystem sftp internal-sftp
Match Group chroot
        ChrootDirectory /home/ssh-chroot/
        ForceCommand    internal-sftp

At this point the test_ssh user can login the server using WinSCP and gets dropped into /home/ssh-chroot/ from where it can progress into /home/ssh-chroot/upload.

Any attempt to write a file to this directory gets the following AVC denial:

type=AVC msg=audit(1284626238.008:30187): avc:  denied  { write } for  pid=27870 comm="sshd" name="upload" dev=dm-6 ino=1572866 scontext=unconfined_u:system_r:sshd_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:user_home_t:s0 tclass=dir

--- Additional comment from mgrepl on 2010-09-17 09:33:54 EDT ---

Mark,
thanks for steps to reproduce. Now I am able to reproduce it.

--- Additional comment from mgrepl on 2010-09-17 09:37:57 EDT ---

Jan,
could it be a problem with "ChrootDirectory"? 

"dyntrasition" from sshd to sftpd doesn't happen in this case.

# sftp test_ssh@localhost
# ps -eZ | grep sshd
unconfined_u:system_r:sshd_t:s0-s0:c0.c1023 26396 ? 00:00:00 sshd
unconfined_u:system_r:sshd_t:s0-s0:c0.c1023 26910 ? 00:00:00 sshd
unconfined_u:system_r:sshd_t:s0-s0:c0.c1023 26914 ? 00:00:00 sshd
unconfined_u:system_r:sshd_t:s0-s0:c0.c1023 26915 ? 00:00:00 sshd

without using chroot

# sftp mgrepl@localhost
# ps -eZ | grep sshd
unconfined_u:system_r:sshd_t:s0-s0:c0.c1023 26396 ? 00:00:00 sshd
unconfined_u:system_r:sshd_t:s0-s0:c0.c1023 26920 ? 00:00:00 sshd
unconfined_u:system_r:sshd_t:s0-s0:c0.c1023 26925 ? 00:00:00 sshd
unconfined_u:system_r:sftpd_t:s0-s0:c0.c1023 26926 ? 00:00:00 sshd

--- Additional comment from juha.heljoranta on 2010-10-24 07:27:31 EDT ---

Works for me. 

Appended to /etc/ssh/sshd_config:

Match Group sftponly
        X11Forwarding no
        AllowTcpForwarding no
        ChrootDirectory /home/%u
        ForceCommand internal-sftp

# ls -laZ /home/foo/
drwxr-xr-x. root root unconfined_u:object_r:user_home_dir_t:s0 .
drwxr-xr-x. root root system_u:object_r:home_root_t:s0 ..
drwxr-xr-x. root root unconfined_u:object_r:user_home_t:s0 bar
drwx------. foo  foo  unconfined_u:object_r:ssh_home_t:s0 .ssh
[root@paja foo]# ls -lZ /home/foo/.ssh/
-rw-------. foo foo unconfined_u:object_r:ssh_home_t:s0 authorized_keys
[root@paja foo]# ls -lZ /home/foo/bar/
-rw-r--r--. root root unconfined_u:object_r:user_home_t:s0 test.txt
# rpm -qa selinux-policy\*
selinux-policy-targeted-3.7.19-65.fc13.noarch
selinux-policy-3.7.19-65.fc13.noarch

However I couldn't get the write access to work:

sftp> ls bar/
bar/test.txt  
sftp> get bar/test.txt
Fetching /bar/test.txt to test.txt
sftp> cd bar
sftp> put test.txt 
Uploading test.txt to /bar/test.txt
remote open("/bar/test.txt"): Permission denied

Sealert:
Source Context                unconfined_u:system_r:sshd_t:s0-s0:c0.c1023
Target Context                unconfined_u:object_r:user_home_t:s0
Target Objects                test.txt [ file ]
Source                        sshd
Source Path                   /usr/sbin/sshd
Source RPM Packages           openssh-server-5.4p1-3.fc13
Policy RPM                    selinux-policy-3.7.19-65.fc13
Selinux Enabled               True
Policy Type                   targeted
Enforcing Mode                Enforcing
Plugin Name                   catchall_boolean
Platform                      Linux 2.6.34.7-61.fc13.x86_64 #1 SMP Tue
                              Oct 19 04:06:30 UTC 2010 x86_64 x86_64
Raw Audit Messages            

node= type=AVC msg=audit(1287918783.147:16868): avc:  denied  { write } for  pid=2698 comm="sshd" name="test.txt" dev=dm-1 ino=21 scontext=unconfined_u:system_r:sshd_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:user_home_t:s0 tclass=file

node= type=SYSCALL msg=audit(1287918783.147:16868): arch=c000003e syscall=2 success=no exit=-13 a0=7f9993353fc0 a1=241 a2=1a4 a3=e items=0 ppid=2697 pid=2698 auid=501 uid=501 gid=501 euid=501 suid=501 fsuid=501 egid=501 sgid=501 fsgid=501 tty=(none) ses=25 comm="sshd" exe="/usr/sbin/sshd" subj=unconfined_u:system_r:sshd_t:s0-s0:c0.c1023 key=(null)

Should I open a new issue for getting the write access fixed?

--- Additional comment from m.watts on 2010-10-25 04:57:16 EDT ---

Well my original report was exactly about write access, so I'd say no :)

Logging in while using ChrootDirectory has never been at issue; writing to files was the problem.


As an aside, I'm using an older openssh-server-5.1p1 on CentOS 5.5 to enable ChrootDirectory as well as the internal-sftp server, and that has no issues with writing to files...

Probably a different SELinux policy?

--- Additional comment from jchadima on 2010-11-20 07:22:23 EST ---

Any progress here?

--- Additional comment from m.watts on 2010-11-22 04:07:31 EST ---

None recently.
I see Miroslav was able to reproduce it, followed by another report for the same issue so I suspect it's still on Miroslav's pile.

--- Additional comment from mgrepl on 2010-11-22 04:18:43 EST ---

(In reply to comment #12)
> Jan,
> could it be a problem with "ChrootDirectory"? 
> 
> "dyntrasition" from sshd to sftpd doesn't happen in this case.
> 
> # sftp test_ssh@localhost
> # ps -eZ | grep sshd
> unconfined_u:system_r:sshd_t:s0-s0:c0.c1023 26396 ? 00:00:00 sshd
> unconfined_u:system_r:sshd_t:s0-s0:c0.c1023 26910 ? 00:00:00 sshd
> unconfined_u:system_r:sshd_t:s0-s0:c0.c1023 26914 ? 00:00:00 sshd
> unconfined_u:system_r:sshd_t:s0-s0:c0.c1023 26915 ? 00:00:00 sshd
> 
> without using chroot
> 
> # sftp mgrepl@localhost
> # ps -eZ | grep sshd
> unconfined_u:system_r:sshd_t:s0-s0:c0.c1023 26396 ? 00:00:00 sshd
> unconfined_u:system_r:sshd_t:s0-s0:c0.c1023 26920 ? 00:00:00 sshd
> unconfined_u:system_r:sshd_t:s0-s0:c0.c1023 26925 ? 00:00:00 sshd
> unconfined_u:system_r:sftpd_t:s0-s0:c0.c1023 26926 ? 00:00:00 sshd


Jan,
look at this my question.

--- Additional comment from jchadima on 2010-11-22 04:31:18 EST ---

from the spec changelog:

* Fri Jul 17 2009 Jan F. Chadima <jchadima> - 5.2p1-14
- changed internal-sftp context to sftpd_t

the piece of the code:

        } else if (s->is_subsystem == SUBSYSTEM_INT_SFTP) {
                extern int optind, optreset;
                int i;
                char *p, *args;

                setproctitle("%s@%s", s->pw->pw_name, INTERNAL_SFTP_NAME);
                args = xstrdup(command ? command : "sftp-server");
                for (i = 0, (p = strtok(args, " ")); p; (p = strtok(NULL, " ")))
                        if (i < ARGV_MAX - 1)
                                argv[i++] = p;
                argv[i] = NULL;
                optind = optreset = 1;
                __progname = argv[0];
#ifdef WITH_SELINUX
                ssh_selinux_change_context("sftpd_t");
#endif
                exit(sftp_server_main(i, argv, s->pw));

--- Additional comment from mgrepl on 2011-02-25 09:08:47 EST ---

Jan,
from my point of you an issue is caused by

Match Group sftponly
        X11Forwarding no
        AllowTcpForwarding no
        ChrootDirectory /home/%u
        ForceCommand internal-sftp


when internal-sftp is not running in the proper domain == sftpd_t. If you just use

Subsystem      sftp    internal-sftp

then it works.

--- Additional comment from dane.watson on 2011-03-07 19:40:19 EST ---

This bug is also affecting RHEL6.

unconfined_u:system_r:sshd_t:s0-s0:c0.c1023 test 2047 0.0  0.0 95384 1596 ?    SNs  08:22   0:00          \_ sshd: test@internal-sftp

Confirming that internal-sftp is running as unconfined_u:system_r:sshd_t:s0 instead of sftp so the following sebools have no affect:

# getsebool -a  | grep sftp
sftpd_anon_write --> off
sftpd_enable_homedirs --> on
sftpd_full_access --> off
sftpd_write_ssh_home --> on

without selinux everthing works superb. Running openssh-5.3p1-20.el6.x86_64.

Any help/escalation would be appreciated.

--- Additional comment from dane.watson on 2011-03-08 13:37:01 EST ---

I am not fluent enough in SELinux to decipher the difference here:

Not using chroot, still using internal-sftp
type=LOGIN msg=audit(1299576444.277:287): login pid=2133 uid=0 old auid=501 new auid=500 old ses=28 new ses=36
type=USER_ROLE_CHANGE msg=audit(1299576444.326:288): user pid=2133 uid=0 auid=500 ses=36 subj=unconfined_u:system_r:sshd_t:s0-s0:c0.c1023 msg='pam: default-context=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 selected-context=?: exe="/usr/sbin/sshd" hostname=? addr=? terminal=? res=failed'
type=USER_ROLE_CHANGE msg=audit(1299576444.328:289): user pid=2133 uid=0 auid=500 ses=36 subj=unconfined_u:system_r:sshd_t:s0-s0:c0.c1023 msg='pam: default-context=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 selected-context=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023: exe="/usr/sbin/sshd" hostname=? addr=? terminal=? res=success'
type=USER_START msg=audit(1299576444.349:290): user pid=2133 uid=0 auid=500 ses=36 subj=unconfined_u:system_r:sshd_t:s0-s0:c0.c1023 msg='op=PAM:session_open acct="test" exe="/usr/sbin/sshd" hostname=10.241.70.43 addr=10.241.70.43 terminal=ssh res=success'

Using chroot with internal-sftp:
type=LOGIN msg=audit(1299577358.024:337): login pid=2263 uid=0 old auid=501 new auid=500 old ses=28 new ses=41
type=USER_ROLE_CHANGE msg=audit(1299577358.070:338): user pid=2263 uid=0 auid=500 ses=41 subj=unconfined_u:system_r:sshd_t:s0-s0:c0.c1023 msg='pam: default-context=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 selected-context=?: exe="/usr/sbin/sshd" hostname=? addr=? terminal=? res=failed'
type=USER_ROLE_CHANGE msg=audit(1299577358.071:339): user pid=2263 uid=0 auid=500 ses=41 subj=unconfined_u:system_r:sshd_t:s0-s0:c0.c1023 msg='pam: default-context=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 selected-context=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023: exe="/usr/sbin/sshd" hostname=? addr=? terminal=? res=success'
type=USER_START msg=audit(1299577358.101:340): user pid=2263 uid=0 auid=500 ses=41 subj=unconfined_u:system_r:sshd_t:s0-s0:c0.c1023 msg='op=PAM:session_open acct="test" exe="/usr/sbin/sshd" hostname=10.241.70.43 addr=10.241.70.43 terminal=ssh res=success'
type=CRED_ACQ msg=audit(1299577358.105:341): user pid=2267 uid=0 auid=500 ses=41 subj=unconfined_u:system_r:sshd_t:s0-s0:c0.c1023 msg='op=PAM:setcred acct="test" exe="/usr/sbin/sshd" hostname=10.241.70.43 addr=10.241.70.43 terminal=ssh res=success'
type=AVC msg=audit(1299577363.793:342): avc:  denied  { write } for  pid=2268 comm="sshd" name="test.txt" dev=dm-2 ino=1310727 scontext=unconfined_u:system_r:sshd_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:user_home_t:s0 tclass=file
type=SYSCALL msg=audit(1299577363.793:342): arch=c000003e syscall=2 success=yes exit=5 a0=7fd1d2b21100 a1=241 a2=1b6 a3=11 items=0 ppid=2267 pid=2268 auid=500 uid=500 gid=500 euid=500 suid=500 fsuid=500 egid=500 sgid=500 fsgid=500 tty=(none) ses=41 comm="sshd" exe="/usr/sbin/sshd" subj=unconfined_u:system_r:sshd_t:s0-s0:c0.c1023 key=(null)

I was able to work around the problem by mount -o bind /proc /chroot/proc... But that doesn't seem very secure.

--- Additional comment from mgrepl on 2011-03-09 05:58:24 EST ---

(In reply to comment #21)
> I am not fluent enough in SELinux to decipher the difference here:
> 
> Not using chroot, still using internal-sftp

So without chroot option it works also for you and you should see sshd running as sftpd_t as I wrote in the comment 17. Can you confirm it?

--- Additional comment from dane.watson on 2011-03-09 13:17:24 EST ---

Confirmed; that was my understanding. Note the last line; chroot works with internal-sftp if I mount /proc inside the chroot. Selinux or openssh seems to be reading the attr file out of the proc directory which it can't find if its chrooted

--- Additional comment from jchadima on 2011-03-10 05:38:13 EST ---

(In reply to comment #23)
> Confirmed; that was my understanding. Note the last line; chroot works with
> internal-sftp if I mount /proc inside the chroot. Selinux or openssh seems to
> be reading the attr file out of the proc directory which it can't find if its
> chrooted

can you post strace please?

--- Additional comment from dwalsh on 2011-03-11 09:38:44 EST ---

SELinux is going to read /proc/filesystem to figure out if SELinux is enabled.  It needs /proc and /selinux in order to work properly.

--- Additional comment from jchadima on 2011-03-17 03:56:45 EDT ---

experimentally solved in rawhide's openssh-5.8p1-18 please test

--- Additional comment from mgrepl on 2011-03-17 04:44:09 EDT ---

(In reply to comment #26)
> experimentally solved in rawhide's openssh-5.8p1-18 please test
Great, I am going to test it.

--- Additional comment from stu.pike on 2011-05-19 06:13:00 EDT ---

I'm having the same issue with RHEL6. Is there going to be a rpm released to fix this issue? Or am I going to have to patch this openssh-5.8p2 manually as I have done in my test environment?

--- Additional comment from jchadima on 2011-05-24 11:58:03 EDT ---

(In reply to comment #28)
> I'm having the same issue with RHEL6. Is there going to be a rpm released to
> fix this issue? Or am I going to have to patch this openssh-5.8p2 manually as I
> have done in my test environment?

the best way is to contact RH SUPPORT.

--- Additional comment from triage.org on 2011-06-02 12:41:03 EDT ---


This message is a reminder that Fedora 13 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 13.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '13'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 13's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 13 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

--- Additional comment from david.tauriainen on 2011-06-21 20:38:39 EDT ---

Given the automated warning above, could someone change the OS to RHEL 6 or 6.1 to keep the bug report alive?

This is also an issue in RHEL 6.1, openssh-server-5.3p1-52:
$ sftp username@server
Connecting to server...
username@server's password: 
sftp> ls
Couldn't get handle: Permission denied
sftp> ls
Couldn't get handle: Permission denied
sftp> cd web
sftp> put foo.txt
Uploading foo.txt to /web/foo.txt
Couldn't get handle: Permission denied