[gentoo-user] Re: CoreOS vulnerability inherited from Gentoo?
Max R.D. Parmer trystero.is> writes: > > Which file contains the purported malaised default configration? > > I just want to manually inspect it and verify for myself. > /etc/pam.d/system-auth which is provided by pambase: > https://gitweb.gentoo.org/proj/pambase.git/ Huh. I looked at that and concluded it could not possibly be the problem. I went a bit deeper at coreOS and found that they are using pambase-20101024 from 2010. Double_huh. I had heard they were behind on updating may ebuilds, but that is ridiculous. Here are the details should anyone be interested:: https://github.com/coreos/coreos-overlay/commit/ 048faeb3b1b1a693dec3bdb47b127b8d71c48c13 I (previously) had high regards for CoreOS, but not keeping things current is usually the largest source of problems and sploits, imho. thx, James
Re: [gentoo-user] Re: CoreOS vulnerability inherited from Gentoo?
On Thu, Jun 2, 2016, at 06:44, James wrote: > Neil Bothwick digimed.co.uk> writes: > > > > > Does this mean we need to do anything to improve the security of our > > > systems? > > > The report seems to be saying that the problem is caused by using the > > Gentoo default config, which assumes a Gentoo environment. So it's fine > > on Gentoo. But it won't hurt to run glsa-check from time to time (my sync > > script does it every time and mails me if there's a problem). > > Which file contains the purported malaised default configration? > I just want to manually inspect it and verify for myself. /etc/pam.d/system-auth which is provided by pambase: https://gitweb.gentoo.org/proj/pambase.git/
[gentoo-user] Re: CoreOS vulnerability inherited from Gentoo?
Neil Bothwick digimed.co.uk> writes: > > Does this mean we need to do anything to improve the security of our > > systems? > The report seems to be saying that the problem is caused by using the > Gentoo default config, which assumes a Gentoo environment. So it's fine > on Gentoo. But it won't hurt to run glsa-check from time to time (my sync > script does it every time and mails me if there's a problem). Which file contains the purported malaised default configration? I just want to manually inspect it and verify for myself. curiously, James
[gentoo-user] Re: CoreOS vulnerability inherited from Gentoo?
Michael Cook 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
