Bug 729648 - In a chrooted sftp environment, selinux is preventing the users from uploading new files to their home directories.
In a chrooted sftp environment, selinux is preventing the users from uploadin...
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: selinux-policy (Show other bugs)
6.1
All Linux
high Severity high
: rc
: ---
Assigned To: Miroslav Grepl
Milos Malik
:
Depends On:
Blocks: 685060
  Show dependency treegraph
 
Reported: 2011-08-10 09:05 EDT by Miroslav Vadkerti
Modified: 2012-03-14 09:05 EDT (History)
7 users (show)

See Also:
Fixed In Version: selinux-policy-3.7.19-109.el6
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: 685060
Environment:
Last Closed: 2011-12-06 05:13:00 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Comment 1 Miroslav Grepl 2011-08-10 09:11:28 EDT
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 10:16:06 EDT
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 11:32:38 EDT
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 03:44:20 EDT
(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 07:58:21 EDT
Ok, could we discuss it tomorrow? We are back from PTO.
Comment 6 Miroslav Grepl 2011-08-23 08:05:39 EDT
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 08:06:41 EDT
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 08:26:38 EDT
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 08:48:49 EDT
Jan,
how is exactly invoked internal-sftpd?
Comment 10 Jan F. Chadima 2011-08-23 11:09:51 EDT
sh -c /path/to/sftpd

I can change it to the direct exec if you wish.
Comment 11 Miroslav Grepl 2011-08-23 14:59:12 EDT
(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 15:05:57 EDT
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 15:08:07 EDT
Jan yes do direct exec.
Comment 14 Daniel Walsh 2011-08-23 16:49:34 EDT
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 04:53:31 EDT
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 16:05:57 EDT
Fixed in selinux-policy-3.7.19-109.el6
Comment 19 errata-xmlrpc 2011-12-06 05:13:00 EST
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.