On Tue, Aug 19, 2008 at 5:10 PM, Steve Marquess <[EMAIL PROTECTED]> wrote: >> Note YOU MUST FOLLOW THE SECURITY POLICIES EXACTLY OR ELSE THE >> RESULTING LIBRARY WILL NOT BE COMPLIANT. This includes shutting your >> UNIX machine down to single-user mode during the build process. It >> probably would not hurt to write down everything that you do in a >> timestamped log so that you can prove that you have followed the >> security policy. > > What he said -- and a good suggestion about the log. Though the "single > user mode" restriction is intended to apply to runtime operation of the > module, not necessarily just the module installation (creation). That > restriction is in every validation that I've read for software on a > general purpose computer. How can that be reconciled with the way such > software is actually used? A good question, and one that I can't answer > other than to note that the single user restriction is not unique to the > OpenSSL FIPS Object Module; in years past I have pursued and been given > multiple explanations, some quite elaborate, that I just don't get.
The best conjecture I've come up with: Relying on operating system restrictions to protect the sanctity of the module's security boundary effectively moves one of the most important functions of the module's packaging outside the control of the module. For a chip, you can say "it's inherent that the chip's pins are the only way to interact across the boundary." If you don't have that inherent quality, then without evidence to the contrary it must be assumed that anything can reach across that boundary. I'm probably completely off-base, but like I said, it's the best conjecture I've got. I'd actually be interested in figuring out what the SELinux extensions would do to help (essentially adding mandatory ACLs to the Linux kernel), but I don't have the cash to pony up for any kind of evaluation or validation attempt for it. :) -Kyle H ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List [email protected] Automated List Manager [EMAIL PROTECTED]
