kcheckpass auth methods

[Martin Gräßlin]

Am 2017-03-12 09:39, schrieb Adriaan de Groot:
> Hi Martin,
> 
> It took a little while to sort out, but it looks like PAM on Linux and 
> PAM on
> FreeBSD take very different approaches when it comes to the PAM module 
> pam_unix
> (i.e. the local /etc/passwd or /etc/shadow checking).
> 
> Here's a note from the FreeBSD manpage of pam_unix:
> 
>                      NOTE: If pam_unix is invoked by a process that 
> does not
>                      have the privileges required to access the 
> password data-
>                      base (in most cases, this means root privileges), 
> the
>                      nullok option may cause pam_unix to allow any user 
> to log
>                      in with any password.
> 
> While the Linux manpage (I checked on OpenSUSE 42) says:
> 
>        A helper binary, unix_chkpwd(8), is provided to check the user's
>        password when it is stored in a read protected database. This 
> binary is
>        very simple and will only check the password of the user 
> invoking it.
>        It is called transparently on behalf of the user by the 
> authenticating
>        component of this module. In this way it is possible for 
> applications
>        like xlock(1) to work without being setuid-root.
> 
> In other words, on Linux the setuid bit is just pushed somewhere down 
> the
> stack.

Thanks for investigating. I can confirm the linux part that unix_chkpwd 
is used in the
stack and is setuid.

To me it means that setuid for kcheckpass is a valid setup also for PAM. 
Nothing I'm happy about as IMHO the code suffered a lot for supporting 
setuid (it tries to do as little as possible, no Qt, etc. etc. all for 
being setuid).

> 
> On Sunday 26 February 2017 09:20:48 Martin Gräßlin wrote:
>> > FreeBSD uses PAM. It also setuid's kcheckpass. I'm taking a look at
>> > what is
>> > actually needed there now (results later).
>> 
>> That's a difference to our cmake as setuid is only set when PAM is not
>> used.
>> Would be interesting to see why you need it. In case that you still 
>> need
>> it, please tell as I'm planning changes which can only go into the
>> non-setuid variant and then I would not be able to use the PAM-found 
>> as
>> condition.
> 
> Well, so we need PAM *and* setuid -- at least on the common setup where
> pam_unix is used. What kind of changes are these? Why are they 
> non-setuid
> only? (I suppose I could try compiling kcheckpass master to see what's 
> up,
> regardless).

The changes don't matter for BSD, it's the introduction of libseccomp 
(D5029).
When using seccomp we cannot fork+exec into a setuid binary. Thus the 
code is
changed to have a long living kcheckpass started prior to installing 
seccomp.
I don't trust the long living kcheckpass variant enough to use it in a 
setuid
application. Thus kcheckpass doesn't support this when being setuid. And 
we don't
use seccomp if kcheckpass is setuid or if we don't have the libseccomp 
library.
In case of BSD both those conditions will be true ;-)

Cheers
Martin