Bug 729648

I need to update policy and a new sshd_sftpd_t domain type because of these changes in openssh package.

Actually, the concept is wrong.

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

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.

(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.

Ok, could we discuss it tomorrow? We are back from PTO.

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:

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

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.

Jan,
how is exactly invoked internal-sftpd?

sh -c /path/to/sftpd

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

(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?

yes there is difference internal runs with context changed to sftp_sshd_t
and external get his context during exec

Jan yes do direct exec.

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;

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)

Fixed in selinux-policy-3.7.19-109.el6

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