login.conf: passwordtime not enforced?

[b. f.]

On 7/14/10, Fernan Aguero <fernan.aguero at gmail.com> wrote:
> On Tue, Jul 13, 2010 at 10:19 PM, b. f. <bf1783 at googlemail.com> wrote:

> I'm sorry about that. My apologies. I just assumed that you assumed
> that I was doing the right thing(TM). :)

That would be a very bad assumption to make, when attempting to track
down a problem.

...

>> and check the sixth colon-delimited field in /etc/master.passwd with 'date
>> -r' for each account changed, to see if
>> the appropriate expiration date was registered?
>
> I don't quite get what 'date -r' does here ... but yes I've checked
> the 6th field in /etc/master.passwd, all accounts (regular users and
> system accounts) have a '0' in that field.

It transforms the password expiration time to a more convenient
format, for those of us who aren't counting machines.  A 0 in the
sixth field indicates that there is no expiration time, and something
is wrong.

>> Next time you make a change like this, test it with a short expiration
>> time (a minute or
>> two, say) on a non-critical account to see if works instead of waiting
>> three months to discover that it does not.
>
> I usually assume that the docs are correct, and don't go about
> checking and re-checking that everything works as expected ... unless
> not for these trivial config tweaks. Of course I've checked that the
> newly created passwords (now using blf instead of md5) worked, but I
> just assumed that the rest of the config settings for this login class
> didn't require further checking ... if the blf change worked, why not
> the rest?
>
> Do you suggest that I should now go and check if the
> 'mixpasswordcase', 'minpasswordlen', 'idletime' or the 'umask'
> settings are honored? I just hope I don't need to ... :)

The docs can be outdated, incomplete, or misinterpreted.  Or your
system could be misconfigured or broken.  How much time and energy you
put into your testing is up to you.  If you're serious about security,
you'll check your changes.  Some of the above-mentioned are fairly
easy to check.

> I just added a new class in login.conf:
>
> test:\
>         :tc=default:\
>         ::passwordtime=2m:
>
> And then added a new user 'testaccount', using adduser(1). I've
> verified that its login class was OK in /etc/master.passwd (BTW again
> the 6th field is '0'). And I never got any message about the password
> being expired, after several succesful login attempts that, obvioulsy,
> spanned more than 2 minutes.
>

Bravo. The above is more of the kind of thing that needs to be done
when trying to diagnose a problem.  But I think you want:
 test:\
    :passwordtime=2m:\
     :tc=default:

See the default login.conf and getcap(3).


> Who is responsible for filling in the password expiration time/date in
> master.passwd, according to the login class config? passwd(1)?
> adduser(1)? Myself, manually?

The first time you have to change it manually for each account, with
passwd(1); thereafter pam_unix(8) checks for expiration at login time:
if a password has expired, you are prompted to change it, and the new
password will have the appropriate expiration time.  It works for me
locally, with the default security settings; I've never tried it over
a remote connection.  You may have some configuration settings that
are causing problems.  Have you tinkered with /etc/pam.d/* ? What
other configuration changes have you made? After using cap_mkdb, have
/etc/pwd.db and /etc/spwd.db changed?  Do they have the right
timestamps?  Does the password change mechanism work properly if you
are logging in locally, as opposed to remotely via ssh?  Are your
system clocks keeping the right time?

> and entering that value into the 6th field of /etc/master.passwd. But
> then, I'll have to do this regularly using a script, because,

This shouldn't be necessary.  It would be better to try to find out
what is wrong.

> Is it at all possible to enforce password expiration times in FreeBSD?

Yes.  But it will take some patience to track down your problem.

b.