[illumos-gate] 17182 libc: cleanup *printf code duplication -- Hans Rosenfeld <rosenfeld⊙gho>

I'm going to regret asking this but I already regret needing to ask. We have a new grant coming in and need to comply with their security requirements. One of them is "The Contractor (and/or any subcontractor) must protect all government information that is or may be sensitive by securing it with a solution that is validated with current FIPS 140 validation certificate from the NIST CMVP.

"

anyway, I don't suppose there's any such certificates for, e,g the cryptographic modules in Illumos?

especially those used with ZFS.

if there is, it would be via a distribution

I don't think it's really possible for illumos to be fips140

for a start, I'm pretty sure we'd have to ship a binary :)

danmcd: you're probably a person who would know?

jbk: and you're a person who would work somewhere that had a cert, if anyone did, I reckon

<sigh> fucking gumbies...

I'm particularly concerned with OmniOS, as that's the distro we're using.

WE DO HAVE some FIPS140 infrastructure in Encryption Framework per se...

The cryptoadm utility provides subcommands to enable and disable

FIPS-140 mode in the Cryptographic Framework. It also provides a list

subcommand to display the current status of FIPS-140 mode.

we've licensed a FIPS140 certified crypto library and integrated it as a KCF module for zfs

in our product

BUT TBH you want things outside of gate that do this. Like OpenSSL, etc.

(we also support FIPS140 certified self encrypting drives)

I don't know how gumby-ish "The Contractor (and/or any subcontractor)" is about it, but I expect they're probably more-than-just-checkboxing.

there's all sorts of 'profiles' so just saying FIPS140 is a bit unspecific

You'll need someone who speaks official-standards to tell you what to expect-and-not and what is required-or-not.

I'd like to honor the spirit as well as the wording, if that's at all possible.

the spirit of fips140 is "we're pretty sure you implemented this right, but to be pretty sure we have decided to be Onerous and nonsensical"

See jbk's idea of profiles. That should honor the spirit insofar as "Don't use DES, MD5 (even HMAC), SHA1, etc..."

danmcd: I thought garrett pulled a lot of that out since there was some closed sourced bits involved

forbid anyone to read your data while wearing matching socks

richlowe: in other words a fucking gumby.

jbk: that might very much be true.

searching for "FIPS 140 zfs" finds at least quite a few people who have asked things in the same direction...

beyond that, it's you only use these approved mechanisms (e.g. I don't think chacha20/poly1305 is on the list)

jbk: that would make sense, if I recall (at least at the time) they certify _binaries_ of implementations

and things like doing a self test at startup and basically not working if things fail

etc.

yes

so things like updates become tricky

since things like 'new behavior' require a new certification

My first contribution to anything public/open-source-y (yes even before fixing a small sockaddr kernel bug in 4.4BSD Lite) was definitions 2 and 3 here:

I remember Val Fenwick had a lot of words about this, but some vague idea it might get better

though things that are bug fixes I believe do not

but then I never had a reason to learn if it got better

^^^ she's at Apple now (along with Mark)

(And yes I know all about esr ... this was literally 30 or more years ago)

the crypto bits we are using are from nss. not just nss, its like 14 years old nss.

the same contract also wants us to run SCAP, which - at least for Leeenux - demands automatic nightly patching.

so much for certified binaries.

"To ensure that the packages comprising the available updates will be automatically installed by dnf-automatic, set apply_updates to yes under [commands] section in /etc/dnf/automatic.conf."

Left hand and right hand are at cross-purposes... that NEVER HAPPENS IN THE GOVERNMENT! (Even true in sane ones.)

I suspect any FIPS-140 stuff in the gate is for older revisions the government no longer accepts

I would hope so alan

nomad: I don't know of a pre-built way to get automatic updates, and I'm not 100% certain the exit status of pkg(1) tells you enough to do it thoroughly

Speaking of which, I don't suppose there's an openSCAP or equiv for Illumos/OmniOS by any chance? I haven't gotten around to looking yet but thought I'd ask here as a lazy shortcut. :)

I don't know if you can tell if you need to reboot just from the exit

they have long tails though

we build & ship openscap in Solaris, so it should be buildable for illumos

FIPS140-3 is (relatively) new, and has a pretty decent backlog in terms of certification

I would assume that would get worse before it gets better

$BOSS just told me to focus on the SCAP stuff so.. <shrug>

why if you look, lots of things tend to have disclaimers to the effect of 'certification in progress'

does look like we patch it a bit though: github.com/oracle/solaris-userland/tree/master/components/openscap

some of the patches a bit important too: github.com/oracle/solaris-userland/…p/patches/zz_probe_package511.patch

yeah, you probably want that if you're on a distro using IPS

could I possibly be so lucky that there's an installable package? That would be a nice improvement on my day so far.

looks like OI dropped their openscap package years ago: OpenIndiana/oi-userland #1430

an installable package? the solaris-userland one will only be installable on Solaris - you'd need to build from source for an illumos distro

the solaris-userland one also provides the framework, but the openscap benchmarks for the Solaris compliance & healthcheck tests are closed source and not provided there

richlowe - this is how I do itbloody% pfexec pkg update --parsable=0 -n | jq '."create-new-be"'

true

clever

[illumos-gate] 16151 want dprintf() -- Hans Rosenfeld <rosenfeld⊙gho>