[SOLVED] Hello and sFTP chroot problem

[lhiggs]

Hello, this is my first post on CentOS forums. I am new to learning linux but am very happy with it and enjoy it much more than windows! I am trying to configure an sftp site for my company and have gotten so far as configuring vsftp, generating and installing the cert (temporary until we purchase one), and connecting via an sftp client (filezilla). The problem I'm running into is trying to configure chroot to jail the user to their home directories.

In my sshd_config I have:

Subsystem sftp internal-sftp

AllowUsers sftpusers

Match group sftpusers
ChrootDirectory /sftp/%u
X11Forwarding no
ForceCommand internal-sftp

The user I am testing is testuser a member of the sftpusers group and is added in the AllowedUsers list in sshd_config.

I have the directories /sftp and /sftp/testusers with drwxr-xr-x root root permissions and the directory /sftp/testusers/incoming directory with drwxr-xr-x testuser sftpusers permissions.

When I connect with my windows filezilla client I get:

Status: Connecting to 192.168.1.90...
Response: fzSftp started
Command: open "testuser@192.168.1.90" 22
Command: Pass: **********
Status: Connected to 192.168.1.90
Status: Retrieving directory listing...
Command: pwd
Response: Current directory is: "/"
Command: ls
Status: Listing directory /
Error: Unable to open .: permission denied

The logs from /var/log/secure are:

Accepted password for testuser from 192.168.1.68 port 54054 ssh2
pam_unix(sshd:session): session opened for user testuser by (uid=0)
subsystem request for sftp
pam_unix(sshd:session): session closed for user testuser

I was previously using ftp and a virtual user internally but this server is being repurposed for sftp transfers from the web. Is Pam causing my troubles? forgive me if I sounded ignorant just there...I am only following tutorials and referencing man pages to get this working. Any direction would be greatly appreciated!

Thanks,
Luke

PS I am running CentOS 6.2, openssh-server-5.3p1-70.el6_2.2.x86_64

[gerald_clark]

Please do not confuse vsftp with sftp. They have nothing to do with each other.
Stop the vsftp service so you don't end up troubleshooting different things at different ends.

[lhiggs]

I ended up installing CentOS 6.2 on another drive and move my home directories to another separate partition/drive. I've reconfigured ssh from scratch and haven't touched vsftp and it appears my troubles are related to SELinux.

With SELinux set to permissive mode everything works fine, when enforcing I get this error in my windows ftp client:

Error: Network error: Software caused connection abort
Error: Could not connect to server

and in /var/log/secure I have:

Jun 29 08:16:29 portal sshd[1992]: Accepted password for testuser from 192.168.1.68 port 55754 ssh2
Jun 29 08:16:30 portal sshd[1992]: pam_unix(sshd:session): session opened for user testuser by (uid=0)
Jun 29 08:16:30 portal sshd[1996]: fatal: safely_chroot: stat("/extdata/"): Permission denied
Jun 29 08:16:30 portal sshd[1992]: pam_unix(sshd:session): session closed for user testuser

I have set SELinux bool ssh_chroot_rw_homedirs to on and it made no effect.

The home directory of testuser is a mounted drive: /extdata/home/testuser.

Permissions for /extdata/home and /extdata/home/testuser are: drwxr-xr-x. 3 root root
Permissions for /extdata/home/testuser/fstore are: drwxr-xr-x. 2 testuser sftpusers

I must be missing something with SELinux policies because everything seems to work as it should when it's disabled. If anyone can point me in the right direction I'd be very grateful :)

[pschaff]

See the Wiki article [url=http://wiki.centos.org/HowTos/SELinux#head-faa96b3fdd922004cdb988c1989e56191c257c01]HowTos/SELinux[/url] and particularly [url=http://wiki.centos.org/HowTos/SELinux#head-faa96b3fdd922004cdb988c1989e56191c257c01]Section 7. Creating Custom SELinux Policy Modules with audit2allow[/url].

[lhiggs]

Thank you so much, creating an semodule solved my problems!

Just to recap what I did for the benefit of others:

1) Set SELinux to permissive mode: # echo 0 >/selinux/enforce

2) Logged in via windows filezilla to sftp server and performed a series of actions (file upload, download, rename, delete, etc) to generate selinux avc logs.

3) Back on the server: # grep avc /var/audit/audit.log and discovered chroot_user_t being denied actions was the cause of my woes.

4) Created my semodule files: # grep chroot_user_t /var/log/audit/audit.log | audit2allow -M sftp_chroot_custom_pol > sftp_chroot_custom_pol.te (I just stored them in a temp directory)

5) Installed the semodule: # semodule -i sftp_chroot_custom_pol.pp

6) Set selinux back to enforcing and it works!

It took several trials and errors to to make sure selinux wasn't preventing additional actions, such as downloading files, deleting etc. This was all worked very well and only required removing and installing the custom module several times. Below is my sftp_chroot_custom_pol.te file audit2allow generated:

******************** IMPORTANT ***********************
To make this policy package active, execute:

semodule -i sftp_chroot_custom_pol.pp

[code]
user_t;
class process signal;
class file { setattr read create write getattr link unlink open };
class unix_dgram_socket { create connect };
class dir { rename search setattr read create write getattr rmdir remove_name add_name };
class chr_file { write ioctl read };
}

#============= chroot_user_t ==============
allow chroot_user_t default_t:dir { rename setattr read create write rmdir remove_name add_name };
allow chroot_user_t default_t:file { setattr read create write getattr link unlink open };
allow chroot_user_t file_t:dir { getattr search };
allow chroot_user_t ptmx_t:chr_file { read write ioctl };
allow chroot_user_t self:unix_dgram_socket { create connect };
allow chroot_user_t user_devpts_t:chr_file { read write ioctl };

#============= sshd_t ==============
allow sshd_t chroot_user_t:process signal;
[/code]
I'm assuming there are no security holes in it...

Thanks!

[pschaff]

You are welcome. Thanks for reporting back. Marking this thread [SOLVED] for posterity.