Thanks, so ABRT is raised when a FIPS-enabled library (e.g. openssl) catches an attempt to use non-approved cipher.
Do you have some examples how such an abort looks like with and without GDB? Why I am asking. Once we start supporting FIPS, I wonder how we are gonna provide support for users and customers who are in FIPS mode and "someting is breaking apart". Installing GDB would be really the last thing to do. I wonder if there is any chance of using SystemTap or even ABRT (Automatic Bug Reporting Tool) data (stacktrace with debug info, core dump). Trying to find a workflow which we will use for retrospective analysis to find the Ruby code which is causing this. Was wondering if we can hook into ABRT and print stacktrace similarly as we do for: https://github.com/theforeman/foreman/blob/698e916ce208b5040b83a908a058c83c94d158ee/config/initializers/sig_ttin_trap.rb LZ On Mon, Nov 20, 2017 at 8:05 PM, Dmitri Dolguikh <[email protected]> wrote: > > > On Mon, Nov 20, 2017 at 2:05 AM, Lukas Zapletal <[email protected]> wrote: >> >> Perhaps - can you bit elaborate the GDB >> thing? Is this some kind of hook that use used for FIPS stack to >> report "mistakes" (e.g. signal or exception when you attempt to use >> md5 hash)? I wonder if there is a way to catch these without GDB, for >> example with SystemTap which would allow to catch these also in >> production. Perhaps I misinterpret how this works, I haven't opened >> the PDFs to be honest yet :-) > > > DGB + ruby-specific .gdbinit are used to report ruby callstack when ABRT is > caught. I didn't look for alternatives, seeing that gdb + .gdbinit > combination is pretty trivial to use. I don't really care what we use here > as long as we can get ruby callstack back. > >> >> >> I understand you only investigated core and smart proxy and I assume >> plugin authors will need to do the similar audit themselves. Since we >> are dealing with security, I would like to propose to create kind of >> FIPS CHECKLIST somewhere (perhaps our wikipage) so we could follow it >> and also add own findings/places to look for. In security world it's >> much more useful to have blueprints or checklists, I would not like to >> reinvent the wheel when doing this for discovery or other plugins. > > > Sure, sounds like a good idea. I think it's going to consist of the list of > hash-functions and ciphers not to use and a recommendation to test changes > on a system with FIPS enabled. > >> >> >> Once we settle down on your proposal, please do create tracker >> issue(s) so we can associate our audits or changes to it. If you find >> anything that needs to be done for all plugins, please create tracker >> issue as well. > > > Tracker issue for Foreman already exists: > http://projects.theforeman.org/issues/3511. > > -d > > -- > You received this message because you are subscribed to the Google Groups > "foreman-dev" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > For more options, visit https://groups.google.com/d/optout. -- Later, Lukas @lzap Zapletal -- You received this message because you are subscribed to the Google Groups "foreman-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
