685060 – In a chrooted sftp environment, selinux is preventing the users from uploading new files to their home directories.

RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.

Bug 685060 - In a chrooted sftp environment, selinux is preventing the users from uploading new files to their home directories.

Summary: In a chrooted sftp environment, selinux is preventing the users from uploadin...

Keywords:
Status:	CLOSED ERRATA
Alias:	None
Product:	Red Hat Enterprise Linux 6
Classification:	Red Hat
Component:	openssh
Sub Component:
Version:	6.0
Hardware:	Unspecified
OS:	Linux
Priority:	medium
Severity:	medium
Target Milestone:	rc
Target Release:	---
Assignee:	Jan F. Chadima
QA Contact:	BaseOS QE Security Team
Docs Contact:
URL:
Whiteboard:
Duplicates (1):	715338 (view as bug list)
Depends On:	729648
Blocks:
TreeView+	depends on / blocked

Reported:	2011-03-15 07:55 UTC by Jijesh Kalliyat
Modified:	2018-11-14 15:37 UTC (History)
CC List:	8 users (show)
Fixed In Version:	openssh-5.3p1-59.el6
Doc Type:	Bug Fix
Doc Text:
Clone Of:
Clones:	729648 (view as bug list)
Environment:
Last Closed:	2011-12-06 09:55:56 UTC
Target Upstream Version:
Embargoed:

Attachments	(Terms of Use)

Links
System	ID	Private	Priority	Status	Summary	Last Updated
Red Hat Knowledge Base (Legacy)	44979	0	None	None	None	Never
Red Hat Product Errata	RHBA-2011:1551	0	normal	SHIPPED_LIVE	openssh bug fix and enhancement update	2011-12-06 00:39:25 UTC

Description Jijesh Kalliyat 2011-03-15 07:55:30 UTC

Description of problem:
In a chrooted sftp environment, selinux is preventing the users from uploading new files to their home directories.

Issue in detail :

When chrooted users trying upload files to their home directory, selinux deny it with the following logs :

type=AVC msg=audit(1299680139.405:61165): avc: denied { write } for pid=3906 comm="sshd" name="outbound" dev=dm-2 ino=12845071 scontext=unconfined_u:system_r:sshd_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:user_home_t:s0 tclass=dir

Version-Release number of selected component (if applicable):
RHEL6
selinux-policy-3.7.19-54.el6

How reproducible:

Steps to Reproduce:
1. setup chrooted sftp:

sshd_config :

ChrootDirectory /home/%u
Subsystem sftp internal-sftp
2. Try to upload a new file to user's home directory.

Actual results:
selinux deny it.

Expected results:
selinux should't deny it (?).

Additional info:

RHEL6 (even rhel5) selinux policy doesn't allow sshd_t to write to a directory which has the context user_home_t.So the above denial is expected.

allow sshd_t user_home_t : dir { ioctl read getattr lock search open } ;

Also there is no SELinux booleans which allow this access.

Note:

-On RHEL5, this is not an issue since in RHEL5 we allow the sshd to be unconfined so it can transition to the unconfined_t domain.
-on RHEL6, sshd run in sshd_t which is not unconfined and thus we see the issue here.
-on RHEL6, issue is not seen when the default subsystem is used, ie /usr/libexec/openssh/sftp-server. This subsystem runs in in 'unconfined_t' context which has access to almost all objects. So the transfer should work fine. but this can't be used for chrooting.

Question:

- Apart from writing a custom policy, What the best way to deal this situation ?.
- This could be treated as bug ?. If allowing such access is considered as security risk, we may need a boolean to allow this ?. Most of the users doesn't like to keep their own policy files.

Comment 2 Daniel Walsh 2011-03-15 12:27:41 UTC

Miroslav I thought we had some fixes for chroot and sshd?

Comment 3 Miroslav Grepl 2011-03-15 12:59:46 UTC

Unfortunately ... the same issue as #561881.

Comment 17 RHEL Program Management 2011-04-04 02:00:47 UTC

Since RHEL 6.1 External Beta has begun, and this bug remains
unresolved, it has been rejected as it is not proposed as
exception or blocker.

Red Hat invites you to ask your support representative to
propose this request, if appropriate and relevant, in the
next release of Red Hat Enterprise Linux.

Comment 19 Jan F. Chadima 2011-06-23 14:08:09 UTC

*** Bug 715338 has been marked as a duplicate of this bug. ***

Comment 28 Miroslav Vadkerti 2011-08-03 16:03:30 UTC

Hi I wrote a reproducer, though I still cannot write to user_home_dir_t directory with the latest openssh package:

time->Wed Aug  3 12:01:14 2011
type=SYSCALL msg=audit(1312387274.711:142887): arch=c000003e syscall=2 success=no exit=-13 a0=7f36ec2b6470 a1=241 a2=180 a3=13 items=0 ppid=29037 pid=29038 auid=511 uid=511 gid=512 euid=511 suid=511 fsuid=511 egid=512 sgid=512 fsgid=512 tty=(none) ses=12429 comm="sshd" exe="/usr/sbin/sshd" subj=unconfined_u:system_r:sshd_t:s0-s0:c0.c1023 key=(null)
type=AVC msg=audit(1312387274.711:142887): avc:  denied  { create } for  pid=29038 comm="sshd" name="test" scontext=unconfined_u:system_r:sshd_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:user_home_dir_t:s0 tclass=file
# rpm -q openssh
openssh-5.3p1-63.el6.x86_64

Seems to me that sshd is still not running internal-sftp with correct context. Mirek pls did you test the latest fix?

Comment 29 Daniel Walsh 2011-08-03 17:28:59 UTC

Why would sshd be creating a file test in the users homedir?

Comment 30 Jan F. Chadima 2011-08-03 19:00:10 UTC

Internal sftp is still sshd, but wit another context. It should have the r/w permissions to the homedir.

Comment 33 Miroslav Grepl 2011-08-04 08:12:16 UTC

I see the same issue, this works in Fedora.

Comment 34 Jan F. Chadima 2011-08-04 10:35:35 UTC

I see this error:
ssh_selinux_change_context: setcon unconfined_u:system_r:sshd_sftpd_t:s0-s0:c0.c1023 from unconfined_u:system_r:sshd_t:s0-s0:c0.c1023 failed with Invalid argument

Can someone from selinux explain why is this prohibited?

Comment 35 Miroslav Grepl 2011-08-04 14:14:47 UTC

"sshd_sftpd_t" does not exist.

Miroslav V. has a test policy which we created.

Comment 36 Jan F. Chadima 2011-08-04 15:16:36 UTC

The test policy is insufficient. It even breaks regular login.

Comment 37 Miroslav Vadkerti 2011-08-04 15:25:00 UTC

When I try to login via ssh I get these AVC's, should I add them to the policy module? Why we have sshd_sftpd_t denials when I'm not connecting via sftp? 

type=AVC msg=audit(1312471372.239:144551): avc:  denied  { search } for  pid=27258 comm="sshd" name="root" dev=dm-0 ino=3014657 scontext=unconfined_u:system_r:sshd_sftpd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:admin_home_t:s0 tclass=dir
type=SYSCALL msg=audit(1312471372.239:144551): arch=c000003e syscall=4 success=no exit=-13 a0=7fffb9b35f80 a1=7fffb9b35ef0 a2=7fffb9b35ef0 a3=fffffffb items=0 ppid=27253 pid=27258 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts1 ses=12614 comm="sshd" exe="/usr/sbin/sshd" subj=unconfined_u:system_r:sshd_sftpd_t:s0-s0:c0.c1023 key=(null)
type=AVC msg=audit(1312471372.240:144552): avc:  denied  { search } for  pid=27258 comm="sshd" name="root" dev=dm-0 ino=3014657 scontext=unconfined_u:system_r:sshd_sftpd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:admin_home_t:s0 tclass=dir
type=SYSCALL msg=audit(1312471372.240:144552): arch=c000003e syscall=80 success=no exit=-13 a0=7f2b07a06660 a1=7f2b06c298b8 a2=9 a3=0 items=0 ppid=27253 pid=27258 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts1 ses=12614 comm="sshd" exe="/usr/sbin/sshd" subj=unconfined_u:system_r:sshd_sftpd_t:s0-s0:c0.c1023 key=(null)
type=AVC msg=audit(1312471372.240:144553): avc:  denied  { write } for  pid=27258 comm="sshd" path="/dev/pts/1" dev=devpts ino=4 scontext=unconfined_u:system_r:sshd_sftpd_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:user_devpts_t:s0 tclass=chr_file
type=SYSCALL msg=audit(1312471372.240:144553): arch=c000003e syscall=1 success=no exit=-13 a0=2 a1=7fffb9b337a0 a2=3b a3=ffffffff items=0 ppid=27253 pid=27258 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts1 ses=12614 comm="sshd" exe="/usr/sbin/sshd" subj=unconfined_u:system_r:sshd_sftpd_t:s0-s0:c0.c1023 key=(null)
type=AVC msg=audit(1312471372.241:144554): avc:  denied  { execute } for  pid=27258 comm="sshd" name="bash" dev=dm-0 ino=524336 scontext=unconfined_u:system_r:sshd_sftpd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:shell_exec_t:s0 tclass=file
type=SYSCALL msg=audit(1312471372.241:144554): arch=c000003e syscall=59 success=no exit=-13 a0=7f2b07a06680 a1=7fffb9b361a0 a2=7f2b079fce70 a3=0 items=0 ppid=27253 pid=27258 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts1 ses=12614 comm="sshd" exe="/usr/sbin/sshd" subj=unconfined_u:system_r:sshd_sftpd_t:s0-s0:c0.c1023 key=(null)
type=AVC msg=audit(1312471372.241:144555): avc:  denied  { write } for  pid=27258 comm="sshd" path="/dev/pts/1" dev=devpts ino=4 scontext=unconfined_u:system_r:sshd_sftpd_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:user_devpts_t:s0 tclass=chr_file
type=SYSCALL msg=audit(1312471372.241:144555): arch=c000003e syscall=1 success=no exit=-13 a0=2 a1=7fffb9b33370 a2=1d a3=ffffffef items=0 ppid=27253 pid=27258 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts1 ses=12614 comm="sshd" exe="/usr/sbin/sshd" subj=unconfined_u:system_r:sshd_sftpd_t:s0-s0:c0.c1023 key=(null)
type=AVC msg=audit(1312471372.243:144556): avc:  denied  { sigchld } for  pid=27253 comm="sshd" scontext=unconfined_u:system_r:sshd_sftpd_t:s0-s0:c0.c1023 tcontext=unconfined_u:system_r:sshd_t:s0-s0:c0.c1023 tclass=process
type=SYSCALL msg=audit(1312471372.243:144556): arch=c000003e syscall=61 success=no exit=-13 a0=ffffffffffffffff a1=7fffb9b3671c a2=1 a3=0 items=0 ppid=27226 pid=27253 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=12614 comm="sshd" exe="/usr/sbin/sshd" subj=unconfined_u:system_r:sshd_t:s0-s0:c0.c1023 key=(null)

Comment 38 Jan F. Chadima 2011-08-04 17:03:32 UTC

Yes add it.
The sshd_sftp_t is a context compatibnle with both partially sshd and sftp.
It is used as intermediate (pty alocation) in sshd in case of ssh.
It is used as sftpd in case of sftp.

Comment 39 Miroslav Grepl 2011-08-04 21:09:07 UTC

Well, but the problem is you end up in sshd_t domain if you only use 

Subsystem internal-sftp

definition. But you should end up in sftpd_t domain. 

Miroslav, 
does it work in permissive mode?

Comment 40 Jan F. Chadima 2011-08-08 03:12:23 UTC

This is technically impossible. The decision ssh/sftp is much more later than the last ability to change context.

The server does not know if client will ask for ssh or sftp (and theoretically may ask both in different channels) in the time of context change,

The context sshd_sftp_t should allow pty allocation as well full home access.

Comment 45 Miroslav Vadkerti 2011-08-15 14:46:17 UTC

I think ON_QA state of this bug is misleading. We still don't know what the fix will be here exactly

Comment 46 Miroslav Vadkerti 2011-08-16 08:17:27 UTC

Moving to ASSIGNED. This bug will need more discussion between the developers to find a proper solution. The current solution doesn't pass testing, thus ON_QA state is clearly wrong.

Comment 47 Jan F. Chadima 2011-08-25 21:32:02 UTC

Code changed according to Dan Walsh's proposal.

Comment 52 errata-xmlrpc 2011-12-06 09:55:56 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-2011-1551.html

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