Bug 1529576 - proftpd: no login with public key with selinux
Summary: proftpd: no login with public key with selinux
Keywords:
Status: ASSIGNED
Alias: None
Product: Fedora
Classification: Fedora
Component: proftpd
Version: 33
Hardware: x86_64
OS: Linux
unspecified
medium
Target Milestone: ---
Assignee: Paul Howarth
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2017-12-28 18:49 UTC by Frank Ansari
Modified: 2020-08-11 15:26 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed:
Type: Bug


Attachments (Terms of Use)
console output of sftp (running with -vvv) (2.61 KB, text/plain)
2017-12-28 18:49 UTC, Frank Ansari
no flags Details
/var/log/proftpd/sftp.log (2.30 KB, text/plain)
2017-12-28 18:49 UTC, Frank Ansari
no flags Details
journalctl -f -u proftpd (1.14 KB, text/plain)
2017-12-28 18:50 UTC, Frank Ansari
no flags Details
proftpd configuration (910 bytes, application/x-gzip)
2018-02-01 19:32 UTC, Frank Ansari
no flags Details
errors from audit.log (2.28 KB, text/plain)
2018-02-01 19:33 UTC, Frank Ansari
no flags Details
from audit2allow (156 bytes, text/plain)
2018-02-01 19:33 UTC, Frank Ansari
no flags Details
from audit2allow (928 bytes, application/octet-stream)
2018-02-01 19:34 UTC, Frank Ansari
no flags Details
output of "semodule -i my-proftpd.pp" (319 bytes, text/plain)
2018-02-01 19:34 UTC, Frank Ansari
no flags Details
ausearch -i -c proftpd (1.25 KB, text/plain)
2018-02-02 19:26 UTC, Frank Ansari
no flags Details
ausearch -i -c proftpd (770 bytes, text/plain)
2018-02-02 19:33 UTC, Frank Ansari
no flags Details
strace sftp -P 10022 localhost (13.04 KB, text/plain)
2018-02-03 13:30 UTC, Frank Ansari
no flags Details
strace -p <pid-of-proftpd> (9.96 KB, text/plain)
2018-02-03 17:21 UTC, Frank Ansari
no flags Details
strace -f -p <pid-of-proftpd> (142.94 KB, text/plain)
2018-02-04 19:14 UTC, Frank Ansari
no flags Details
strace -f -p <pid-of-proftpd> (167.00 KB, text/plain)
2018-02-04 19:16 UTC, Frank Ansari
no flags Details
strace -f -p <pid-of-proftpd> (1.16 MB, text/plain)
2018-02-05 19:30 UTC, Frank Ansari
no flags Details
default config, public key, enforcing mode (134.72 KB, text/plain)
2018-02-06 19:50 UTC, Frank Ansari
no flags Details
default config, public key, permissive mode (170.82 KB, text/plain)
2018-02-06 19:50 UTC, Frank Ansari
no flags Details
default config, password, enforcing mode (132.27 KB, text/plain)
2018-02-06 19:51 UTC, Frank Ansari
no flags Details
default config, password, permissive mode (159.97 KB, text/plain)
2018-02-06 19:51 UTC, Frank Ansari
no flags Details
runcon -u system_u -r system_r -t initrc_t -- runcon -t ftpd_t -- /usr/bin/strace /usr/sbin/proftpd -nd10 &> ~/proftpd-trace.log (143.29 KB, text/plain)
2018-03-24 00:08 UTC, marcindulak
no flags Details
runcon -u system_u -r system_r -t initrc_t -- runcon -t ftpd_t -- /usr/bin/strace /usr/sbin/proftpd -nd10 &> ~/proftpd-trace.mod_sftp_pam.log (143.87 KB, text/plain)
2018-03-24 00:09 UTC, marcindulak
no flags Details

Description Frank Ansari 2017-12-28 18:49:03 UTC
Created attachment 1373367 [details]
console output of sftp (running with -vvv)

Description of problem:
When I have SELinux in enforcing mode I cannot login to proftpd with public key.
When I put SELinux in permissive mode it works.
Strange thing is I don't see any clues in the audit.log.

Version-Release number of selected component (if applicable):
Version      : 1.3.6
Release      : 8.fc27


How reproducible:
Include something like this as "sftp.conf" to your proftpd.conf


<IfModule mod_sftp.c>
        SFTPEngine on
        Port 10022
        SFTPLog /var/log/proftpd/sftp.log

        # Configure both the RSA and DSA host keys, using the same host key
        # files that OpenSSH uses.
        SFTPHostKey /etc/ssh/ssh_host_rsa_key

        # SFTPAuthMethods password publickey
        SFTPAuthMethods publickey

        SFTPAuthorizedUserKeys file:/etc/proftpd/authorized_keys/%u

        # Enable compression
        SFTPCompression delayed
</IfModule>



Steps to Reproduce:
1. Export your ssh key with "ssh-keygen -e" and copy the result to /etc/proftpd/authorized_keys/<username>
2. Make sure SELinux is in enforcing mode.
3. sftp -vvv -P 10022 <ip_address_of_proftpd_server>
4. Check "journalctl -f -u proftpd", /var/log/proftpd/sftp.log and /var/log/audit/audit.log for any clues.

Actual results:
Login is denied.

Expected results:
Login should work.

Additional info:

Comment 1 Frank Ansari 2017-12-28 18:49:48 UTC
Created attachment 1373368 [details]
/var/log/proftpd/sftp.log

Comment 2 Frank Ansari 2017-12-28 18:50:32 UTC
Created attachment 1373369 [details]
journalctl -f -u proftpd

Comment 3 Paul Howarth 2018-01-31 12:02:08 UTC
Do you have the ftpd_full_access SELinux boolean set? I presume so, because without it, it seems that proftpd can't read the SSH host key.

However, with that boolean set, it works for me.

Comment 4 Frank Ansari 2018-01-31 19:43:48 UTC
This flag is activated. Nevertheless it does not work when SELinix is in enforcing mode.

root@bat ~]# getsebool ftpd_full_access
ftpd_full_access --> on

Comment 5 Paul Howarth 2018-02-01 10:37:59 UTC
What are the file contexts on /etc/proftpd/ and everything underneath it?

You can try turning off the dontaudit rules and trying the ftp session again.

# semodule -DB

There will be a lot of noise in the audit logs but some should relate to ftpd_t

You can turn the dontaudit rules back on later:

# semodule -B

Comment 6 Frank Ansari 2018-02-01 19:32:23 UTC
Created attachment 1389716 [details]
proftpd configuration

Comment 7 Frank Ansari 2018-02-01 19:33:03 UTC
Created attachment 1389717 [details]
errors from audit.log

Comment 8 Frank Ansari 2018-02-01 19:33:33 UTC
Created attachment 1389718 [details]
from audit2allow

Comment 9 Frank Ansari 2018-02-01 19:34:01 UTC
Created attachment 1389719 [details]
from audit2allow

Comment 10 Frank Ansari 2018-02-01 19:34:47 UTC
Created attachment 1389720 [details]
output of "semodule -i my-proftpd.pp"

Comment 11 Paul Howarth 2018-02-01 19:58:03 UTC
Was that in enforcing mode or permissive? It'd need to be permissive to see all of what it's trying to do that's not allowed. All I can see from your output is an attempt to read /etc/shadow, which would never be allowed.

For my own testing I just made the following changes to the default proftpd.conf in the package:

--- proftpd.conf.orig	2017-09-20 11:28:10.000000000 +0100
+++ proftpd.conf	2018-01-31 11:58:41.389185662 +0000
@@ -210,7 +210,7 @@
 #
 # Support for the SSH2, SFTP, and SCP protocols, for secure file transfer over
 # an SSH2 connection (http://www.castaglia.org/proftpd/modules/mod_sftp.html)
-#   LoadModule mod_sftp.c
+   LoadModule mod_sftp.c
 #
 # Use PAM to provide a 'keyboard-interactive' SSH2 authentication method for
 # mod_sftp (http://www.castaglia.org/proftpd/modules/mod_sftp_pam.html)
@@ -356,6 +356,41 @@
 
 </Global>
 
+# SFTP configuration on port 10022
+<IfModule mod_sftp.c>
+  <VirtualHost 0.0.0.0>
+
+    Port 10022
+    SFTPEngine On
+
+    # Configure the RSA, DSA, and ECDSA host keys, using the same host key
+    # files that OpenSSH uses.
+    SFTPOptions InsecureHostKeyPerms
+    SFTPHostKey /etc/ssh/ssh_host_rsa_key
+    SFTPHostKey /etc/ssh/ssh_host_ecdsa_key
+
+    # Remove "password" for key-only access
+    #SFTPAuthMethods password publickey
+    SFTPAuthMethods publickey
+
+    # Configure the file used for comparing authorized public keys of users.
+    #SFTPAuthorizedUserKeys file:~/.ssh/sftp_authorized_keys
+    SFTPAuthorizedUserKeys file:/etc/proftpd/authorized_keys/%u
+
+    # Enable compression
+    SFTPCompression delayed
+
+    # Allow the same number of authentication attempts as OpenSSH.
+    #
+    # It is recommended that you explicitly configure MaxLoginAttempts
+    # for your SSH2/SFTP instance to be higher than the normal
+    # MaxLoginAttempts value for FTP, as there are more ways to authenticate
+    # using SSH2.
+    MaxLoginAttempts 6
+
+  </VirtualHost>
+</IfModule>
+
 # A basic anonymous configuration, with an upload directory
 # Enable this with PROFTPD_OPTIONS=-DANONYMOUS_FTP in /etc/sysconfig/proftpd
 <IfDefine ANONYMOUS_FTP>

With that configuration, it worked for me in enforcing mode.

Comment 12 Frank Ansari 2018-02-02 19:26:30 UTC
Created attachment 1390305 [details]
ausearch -i -c proftpd

Comment 13 Frank Ansari 2018-02-02 19:32:22 UTC
The test from yesterday was in enforcing mode.

Today I switched to permissive mode.

To me it looks the same.

Comment 14 Frank Ansari 2018-02-02 19:33:29 UTC
Created attachment 1390308 [details]
ausearch -i -c proftpd

another test in permissive mode

Comment 15 Paul Howarth 2018-02-02 20:11:33 UTC
Very strange. Maybe running it via strace might be more revealing?

http://blog.siphos.be/2013/04/using-strace-to-troubleshoot-selinux-problems/

Comment 16 Frank Ansari 2018-02-03 13:30:32 UTC
Created attachment 1390540 [details]
strace sftp -P 10022 localhost

Comment 17 Paul Howarth 2018-02-03 14:27:14 UTC
It's the proftpd daemon you'll need to trace, not the sftp client. Attach to it after systemd has started it, so it'll run in the right SELinux context. Try it both permissive and enforcing.

Comment 18 Frank Ansari 2018-02-03 14:42:35 UTC
When I run "proftpd --nodaemon" instead of starting it with systemd I can connect in enforcing mode.

How do I have to do the strace with systemd?

Comment 19 Paul Howarth 2018-02-03 15:50:42 UTC
(In reply to Frank Ansari from comment #18)
> When I run "proftpd --nodaemon" instead of starting it with systemd I can
> connect in enforcing mode.

It's not confined when you do it like that.

> How do I have to do the strace with systemd?

I'd start it as usual and then attach strace to the already-running process using "strace -p PID-of-proftpd".

Comment 20 Frank Ansari 2018-02-03 17:21:47 UTC
Created attachment 1390589 [details]
strace -p <pid-of-proftpd>

Comment 21 Paul Howarth 2018-02-04 11:31:50 UTC
Ah, this trace is that of the parent proftpd daemon but doesn't contain a trace of the child thread created to handle your connection. You probably need to use the "-f" option in strace to follow child processes.

It would also be helpful to see traces for both permissive and enforcing modes to try to see what's different.

Comment 22 Frank Ansari 2018-02-04 19:14:46 UTC
Created attachment 1391114 [details]
strace -f -p <pid-of-proftpd>

Comment 23 Frank Ansari 2018-02-04 19:15:23 UTC
Comment on attachment 1391114 [details]
strace -f -p <pid-of-proftpd>

enforcing mode

Comment 24 Frank Ansari 2018-02-04 19:16:08 UTC
Created attachment 1391115 [details]
strace -f -p <pid-of-proftpd>

permissive mode

Comment 25 Paul Howarth 2018-02-05 11:13:19 UTC
Looking at these traces, I don't think the issue is anything to do with use of public keys; I can see them being opened and read in both permissive and enforcing modes.

Instead, I think it's that your users are just being stored in the regular /etc/passwd|shadow files, and SELinux is blocking attempted reads of /etc/shadow, which is what showed up in the audit logs earlier.

I think you need to work around this by using PAM to do the authentication, as SELinux allows that:

# Use pam to authenticate (default) and be authoritative
AuthPAMConfig                   proftpd
AuthOrder                       mod_auth_pam.c* mod_auth_unix.c

Comment 26 Frank Ansari 2018-02-05 19:30:20 UTC
Created attachment 1391689 [details]
strace -f -p <pid-of-proftpd>

enforcing mode

Comment 27 Frank Ansari 2018-02-05 19:34:01 UTC
This is unclear to me for two reasons:

1.
# Use pam to authenticate (default) and be authoritative
AuthPAMConfig                   proftpd
AuthOrder                       mod_auth_pam.c* mod_auth_unix.c

These lines appear in my /etc/proftpd.conf.

2.
When I login via password (I set "SFTPAuthMethods password" in my config for doing this) the login works as you can see from my latest trace (password replaced by "xxx").

Comment 28 Paul Howarth 2018-02-06 10:22:19 UTC
Hmm, that's confusing.

Can you try testing with the default configuration file from the package plus the changes in Comment#11? That worked for me in enforcing mode. If it works for you, maybe we can figure out what it is that's making the difference.

Comment 29 Frank Ansari 2018-02-06 19:50:04 UTC
Created attachment 1392265 [details]
default config, public key, enforcing mode

Comment 30 Frank Ansari 2018-02-06 19:50:39 UTC
Created attachment 1392266 [details]
default config, public key, permissive mode

Comment 31 Frank Ansari 2018-02-06 19:51:14 UTC
Created attachment 1392267 [details]
default config, password, enforcing mode

Comment 32 Frank Ansari 2018-02-06 19:51:55 UTC
Created attachment 1392268 [details]
default config, password, permissive mode

Comment 33 Frank Ansari 2018-02-06 19:54:01 UTC
The behaviour for public key is the same.

But I found two differences to my original config with password:

1.
Login does not work in enforcing mode (as before).

2.
I cannot find my password in the strace file.

Comment 34 Frank Ansari 2018-02-06 19:55:47 UTC
Clarification to 1.: What I wanted to say is: with my original configuration login with password worked even with enforcing mode.

Comment 35 Paul Howarth 2018-03-20 15:25:57 UTC
Hmm, just started looking at this again and can't get it to work at all now; problems with sftp key exchange:
https://github.com/proftpd/proftpd/issues/674

If you're still having the same symptoms, can you try loading and enabling mod_sftp_pam?

Comment 36 Frank Ansari 2018-03-21 19:37:31 UTC
I tried. The behaviour is the same. My login is rejected and no entry in the audit.log file why this is the case.

Comment 37 Paul Howarth 2018-03-22 09:08:29 UTC
PAM is trying to access /etc/passwd and /etc/shadow directly rather than via the helper unix_chkpwd, and I don't really understand why.

Comment 38 Paul Howarth 2018-03-22 18:14:34 UTC
You're not running this in a chroot or virtualized environment with no selinuxfs mount visible are you? I don't think you are from the details you've posted but I'd like to be sure.

Comment 39 Frank Ansari 2018-03-22 19:16:22 UTC
No - I just use proftpd as it is. The effect is the same on two Fedora 27 machines I have tested.

Comment 40 Paul Howarth 2018-03-23 13:54:25 UTC
Let's see if we can capture the start-up of the daemon too. For that, we'll need a custom SELinux policy module that will let us trace the process:

Create a file trace_proftpd.te:
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
policy_module(trace_proftpd, 0.1)

# After installing this module, can trace proftpd in enforcing mode like this:
# runcon -u system_u -r system_r -t initrc_t -- runcon -t ftpd_t -- /usr/bin/strace /usr/sbin/proftpd -nd10 -X &> ~/proftpd-trace.log

require {
	type ftpd_t;
	type ftpd_exec_t;
	class process ptrace;
	class capability sys_ptrace;
	class file execute_no_trans;
}

#============= ftpd_t ==============
allow ftpd_t ftpd_exec_t:file execute_no_trans;
allow ftpd_t self:capability sys_ptrace;
allow ftpd_t self:process ptrace;
corecmd_bin_entry_type(ftpd_t)
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>

If you have the selinux-policy-devel package installed, you should be able to compile this like so:
# make -f /usr/share/selinux/devel/Makefile trace_proftpd.pp

And then load the module:
# semodule -i trace_proftpd.pp

Then trace the process:
# runcon -u system_u -r system_r -t initrc_t -- runcon -t ftpd_t -- /usr/bin/strace /usr/sbin/proftpd -nd10 -X &> ~/proftpd-trace.log

The resulting trace log might shed some light on why pam is not trying to use the unix_chkpwd helper.

Comment 41 marcindulak 2018-03-24 00:08:25 UTC
Created attachment 1412351 [details]
runcon -u system_u -r system_r -t initrc_t -- runcon -t ftpd_t -- /usr/bin/strace /usr/sbin/proftpd -nd10 &> ~/proftpd-trace.log

Comment 42 marcindulak 2018-03-24 00:09:40 UTC
Created attachment 1412352 [details]
runcon -u system_u -r system_r -t initrc_t -- runcon -t ftpd_t -- /usr/bin/strace /usr/sbin/proftpd -nd10 &> ~/proftpd-trace.mod_sftp_pam.log

Comment 43 marcindulak 2018-03-24 00:12:07 UTC
(In reply to Paul Howarth from comment #40)
> Let's see if we can capture the start-up of the daemon too. For that, we'll
> need a custom SELinux policy module that will let us trace the process:
> 
> Create a file trace_proftpd.te:
> <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
> policy_module(trace_proftpd, 0.1)
> 
> # After installing this module, can trace proftpd in enforcing mode like
> this:
> # runcon -u system_u -r system_r -t initrc_t -- runcon -t ftpd_t --
> /usr/bin/strace /usr/sbin/proftpd -nd10 -X &> ~/proftpd-trace.log
> 
> require {
> 	type ftpd_t;
> 	type ftpd_exec_t;
> 	class process ptrace;
> 	class capability sys_ptrace;
> 	class file execute_no_trans;
> }
> 
> #============= ftpd_t ==============
> allow ftpd_t ftpd_exec_t:file execute_no_trans;
> allow ftpd_t self:capability sys_ptrace;
> allow ftpd_t self:process ptrace;
> corecmd_bin_entry_type(ftpd_t)
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> 
> If you have the selinux-policy-devel package installed, you should be able
> to compile this like so:
> # make -f /usr/share/selinux/devel/Makefile trace_proftpd.pp
> 
> And then load the module:
> # semodule -i trace_proftpd.pp
> 
> Then trace the process:
> # runcon -u system_u -r system_r -t initrc_t -- runcon -t ftpd_t --
> /usr/bin/strace /usr/sbin/proftpd -nd10 -X &> ~/proftpd-trace.log
> 
> The resulting trace log might shed some light on why pam is not trying to
> use the unix_chkpwd helper.

I did not find -X option in CentOS7 proftpd-1.3.5e-4.el7.x86_64.
Attached are the outputs without (proftpd-trace.log) and with (proftpd-trace.mod_sftp_pam.log) mod_sftp_pam enabled.

Comment 44 Paul Howarth 2018-03-26 13:59:59 UTC
The first one fails to find the root user account as before.

The second does find the root account (progress, yay!) but then segfaults, which may be a similar issue to what I'm seeing in Comment#35.

Comment 45 Ben Cotton 2018-11-27 16:28:20 UTC
This message is a reminder that Fedora 27 is nearing its end of life.
On 2018-Nov-30  Fedora will stop maintaining and issuing updates for
Fedora 27. It is Fedora's policy to close all bug reports from releases
that are no longer maintained. At that time this bug will be closed as
EOL if it remains open with a Fedora  'version' of '27'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 27 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

Comment 46 Paul Howarth 2018-11-27 18:46:05 UTC
This is still unresolved upstream.

https://github.com/proftpd/proftpd/issues/659

Comment 47 Ben Cotton 2019-02-19 17:11:48 UTC
This bug appears to have been reported against 'rawhide' during the Fedora 30 development cycle.
Changing version to '30.

Comment 48 Ben Cotton 2020-04-30 22:17:22 UTC
This message is a reminder that Fedora 30 is nearing its end of life.
Fedora will stop maintaining and issuing updates for Fedora 30 on 2020-05-26.
It is Fedora's policy to close all bug reports from releases that are no longer
maintained. At that time this bug will be closed as EOL if it remains open with a
Fedora 'version' of '30'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 30 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

Comment 49 Ben Cotton 2020-08-11 15:26:06 UTC
This bug appears to have been reported against 'rawhide' during the Fedora 33 development cycle.
Changing version to 33.


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