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:
Created attachment 1373368 [details] /var/log/proftpd/sftp.log
Created attachment 1373369 [details] journalctl -f -u proftpd
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.
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
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
Created attachment 1389716 [details] proftpd configuration
Created attachment 1389717 [details] errors from audit.log
Created attachment 1389718 [details] from audit2allow
Created attachment 1389719 [details] from audit2allow
Created attachment 1389720 [details] output of "semodule -i my-proftpd.pp"
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.
Created attachment 1390305 [details] ausearch -i -c proftpd
The test from yesterday was in enforcing mode. Today I switched to permissive mode. To me it looks the same.
Created attachment 1390308 [details] ausearch -i -c proftpd another test in permissive mode
Very strange. Maybe running it via strace might be more revealing? http://blog.siphos.be/2013/04/using-strace-to-troubleshoot-selinux-problems/
Created attachment 1390540 [details] strace sftp -P 10022 localhost
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.
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?
(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".
Created attachment 1390589 [details] strace -p <pid-of-proftpd>
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.
Created attachment 1391114 [details] strace -f -p <pid-of-proftpd>
Comment on attachment 1391114 [details] strace -f -p <pid-of-proftpd> enforcing mode
Created attachment 1391115 [details] strace -f -p <pid-of-proftpd> permissive mode
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
Created attachment 1391689 [details] strace -f -p <pid-of-proftpd> enforcing mode
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").
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.
Created attachment 1392265 [details] default config, public key, enforcing mode
Created attachment 1392266 [details] default config, public key, permissive mode
Created attachment 1392267 [details] default config, password, enforcing mode
Created attachment 1392268 [details] default config, password, permissive mode
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.
Clarification to 1.: What I wanted to say is: with my original configuration login with password worked even with enforcing mode.
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?
I tried. The behaviour is the same. My login is rejected and no entry in the audit.log file why this is the case.
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.
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.
No - I just use proftpd as it is. The effect is the same on two Fedora 27 machines I have tested.
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.
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
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
(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.
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.
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.
This is still unresolved upstream. https://github.com/proftpd/proftpd/issues/659
This bug appears to have been reported against 'rawhide' during the Fedora 30 development cycle. Changing version to '30.
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.
This bug appears to have been reported against 'rawhide' during the Fedora 33 development cycle. Changing version to 33.
This message is a reminder that Fedora 33 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora 33 on 2021-11-30. 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 '33'. 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 33 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.
This bug appears to have been reported against 'rawhide' during the Fedora 36 development cycle. Changing version to 36.
This message is a reminder that Fedora Linux 36 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora Linux 36 on 2023-05-16. 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 'version' of '36'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, change the 'version' to a later Fedora Linux version. Note that the version field may be hidden. Click the "Show advanced fields" button if you do not see it. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora Linux 36 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 Linux, you are encouraged to change the 'version' to a later version prior to this bug being closed.
Maybe I should close this as UPSTREAM since https://github.com/proftpd/proftpd/issues/659 would need to be addressed to get this working? A similar issue has been reported recently: https://github.com/proftpd/proftpd/issues/1658
Since the latest proftpd is packaged for latest Fedora, the "CLOSED UPSTREAM" category could be used to close this bug https://docs.fedoraproject.org/en-US/quick-docs/bugzilla/ UPSTREAM: Used by maintainers to indicate that a bug is expected to be fixed upstream and naturally rolled into Fedora Linux in a subsequent update.
Fedora Linux 36 entered end-of-life (EOL) status on 2023-05-16. Fedora Linux 36 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora Linux please feel free to reopen this bug against that version. Note that the version field may be hidden. Click the "Show advanced fields" button if you do not see the version field. If you are unable to reopen this bug, please file a new report against an active release. Thank you for reporting this bug and we are sorry it could not be fixed.