Correction of previous message, just noticed -:
I do not see (maybe it is my failure) cases where pam_faillock and
screensavers work correctly - only issues/mails where it is broken.
This should be pam_tally2, not faillock! Hopefully you guessed this
mistake rather than scratching your head!
On Tue, Jun 7, 2016 at 8:31 PM, Jason Newton <nevion(a)gmail.com> wrote:
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.
On Fri, Jun 3, 2016 at 12:22 PM, Thorsten Kukuk <kukuk(a)suse.de> 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 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(a)opensuse.org
To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org