On Aug 11, 2011, [email protected] wrote: > Something I've been thinking about is the problem of giving out > fwknop access with specific username and passphrase pairs; You end > up with a lot of credentials floating around, and no way of really > expiring that access other than by manually editing access.conf.
Agreed that having the ability to specify an expiration time for each user would be a nice feature, and thanks for the discussion on this along with Sebastien and Jeff at Defcon. One kludge would be to leverage the expiration time on gpg keys, but this doesn't work for those that use SPA packets encrypted with Rijndael. Also, fwknop should be able to expire users independently of gpg anyway since many keys are set to never expire. > A simple solution would involve the following: > 1. sub SPA_check_user() should check for an expired account as well > as valid username, since we know when a username is being used. Log > the result. Just to confirm, the expiration time would be specified on a per-user basis in the access.conf file, correct? Or do you mean look for users that have been expired via a separate system authentication mechanism? > 2. need a new sub to read the expiry file list and get a list of > expired accounts by username - need to define $username_exp_list = > path to expiry list > 2.1 add an option for turning on username expiry in > /etc/fwknop/fwknop.conf > 2.2 modify fwknopd to recognize the username expiry option in the > .conf file > > 3. need a daemon to check logs and add usernames to the expiry list > (this should NOT be in the access.conf since we probably don't want > to risk writing to that file) > > I'd assume that the expiry list would need to be read on the fly > (not sure if this might create some overhead if reading large > lists) in order to make the expiry take effect as soon as a > username is expired. The performance of this should not be a large impact - definitely doable. > As a few of us discussed at defcon, there's probably a lot of > interesting features that could be added to this functionality, > such as a secure way to notify users of their blacklisting, or > combining the fwknop blacklisting with irc k-lining, and so on. The > blacklist could also enable set hours when certain profiles are > enabled or disabled. All good ideas. I've made quite a bit of progress in a private git branch for defaulting to a non-gdbm/ndbm solution (with the original behavior re-enabled with a new configure script argument). This code will be pushed to the public git repository by this weekend I think, and the 2.0 release shouldn't be too long after that. Thanks, --Mike > -- > mart > > > ------------------------------------------------------------------------------ > Get a FREE DOWNLOAD! and learn more about uberSVN rich system, > user administration capabilities and model configuration. Take > the hassle out of deploying and managing Subversion and the > tools developers use with it. > http://p.sf.net/sfu/wandisco-dev2dev > _______________________________________________ > Fwknop-discuss mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/fwknop-discuss ------------------------------------------------------------------------------ Get a FREE DOWNLOAD! and learn more about uberSVN rich system, user administration capabilities and model configuration. Take the hassle out of deploying and managing Subversion and the tools developers use with it. http://p.sf.net/sfu/wandisco-dev2dev _______________________________________________ Fwknop-discuss mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/fwknop-discuss
