I've seen a few reports that proftpd's sftp support isn't working with SELinux in enforcing mode:
https://bugzilla.redhat.com/show_bug.cgi?id=1529576 https://github.com/proftpd/proftpd/issues/659
Using strace, it appears that proftpd is rejecting logins after failing to access /etc/shadow, but why would it be doing that at all, rather than using the unix_chkpwd helper?
Googling this, the only similar issue I saw was this: http://blog.siphos.be/2014/12/why-does-it-access-etcshadow/ but this seems to be different because ftpd policy does include auth_use_pam.
Any thoughts on this? I did try this locally and couldn't reproduce it, so it seems to be configuration/environment-specific rather than something being fundamentally wrong.
Paul.
On 03/22/2018 07:55 AM, Paul Howarth wrote:
I've seen a few reports that proftpd's sftp support isn't working with SELinux in enforcing mode:
https://bugzilla.redhat.com/show_bug.cgi?id=1529576 https://github.com/proftpd/proftpd/issues/659
Using strace, it appears that proftpd is rejecting logins after failing to access /etc/shadow, but why would it be doing that at all, rather than using the unix_chkpwd helper?
Googling this, the only similar issue I saw was this: http://blog.siphos.be/2014/12/why-does-it-access-etcshadow/ but this seems to be different because ftpd policy does include auth_use_pam.
Any thoughts on this? I did try this locally and couldn't reproduce it, so it seems to be configuration/environment-specific rather than something being fundamentally wrong.
Is it possible that proftpd is running in a chroot environment with a read-only or non-exisitent selinuxfs mount, faking libselinux into believing that SELinux is disabled (and thus pam doesn't bother trying to run unix_chkpwd when it runs with uid 0)?
On Thu, 22 Mar 2018 13:04:28 -0400 Stephen Smalley sds@tycho.nsa.gov wrote:
On 03/22/2018 07:55 AM, Paul Howarth wrote:
I've seen a few reports that proftpd's sftp support isn't working with SELinux in enforcing mode:
https://bugzilla.redhat.com/show_bug.cgi?id=1529576 https://github.com/proftpd/proftpd/issues/659
Using strace, it appears that proftpd is rejecting logins after failing to access /etc/shadow, but why would it be doing that at all, rather than using the unix_chkpwd helper?
Googling this, the only similar issue I saw was this: http://blog.siphos.be/2014/12/why-does-it-access-etcshadow/ but this seems to be different because ftpd policy does include auth_use_pam.
Any thoughts on this? I did try this locally and couldn't reproduce it, so it seems to be configuration/environment-specific rather than something being fundamentally wrong.
Is it possible that proftpd is running in a chroot environment with a read-only or non-exisitent selinuxfs mount, faking libselinux into believing that SELinux is disabled (and thus pam doesn't bother trying to run unix_chkpwd when it runs with uid 0)?
Not sure about the vagrant example in github, but the example from bz.redhat.com is a regular install, and the reporter says he says the same behaviour on both machines he's tried.
The strace logs from bz.redhat.com don't contain the string "selinux"; shouldn't there be an access to something under /sys/fs/selinux to check if SELinux is enabled?
Paul.
On 03/23/2018 05:40 AM, Paul Howarth wrote:
On Thu, 22 Mar 2018 13:04:28 -0400 Stephen Smalley sds@tycho.nsa.gov wrote:
On 03/22/2018 07:55 AM, Paul Howarth wrote:
I've seen a few reports that proftpd's sftp support isn't working with SELinux in enforcing mode:
https://bugzilla.redhat.com/show_bug.cgi?id=1529576 https://github.com/proftpd/proftpd/issues/659
Using strace, it appears that proftpd is rejecting logins after failing to access /etc/shadow, but why would it be doing that at all, rather than using the unix_chkpwd helper?
Googling this, the only similar issue I saw was this: http://blog.siphos.be/2014/12/why-does-it-access-etcshadow/ but this seems to be different because ftpd policy does include auth_use_pam.
Any thoughts on this? I did try this locally and couldn't reproduce it, so it seems to be configuration/environment-specific rather than something being fundamentally wrong.
Is it possible that proftpd is running in a chroot environment with a read-only or non-exisitent selinuxfs mount, faking libselinux into believing that SELinux is disabled (and thus pam doesn't bother trying to run unix_chkpwd when it runs with uid 0)?
Not sure about the vagrant example in github, but the example from bz.redhat.com is a regular install, and the reporter says he says the same behaviour on both machines he's tried.
The strace logs from bz.redhat.com don't contain the string "selinux"; shouldn't there be an access to something under /sys/fs/selinux to check if SELinux is enabled?
Yes, anything that links with libselinux will probe for that, e.g. $ strace ls |& grep selinux openat(AT_FDCWD, "/lib64/libselinux.so.1", O_RDONLY|O_CLOEXEC) = 3 statfs("/sys/fs/selinux", {f_type=SELINUX_MAGIC, f_bsize=4096, f_blocks=0, f_bfree=0, f_bavail=0, f_files=0, f_ffree=0, f_fsid={val=[0, 0]}, f_namelen=255, f_frsize=4096, f_flags=ST_VALID|ST_RELATIME}) = 0 statfs("/sys/fs/selinux", {f_type=SELINUX_MAGIC, f_bsize=4096, f_blocks=0, f_bfree=0, f_bavail=0, f_files=0, f_ffree=0, f_fsid={val=[0, 0]}, f_namelen=255, f_frsize=4096, f_flags=ST_VALID|ST_RELATIME}) = 0 access("/etc/selinux/config", F_OK) = 0
selinux@lists.fedoraproject.org
-
Paul Howarth -
Stephen Smalley