login.conf: passwordtime not enforced?

[Fernan Aguero]

On Wed, Jul 14, 2010 at 1:25 PM, b. f. <bf1783 at googlemail.com> wrote:
> 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.
> ...

Right, I thought it was simpler than it really is ... this is getting scary.



>>> 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.

Right, should have checked before talking ... see below,

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

OK, changed this, but got mixed results, see below.

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

Sorry if I'm getting dense but do you mean 'manually' as in editing
master.passwd with vipw?
Or do you really mean 'manually with passwd(1)? My passwd(1) only
allows me to change the user password and even doing this doesn't
update the expiration time in master.passwd. Is there a hidden
functionality in passwd that allows me to set the expiration time for
the password?

BTW, this is on FreeBSD-6.4-p10. And so far all my tests fail to make
passwords expire.

But I just tested the same changes on a recent 7.3-STABLE. And:

i) the first time, passwd(1) doesn't update the expiration time in
master.passwd, I have to enter it manually using vipw
ii) using ssh and trying to log in after the expiration period makes
the system prompt for a new password, with no further explanation
about what's going on, i.e.:

[fernan at localhost] ssh testaccount at otherhost
Password:
New Password:


So, the password is getting expired. However,

iii) the 6th field in master.passwd for this account is reset to '0'
after setting the new password. This happens if I set the new password
as prompted using ssh, or if I run passwd(1) on a terminal. And,

iv) I was able to enter a 5 character password, no mixed case, all
letters, completely ignoring the other settings in the default login
class (minpasswordlen=8, mixpasswordcase=true).

> thereafter pam_unix(8) checks for expiration at login time:
> if a password has expired, you are prompted to change it,

correct in FreeBSD-7.3-STABLE

> and the new password will have the appropriate expiration time.

not in my case.

> It works for me locally, with the default security settings; I've never tried it over
> a remote connection.

which FreeBSD version are you using?

> You may have some configuration settings that
> are causing problems.  Have you tinkered with /etc/pam.d/* ?

No.

> What other configuration changes have you made?

Some mentioned in http://tuxtraining.com/2009/04/26/how-to-harden-freebsd

> After using cap_mkdb, have /etc/pwd.db and /etc/spwd.db changed?  Do they have the right
> timestamps?

After using cap_mkdb on /etc/login.conf, /etc/login.conf.db gets changed, yes.
And after editing master.passwd with vipw, all of /etc/pwd.db,
/etc/spwd.db and /etc/passwd all get changed.

Timestamps are OK and reasonable.

> Does the password change mechanism work properly if you
> are logging in locally, as opposed to remotely via ssh?

Yes in FreeBSD-7.3-STABLE. Not in 6.4.

> Are your system clocks keeping the right time?

Yes.

>> 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.

Thanks for all the help.

-- 
fernan