Bug 729648 - 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: selinux-policy
Version: 6.1
Hardware: All
OS: Linux
high
high
Target Milestone: rc
: ---
Assignee: Miroslav Grepl
QA Contact: Milos Malik
URL:
Whiteboard:
Depends On:
Blocks: 685060
TreeView+ depends on / blocked
 
Reported: 2011-08-10 13:05 UTC by Miroslav Vadkerti
Modified: 2018-11-26 17:06 UTC (History)
7 users (show)

Fixed In Version: selinux-policy-3.7.19-109.el6
Doc Type: Bug Fix
Doc Text:
Clone Of: 685060
Environment:
Last Closed: 2011-12-06 10:13:00 UTC
Target Upstream Version:


Attachments (Terms of Use)


Links
System ID Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2011:1511 normal SHIPPED_LIVE selinux-policy bug fix and enhancement update 2011-12-06 00:39:17 UTC

Comment 1 Miroslav Grepl 2011-08-10 13:11:28 UTC
I need to update policy and a new sshd_sftpd_t domain type because of these changes in openssh package.

Comment 2 Miroslav Grepl 2011-08-10 14:16:06 UTC
Actually, the concept is wrong.

Jan,
we need to talk on irc with Dan. Are you ok either later today or tomorrow?

Comment 3 Daniel Walsh 2011-08-10 15:32:38 UTC
Yes lets discuss the best solution for this.  It might be to finally break sshd into two labels, one that listens on the network and one that can manipulate the users directory.

Comment 4 Jan F. Chadima 2011-08-12 07:44:20 UTC
(In reply to comment #2)
> Actually, the concept is wrong.
> 
> Jan,
> we need to talk on irc with Dan. Are you ok either later today or tomorrow?

Ok ping me when.

Comment 5 Miroslav Grepl 2011-08-22 11:58:21 UTC
Ok, could we discuss it tomorrow? We are back from PTO.

Comment 6 Miroslav Grepl 2011-08-23 12:05:39 UTC
With this policy

---

policy_module(mysftp, 1.0)

type sftpd_exec_t;
files_type(sftpd_exec_t)

type sshd_sftpd_t;
domain_type(sshd_sftpd_t)
role system_r types sshd_sftpd_t;

permissive sshd_sftpd_t;

allow sshd_t sshd_sftpd_t:process setexec;
allow sshd_t sshd_sftpd_t:process dyntransition;

---

we have the following situation:

Comment 7 Miroslav Grepl 2011-08-23 12:06:41 UTC
1.

# ssh mgrepl@localhost

you will end up within sshd_sftpd_t domain.


2.

#Subsystem      sftp    /usr/libexec/openssh/sftp-server

userdom_spec_domtrans_unpriv_users(sshd_sftpd_t)
domtrans_pattern(unpriv_userdomain, sftpd_exec_t, sftpd_t)

# sftp mgrepl@localhost

I am able to end up within sftpd_t

# staff_u:staff_r:sftpd_t:s0      27520 ?        00:00:00 sftp-server


3. 

# Subsystem       sftp    internal-sftp

You will end up

# staff_u:staff_r:staff_t:s0      27663 pts/2    00:00:00 sftp

Comment 8 Miroslav Grepl 2011-08-23 12:26:38 UTC
ad 1)

It means, you set the "sshd_sftpd_t" label as starting context. So you don't have the difference between ssh and sftp.


ad 3)

I guess the problem why we end up within userdomain is the following rule

userdom_spec_domtrans_unpriv_users(sshd_t)

since 

"sh -c command" is used in openssh.

Comment 9 Miroslav Grepl 2011-08-23 12:48:49 UTC
Jan,
how is exactly invoked internal-sftpd?

Comment 10 Jan F. Chadima 2011-08-23 15:09:51 UTC
sh -c /path/to/sftpd

I can change it to the direct exec if you wish.

Comment 11 Miroslav Grepl 2011-08-23 18:59:12 UTC
(In reply to comment #10)
> sh -c /path/to/sftpd
> 
> I can change it to the direct exec if you wish.

I thought there is a difference between internal and external?

Comment 12 Jan F. Chadima 2011-08-23 19:05:57 UTC
yes there is difference internal runs with context changed to sftp_sshd_t
and external get his context during exec

Comment 13 Daniel Walsh 2011-08-23 19:08:07 UTC
Jan yes do direct exec.

Comment 14 Daniel Walsh 2011-08-23 20:49:34 UTC
After long discussion on the list I think we need to do the following.

We have three different situations.

pam_stack is called and will setexeccon()

if (chroot)
  setexeccon(NULL) # Clear execcon 
  setcon("system_u:system_r:chroot_user_t:s0")
  chroot()
  setuid()
  # In either case where you do internal-sftp or login start a user shell, the context will run chroot_user_t, which will be allowed to read/write/exec all user content.
else
  if (internal-sftp)
            setuid()
            getexecon(&scon)
            setcon(scon)
            freecon(scon)
  else
      exech(sh) # In which case SELinux will perform the original transition to user type setup in pam
  fi

fi

In the case where we are not doing chroot the exec of the shell will work correctly as it always has.

Miroslav has to write a policy type for chroot_user_t;

Comment 15 Miroslav Grepl 2011-08-26 08:53:31 UTC
With a new openssh package:

1. I use chroot together with internal-sftp

# sftp test@RHEL6

# ps -efZ |grep sftp
unconfined_u:system_r:chroot_user_t:s0-s0:c0.c1023 test 484 483  0 10:40 ? 00:00:00 sshd: test@internal-sftp

So it looks good.

2. ssh mgrepl@RHEL6

# ps -efZ |grep ssh
unconfined_u:system_r:sshd_t:s0-s0:c0.c1023 root 332 1  0 10:32 ?      00:00:00 /usr/sbin/sshd
unconfined_u:system_r:sshd_t:s0-s0:c0.c1023 root 489 332  1 10:42 ?    00:00:00 sshd: mgrepl [priv]
unconfined_u:system_r:sshd_t:s0-s0:c0.c1023 mgrepl 493 489  0 10:42 ?  00:00:00 sshd: mgrepl@pts/0

# id -Z
staff_u:staff_r:staff_t:s0

Looks good.

3. I enabled internal-sftp without chroot and we have issue


#============= sshd_t ==============
#!!!! This avc is a constraint violation.  You will need to add an attribute to either the source or target type to make it work.
#Contraint rule: 
allow sshd_t staff_t:process dyntransition;


because of 

 if (internal-sftp)
            setuid()
            getexecon(&scon)
            setcon(scon)

Comment 16 Miroslav Grepl 2011-08-31 20:05:57 UTC
Fixed in selinux-policy-3.7.19-109.el6

Comment 19 errata-xmlrpc 2011-12-06 10:13:00 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-1511.html


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