Re: [Otpasswd-talk] Using OTP to kind of fix MITM.

[Hannes Beinert]

On Tue, Dec 22, 2009 at 17:57, Tomasz bla Fortuna <address@hidden> wrote:
> Dnia Tue, 22 Dec 2009 17:49:20 -0600 Hannes Beinert <address@hidden> 
> napisał(a):
>>
>> However, you do make me wonder whether the PAM module could be
>> designed to have a "permissive" or "optional" mode.  Namely, if the
>> user has no userland PPP configuration, the module would just return a
>> successful authentication.  If there *is* a userland configuration,
>> then it would work normally.  In this case, the sysadmin would be
>> making the policy decision that PPP is optional, and if a user chooses
>> to increase his/her account's security at the cost of convenience,
>> then so be it.
>>
>> The other advantage of this system would be that it's even conceivable
>> that a distro could ship with this module installed in the default PAM
>> stacks.  There would be no change in the default system behavior
>> unless a user takes some proactive steps.
>>
>> I kinda like this option.
>
> Done already. (-; You just add otpasswd into PAM as 'required' module
> (pam_unix being before with 'requisite' setting) and in config there's
> ENFORCE option which is by default set to 0, so module will return
> PAM_IGNORE if user is not in key database (global, local or whatever)

Forgive me, I misunderstood the function of the ENFORCED keyword.  It
sounded as though it would cause the OT password to be ignored.  I
should've checked the code.  :-)

In any event...  nice!  I think that's a very nice feature.

> Still having a user-db makes the program not suid/sgid which might be
> thought as a safer. (it's never set-uid root!) I personally think that
> it can be SUID/SGID by default because there's kind of little code
> which will get run with higher privilage when 'user-db' is selected and
> this would make the installation more 'standard':

Since it is not suid root, I would agree.

One way to create a privilege separation would be to design this as a
client-server model.  The server would have privilege, and would
perform any operation requiring privilege at the request of the
client.  This would force all transactions to be squeezed through an
easily delimited and scrutinized IPC channel.  The client wouldn't
have to be written as carefully this way.  The disadvantage to this is
the overhead, of course.  I'm unsure if this situation calls for such
an approach, though.

>        ret = chdir("/");
>        if (ret != 0) {
>                printf("Unable to change directory to /\n");
>                exit(EXIT_FAILURE);
>        }

Another technique I've seen is to do something like this:

     mkdir("/tmp/RANDOM")
     chdir("/tmp/RANDOM")
     rmdir("/tmp/RANDOM")

This foils many potential abuses.  Some distros have a permanent empty
directory for applications to use, but I think I'm less keen on that.
I think I'd rather make my own random directory in /tmp, with or
without the rmdir.

You have/are putting in a long day, Tomasz!  I just resync'ed the
repo, and you've been really busy since last time I looked.

Hannes.