Why might pam not use unix_chkpwd?

[Paul Howarth]

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.

[Stephen Smalley]

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

[Paul Howarth]

On Thu, 22 Mar 2018 13:04:28 -0400
Stephen Smalley <sds(a)tycho.nsa.gov&gt; 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.

[Stephen Smalley]

On 03/23/2018 05:40 AM, Paul Howarth wrote:
>  On Thu, 22 Mar 2018 13:04:28 -0400
>  Stephen Smalley <sds(a)tycho.nsa.gov&gt; 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