I had to use jump directives with pam_tally2, prior to my knowledge of faillock to meet requirements. As for impossible configuration - I'm happy with RHEL's, which is probably the most tricky part... it does suffer from redundant args, at least they are within a line of eachother though. auth required pam_faillock.so preauth silent audit deny=3 unlock_time=600 auth sufficient pam_unix.so nullok try_first_pass auth [default=die] pam_faillock.so authfail audit deny=3 unlock_time=600 pam-config was useless in the advanced configurations I had to apply. For screensaver handling - from the pam_faillock manpage: The individual files with the failure records are created as owned by the user. This allows pam_faillock.so module to work correctly when it is called from a screensaver I do not see (maybe it is my failure) cases where pam_faillock and screensavers work correctly - only issues/mails where it is broken. Further, even if you don't think this should be upstream... and playing devils advocate here, you may still have problems meeting approved security configurations with only pam_tally2 - this has an effect on the usage of any SUSE product in government owned systems. -Jason On Fri, Jun 3, 2016 at 4:45 AM, Thorsten Kukuk wrote:

On Thu, Jun 02, Jason Newton wrote:

...

I'd consider adding it as an update, too, to 42.1 and SP1, at least in aux repositories - preferably to updates :-).

I've spoken with the author of pam_faillock and I believe it to be superior to pam_tally2, particularly concerning handling of screensaver handling.

There is one very good reason, why the upstream PAM maintainer rejected to include this module: it is next to impossible to configure it correct. Did you look at the example, how to configure a service to use this module? The module has one big design disadvantage: it needs to be called several time in a PAM stack, and you need jump directives, depending on the result of a module. While this works with only pam_unix.so, it will be next to impossible to some more complex authentication stacks. So tools like pam-config will never support pam_faillock. The whole mess could be avoided, if pam_faillock would have not be designed under the assumption, that all PAM applications by design are broken ...

Beside I fail to see your problem with screensaver handling. pam_faillock and pam_tally2 needs both the same rights.

Thorsten

-- Thorsten Kukuk, Senior Architect SLES & Common Code Base SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

-- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

If I'm understanding you correctly, I first have to clarify when I say SUSE I'm including all "derivative" products - and both matter. I don't see what's wrong with invoking change [open]SUSE core from the community side - it's the interface I'm used to doing change with and my favorite Linux. I've seen non-upstreamable patches applied in distro, too, when there's cause. So yes, I think it's a legitimate reason for incorporation of the module, and shouldn't be considered in a negative light. I am familiar with many SUSE press releases and that SUSE Enterprise meets FIPS certification, but past that I'm not sure, although I've come across manual STIGs/benchmarks for older SLES (which use pam_tally2) - but I feel there is something here being missed. Coming at it as a linux developer who's been in the contractor ecosystem for many years now, there is a clear imbalance of Linux choice. I've come across [Open]SUSE (including both) used in contracting environments only 1 time in my career - but CentOS/RHEL have heavily dominated by more than 100 instances vs that 1. I'd like to address that lack of choice which details like this pam module contribute to - people don't want to deviate from the known working pam configs, as they're not easy to grok. And given the NIST 800-53 controls, one of these modules objectively meets those criteria more than the other. Sticklers may require you use the better module, and probably what they already know. -Jason On Fri, Jun 3, 2016 at 12:22 PM, Thorsten Kukuk wrote:

On Fri, Jun 03, Jason Newton wrote:

...

Further, even if you don't think this should be upstream... and playing devils advocate here, you may still have problems meeting approved security configurations with only pam_tally2 - this has an effect on the usage of any SUSE product in government owned systems.

Very intersting that you now arguments with the business of SUSE to get your wishes into openSUSE...

And no, we have no problems meeting approved security configurations for government owned systems, we have the needed certifications to sell even to the US government. As you could have easily found out by reading our press releases ;)

Thorsten

-- Thorsten Kukuk, Senior Architect SLES & Common Code Base SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Hi - reviving this thread with the following PR - finally got around to tackling the confusing automake error the build was giving me last year in regards to docbook and manpages. Please work with me in getting this in shipable - not that I'm the module author. It's strictly for the betterment of [open]SUSE with a technically (+objectively) better module. Hopefully it lays the ground work for other distros to follow suite (arch, gentoo, debian, ubuntu and others). The current outlook is although this module is not accepted in PAM upstream due to quibbles centering around software engineering principles and code reuse, it's not going away until the end of time and has been audited by many parties as an acceptable and required module for securing computers. If you're going to repeat the reasons why PAM upstream didn't incorporate it, I ask that you realize this is not the place to make that same decision - and that problem may be solved upstream "someday". Here it is our duty to provide real, working, solutions - and if that is a permanent stop-gap measure, we must deal with it. https://build.opensuse.org/request/show/454027 FYI original patch here: http://people.redhat.com/tmraz/pam_faillock/pam-1.2.1-faillock-with-manual.p... - I updated it to work against 1.3.0 - just some automake context difference patch couldn't compensate for at time of writing. This should also greatly improve compatibility with state of the art SCAP/automated STIG implementation for which pam_tally2 has far less (if any) support - and that is important to [open]SUSE users in the DOD/government space. -Jason -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org