Bug 561881

Summary: SELinux avc denials when using ChrootDirectory
Product: [Fedora] Fedora Reporter: Mark Watts <m.watts>
Component: opensshAssignee: Jan F. Chadima <jchadima>
Status: CLOSED WONTFIX QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: low    
Version: 13CC: dane.watson, david.tauriainen, dwalsh, jchadima, juha.heljoranta, mgrepl, stu.pike, tmraz
Target Milestone: ---Keywords: SELinux
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
: 715338 (view as bug list) Environment:
Last Closed: 2011-06-27 10:53:35 EDT Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Bug Depends On:    
Bug Blocks: 715338    

Description Mark Watts 2010-02-04 11:00:28 EST
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).
Comment 1 Miroslav Grepl 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
Comment 2 Mark Watts 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
Comment 3 Miroslav Grepl 2010-02-05 05:29:51 EST
We have been talking about that with Mark and now I am trying to reproduce it.
Comment 4 Miroslav Grepl 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
Comment 5 Mark Watts 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)
Comment 6 Jan F. Chadima 2010-06-07 08:26:11 EDT
ping, is there still someone alive?
Comment 7 Mark Watts 2010-06-09 14:54:11 EDT
Yes?
Comment 8 Jan F. Chadima 2010-09-14 06:08:48 EDT
Miroslav, what is the progress?
Comment 9 Miroslav Grepl 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?
Comment 10 Mark Watts 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
Comment 11 Miroslav Grepl 2010-09-17 09:33:54 EDT
Mark,
thanks for steps to reproduce. Now I am able to reproduce it.
Comment 12 Miroslav Grepl 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
Comment 13 Juha Heljoranta 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?
Comment 14 Mark Watts 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?
Comment 15 Jan F. Chadima 2010-11-20 07:22:23 EST
Any progress here?
Comment 16 Mark Watts 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.
Comment 17 Miroslav Grepl 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.
Comment 18 Jan F. Chadima 2010-11-22 04:31:18 EST
from the spec changelog:

* Fri Jul 17 2009 Jan F. Chadima <jchadima@redhat.com> - 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));
Comment 19 Miroslav Grepl 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.
Comment 20 Dane Watson 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.
Comment 21 Dane Watson 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.
Comment 22 Miroslav Grepl 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?
Comment 23 Dane Watson 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
Comment 24 Jan F. Chadima 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?
Comment 25 Daniel Walsh 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.
Comment 26 Jan F. Chadima 2011-03-17 03:56:45 EDT
experimentally solved in rawhide's openssh-5.8p1-18 please test
Comment 27 Miroslav Grepl 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.
Comment 28 Stuart 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?
Comment 29 Jan F. Chadima 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.
Comment 30 Bug Zapper 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
Comment 31 David Tauriainen 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
Comment 32 Bug Zapper 2011-06-27 10:53:35 EDT
Fedora 13 changed to end-of-life (EOL) status on 2011-06-25. Fedora 13 is 
no longer maintained, which means that it will not receive any further 
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of 
Fedora please feel free to reopen this bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.