[gentoo-user] Re: CoreOS vulnerability inherited from Gentoo?

[James]

Michael Cook <mcook <at> mackal.net> writes:


> >> [1] https://coreos.com/blog/

> > Does this mean we need to do anything to improve the security of our
systems?


It's going to depend, but surely a wide audience needs to poke at this...

> I tried logging in as operator with any password, it did not work for
> me. Unsure if that's because of my SSH set up or not though. The blog
> post does however mention reverting their SSSD change did fix the issue,
> so I assume if you set up SSSD the same way they did you would have
> issues. With that being said, maybe it would be a good idea for the
> gentoo pam team to set up pambase to support SSSD and not cause issues.
> (Currently if you want to set up SSSD you are left to do it manually)


I simple went looking for a pam<*>.conf file to make a simple edit and 
then test. It took me on a journey, so I posted here, figuring one
of the others had already ferreted out the details....


Oddly, I was looking at DPI (deep packet inspection) tools readily 
available for gentoo, to test some protocols, including ssh*.


I found nDPI and libndpi in overlays and suricata, which purports to
be able to perform deep packet inspections and is Netfilter compatible.
Since dpi can be a big drain on resources (of a single host), I was
hoping somebody had already migrated a dpi family of codes to a gentoo
cluster of some sort. Naddah. Ziltchen. Verboten! Since much of routing and
network engines have move to clusters (sdn, nvf, etc) dpi is king
of the hill for hot analytics.....


Those folks deeply into penetration (professional assessment types) means
are the best source for understanding dpi semantics. Every thing I have
found where folks are migrating dpi to clusters, these companies, projects
and experts are being snapped up by large corps,  agencies and otherwise
going 'off grid'. I'm not too sure what to make of all of this, but the pam
issue is only the tip of the berg.....ymmv.



hth,
James