Re: login.conf: passwordtime not enforced?
On 7/14/10, Fernan Aguero fernan.agu...@gmail.com wrote: On Wed, Jul 14, 2010 at 1:25 PM, b. f. bf1...@googlemail.com wrote: On 7/14/10, Fernan Aguero fernan.agu...@gmail.com wrote: ... 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? Yes, I meant with passwd(1). After some preliminaries, passwd(1) hands the task over to pam(3), in particular pam_sm_chauthtok(3) of pam_unix(8). This in turn uses the pw_* routines of libutil, contained in /usr/src/lib/libutil/pw_util.c. The pw_* use various libc functions and pwd_mkdb(8). The handling of the reserved capabilities minpasswordlen, mixpasswordcase, passwordtime, etc. needs at least to be in pam(3), for when you are prompted to reset your password, and should probably be implemented in the other utilities that don't use pam(3), like chpass(1), pw(8), and the vipw(8) consistency checks. It looks like passwd(1) used to deal with these capabilities directly, but in April 2002 it was gutted and turned into a front-end for pam(3), and some of the options-handling fell by the wayside. In Feb. 2010, in response to http://www.FreeBSD.org/cgi/query-pr.cgi?pr=bin/93310 des@, who is responsible for pam(3), added passwordtime-handling in: http://svn.freebsd.org/viewvc/base?view=revisionrevision=203377 At the time, he announced that it would be merged, at least into 8-STABLE (and subsequently into 8.1), in one week. He never performed this merge: I assume that he forgot. So unfortunately it looks as if you will have to manually set password expiration times. You could do this, for example, with vipw(8); or with pw(8) and either a -p argument or a password_days entry in pw.conf(5). Or you could add the patch from the above PR to your system pam_unix(8) sources and rebuild them, or update to 9-CURRENT (which is what I am using). I'm guessing that some of the other reserved options are neglected as well. You could enforce them manually, or patch pam_unix(8), chpass(1), pw(8), and vipw(8). If you do so, you should submit PRs with your patches, in the hopes that someone will reintroduce them into the base-system utilities. Ironically, the stripped-down /usr/src/release/picobsd/tinyware/passwd/local_passwd.c still handles some of them -- you could look at that for ideas. Incidentally, If I were you, I would update at least to the latest stable release of FreeBSD, unless you are constrained to use the earlier releases for some work-related reason. b. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: login.conf: passwordtime not enforced?
On Tue, Jul 13, 2010 at 10:19 PM, b. f. bf1...@googlemail.com wrote: after reading some docs about hardening freebsd installations, I decided to enforce password expiration after 90days. I've added the corresponding line to /etc/login.conf and ... after quite some time (way more than 3 months already!) nothing happens ... If you want help, you'll have to be more specific. Thanks bf1783, I'm sorry about that. My apologies. I just assumed that you assumed that I was doing the right thing(TM). :) Exactly what changes did you make to login.conf, in what sections? I've changed only the default login class, and added and/or changed these lines: :passwd_format=blf:\ :minpasswordlen=8:\ :mixpasswordcase=true:\ :passwordtime=90d:\ :idletime=30:\ :umask=027: Did you run 'cap_mkdb /etc/login.conf' afterwards? Of course I did. Did you then reset your account passwords Of course. Now they all begin with $2a, as expected for blowfish-hashed passwds. 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. 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 ... :) Any ideas on how to enforce this? Do I have to manually use pw(1) every 90 days? No, you shouldn't have to if you use the feature properly. You'll be prompted immediately after login for a new password if your old one has expired. b. 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. 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? I guess this is the question I wanted answered in my first email. After reading, again the man page for master.passwd(5), saying that The expire field is the number of seconds from the epoch, UTC, until the account expires. It's now clear to me that i) I can do it manually, eg. by running something like %date -j -f %a %b %d %T %Z %Y `date -v+90d` +%s 1286895815 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, ii) passwd(1) fails to read the setting in login.conf and then add the corresponding expiration time (in seconds since the epoch) in /etc/master.passwd Unless, of course, I'm missing something ... after setting the expiration time to %date -j -f %a %b %d %T %Z %Y `date -v+2M` +%s 1279120340 And then waiting until this time has passed, nothing happens (I'm logging in remotely using SSH) ... no warning, no refuse to log me in, nothing. Is it at all possible to enforce password expiration times in FreeBSD? -- fernan ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: login.conf: passwordtime not enforced?
On 7/14/10, Fernan Aguero fernan.agu...@gmail.com wrote: On Tue, Jul 13, 2010 at 10:19 PM, b. f. bf1...@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. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: login.conf: passwordtime not enforced?
On Wed, Jul 14, 2010 at 1:25 PM, b. f. bf1...@googlemail.com wrote: On 7/14/10, Fernan Aguero fernan.agu...@gmail.com wrote: On Tue, Jul 13, 2010 at 10:19 PM, b. f. bf1...@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.: [fer...@localhost] ssh testacco...@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
login.conf: passwordtime not enforced?
Hi, after reading some docs about hardening freebsd installations, I decided to enforce password expiration after 90days. I've added the corresponding line to /etc/login.conf and ... after quite some time (way more than 3 months already!) nothing happens ... Just googled around, and noticed this functionality seems to be absent from the base system ... only passwd(1) seems to honor this value, but truth is, when I need to use passwd(1) it's because I want to change the password myself! There is a post that mentions that having blowfish (instead of md5) as a 'passwd_format' works ... http://www.daemonforums.org/showpost.php?s=41d1e0ba423c94357afe805dbe0b2730p=17826postcount=5 However, I wonder if it worked for the author of the post, only because he manually set the password expiry date using 'pw usermod [username] -p [date]' Any ideas on how to enforce this? Do I have to manually use pw(1) every 90 days? -- fernan PS: other references to this problem: http://markmail.org/message/f5b5o3vsyo7pcozf http://lists.freebsd.org/pipermail/freebsd-security/2008-September/004934.html ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: login.conf: passwordtime not enforced?
after reading some docs about hardening freebsd installations, I decided to enforce password expiration after 90days. I've added the corresponding line to /etc/login.conf and ... after quite some time (way more than 3 months already!) nothing happens ... If you want help, you'll have to be more specific. Exactly what changes did you make to login.conf, in what sections? Did you run 'cap_mkdb /etc/login.conf' afterwards? Did you then reset your account passwords 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? 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. Any ideas on how to enforce this? Do I have to manually use pw(1) every 90 days? No, you shouldn't have to if you use the feature properly. You'll be prompted immediately after login for a new password if your old one has expired. b. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
