• What do we want for the long term?
• What can we do in time for 10.0?
• Pawel's attachtimes patch for early entropy gathering
• random_adaptor framework
• HWRNG support:
  • As an entropy source for Yarrow / Fortuna
  • As a backend for /dev/random
  • Selectable mixer

• Walkthrough on actual state of security mitigation in FreeBSD
  • ASLR (exprimental patches on people.freebsd.org/~sbz/aslr) ⇒ rewiew + exp-run + security OID
  • DEP (nxstack) [data, head and stack OK]
  • redzone ⇒ not in production (double allocation for runtime check)
  • …

Topics:

• Using CPE in VuXML ⇒ no time

• Security Testing/Operations
  • Security infrastructure (PKI) ⇒ clusteradm not present
  • Response to incident quickly (why not having a security operation team) ⇒ clusteradm not present

In total, there were three security-related sessions: one on each day of the summit.

Notes taken by SofianBrabez originally in text/x-zim-wiki syntax, partly moinmoinified by DagErlingSmørgrav

Present

• pjd
• des
• sbz
• gavin
• markm
• adrian
• rwatson
• daviddrysdale
• oshogbo
• Warren Hunt

See DevRandom

ST

Probably for 11.0

rwatson: Use randomness for ASLR in process and kernel markm : RC4 random (dedicated register) use for mititation and aslr randomness in user mode, /dev/random unblock

Recent:

• FreeBSD-SA-13:06.mmap by alc
  • security.bsd.unprivileged_proc_debug=1 by default

LT:

• Code (.text): [NO ASLR]
• Data (.bss): [NO ASLR] [DEP]
• Linker (loader): [NO ASLR]
• Libc: [NO ASLR]
• Heap: [NO ASLR] [DEP]
• Stack: [NO ASLR] [DEP]
• SSP: Base [OK], Port [KO], Kernel modules [OK/KO]

• kib/alc:
  • email rewiew
  • des: 64 bits code
    • increase address space fragemenation (super pages code ?!)
    • have to look, logic for a hole to fill
  • have to be in security sysctl OID

• garretcooper, macos/other bsd to look at it:
  • apple

• mmap random ⇒ mask to use ⇒ modulus

• patches + exp run + sysctl enable (9.x, 10.x)
  • ⇒ for port

• sysctl oid:
  • move kern/random kern.randompid to security for 10.x
  • move stackgap and mmap to security

• align size of the pointer (align byte minus 1):
  • rwatson:
    • use ALIGN macro
  • pjd:
    • mmx ?!
  • des:
    • align byte macro on ARM is incorrect

• redzone:
  • runtime check, buffer overflow, overrun
  • twice allocation

Whiteboard photos:

• IMG_20130827_115405.jpg
• IMG_20130827_115646.jpg
• IMG_20130827_115708.jpg

Present:

• des
• rwatson
• bz
• sbz
• jonathan
• daviddrysdale
• pjd
• oshogbo
• piete brooks
• pjg
• gavin
• erwin

• 10.0:
  • des: want to kill BIND and replace it by ldns + unbound (or offer the possibility)
  • des: need local caching resolver understanding DNSSEC because time consuming
  • des about ldns:
    • important ldns-host on Monday
    • came from with drill program require a dig wrapper
    • 90 % of compatibility of dig
  • des about unbound:
    • have local resolution (cache resolver and can't afford zone) + local forwarder
    • files as forwarders because it's want we want for each case
    • dhclient updates has to hash unbound instance for resolution because it's cached (resolv.conf to localhost)
    • pjd: risky because people does resolution in jails
    • rwatson: how to choose beetween localtion resolution and normal
    • gavin: resolv.conf handles unbound
    • service unbound states ?!
    • rwatson: handle non-atomicity in rc.conf change
    • openssh: SSHFP (host key fingerprint) record handle by ldns
• future:
  • question about transitions ? for binary output ?
  • careful to removal of nslookup
  • bapt: use bind binary from ports tree version
  • des: library use by ldns = libval feature API ⇒ integrated as libdns in libc for 11.0 (state machine record)
  • pjd: order of depends at runtime and interact with DNSSEC ?!
  • des: shape root key
  • bz ask:
    • security problems if we link a libc that does the resolution for SSH !
    • is libdns a stable API ?!
  • SSH in 10.0 will use libdns and sshfp
  • rwatson: linking the library statically
  • Don't build libunbound at all
  • ask: DNSSec use in base beyond SSH

des: libfetch in 10.0 can verify certificate, where we ship the certificate ?! bz: insane to put cert in DNSSEC record rwatson: digital signature ?! bapt: I just need to sign the metadata ?! des: you have to sign packages as well too bapt: already to be able to sign the catalog des: we have around november because pkgng is a port bapt: introduce simon bytesync python tool ⇒ we don't need to use SSH to copy thing.

pjd: LT when using mirrors compromised ? will be a problem / replace a package corrupted

Both ways are OK * easy way

• https for package distribution
• to transfer the cert what about ceils ? 1) DANE 2) x509 → root cert ?
• → distribution route → talk w/Simon
• → require CDN with SSL

* hard way

• signed package set hash → certification but not a CA! (use per-source key fingerprint)
• bapt: no feedback for improvment because no review and pcbsd already use exisiting solutions ⇒ need secteam review
• → requires review
• → really wants attribute certificate (Extension of OpenSSL) → not in OpenSSL right now
• → OR multiple chains or multiple roots
• des: FreeBSD Foundation can pay for a root for a multiple chains ?
• bapt: verisign propose something or can provide it
• rwatson: introduce CRL to revoke package or package sets difference between package vs vulnerable package

• CPE in ports ?

• bapt: pkg repo does the sign of the metadata
• simon: want an unsigned catalog
• bapt: ask Juniper (sjg) what they done at Juniper
• pjd: propose having absolute path to key
• jonathan/rwatson: propose to add a include directive in pkgng configuration

future:

• we want to set a root cert for having a chains !
• freebsd-update aware !
• pjd: would like to look for revocation (CRL ?)
• des: revoke key and create a new key
• rwatson: think about model before review and revoke key ⇒ revoke packages
• jonathan: using pluggable for signing ⇒ signature checking

10.0 Operational TODO:

• pkg repo must submit metadata for signing, not hold keys
• pjd: support people without certificate and local repository (file://, ssh://…)
• build system cool still compromise for short term (one month)
• key management
• pawel or Juniper's signature source for FreeBSD → signing service
• TODO for clusteradm:
  • bapt requires HSM-LIKE service (provide by pjd implementation or sjg at juniper)

10.0 Developer TODO:

• Installer support ?
• Commit pkg keys to src
• Having in time for 10.0 release but pkgng is a port
• Review pkgng sign/validation code
• Way to distribute/include key via freebsd-update → master key to update
• Package + package set revocation
  • - record hashes in db
  • - how do distribute revocation list (list of hashes ?!)
• Allow multiple signatures on package set → Fingerprints (multiple) bad keys w/ expirate date
• Model dual - key model
• Clear validation strategy/algorithm
• Key definitions can contain “revocation” fingerprints with dates
• VUXML:
  • - pkgng support condense and normal audit format

• TODO for clusteradm/secteam (benlaurie, jonanderson, steven, …):
  • commit pkgng keys to src

• TODO for bapt:
  • pkg/set revocation
  • key definitions
  • allow multiple signatures

10.0 impossible things:

• 1) X509 certs
• 2) nature key management/
• 3) assume pkgng self-update post freebsd-update
• 4) HSM

• Nomenclature used by Mitre and the NVD to identify which software packages are affected by a vulnerability
• Currently, VuXML uses the port's ${PACKAGE_NAME} and easily gets confused if a package is renamed (e.g. various Perl ports)
• If we store the CPE as metadata in the package and include it in the VuXML entry, we can use that instead

Conclusion: just start adding CPEs and worry about how to use them later.

• All SAs need regression tests
• Migration kill from BIND to LNDS + Unbound in base
• What about host, dig, nsupdate (replace old tool by ldns tool)
• “Screw it, we import unbound”

We will have a short-term plan for 10.0 that isn't pretty but allows us to securely update packages and pkg infrastructure in the field (pkg signing for 10.0.jpeg).

We also need a longer-term plan that we can implement for e.g. 11 (longer term pkg signing plan.jpeg).

A package currently contains: - Two manifest files +MANIFEST - Contains full details, including hashes of each file +COMPACT_MANIFEST - File list, directory list, scripts removed - COMPACT_MANIFEST is only used to know wheter a package needs updated

digest.txz contains: - Signatures of COMPACT_MANIFESTS - digests file is purely an optimisation.

Packagesite.txz contains: - packagesite.yaml - Contains copy of all COMPACT_MANIFEST details, including hash(pkg files)

In the future, digest.txz and packagesite.txz should both be signed.

/usr/local/etc/pkg.conf on client should support: - fingerprint: ….. - include: /etc/… (this support needs to be added, and needs to support multiple includes) - This is to allow people to create their own fingerprint trees and include them

Signatures are RSA, created with OpenSSL

/etc/pkg/keys/ - OpenSSL public keys Contains list of good keys Contains list of bad keys - pkg needs to check bad keys first! /etc/pkg/freebsd.conf “enable: true” to enable official repo

Bootstrapping relies on: pkg.txz pkg.txz.sig (pkg.txz.crt) keys.txz keys.txz.sig pkg bootstrap binary in base verifies SSL signature against /etc/pkg/keys/ key

Need to record which key/certificate created each signature

Signing service needs building - clusteradm (Juniper/pjd?)

Digests need to contain (pkg, reposet, signatures, signature datestamp)

Compromised package sets notified via “pkg audit”, plus security advisory etc

packagesite.txz should contain previous “bad” backage set details

packageset.txz also contains cert/signature mapping

poudriere: ports→packages→repo. Signed. (cert, sig) given to pkg update. pgk update: for each (cert, sig): check cert, fingerprint (with OpenSSL) (check /etc/pkg/fingerprints/bad, check “bad set” list) verify signature (with OpenSSL) …

clusteradm will have key on signing server. so@ will keep copy encrypted against so@ pgp key, just in case.

- CA cert + chain - Key rotation - key distribution through pkgng

OpenSSL doesn't support attribute certificates, so we need to hack around it.

FreeBSD CA \–> sub –» @FreeBSD.org S/MIME | |—> freebsd-update fingerprint (handled in same way as below) \|/ pkg fingerprint file (serves to break the certificate chain) \|/ pkg intermediate \|/ cert \|/ pkg set

Result: FreeBSD CA only signing configuration files. Chain of trust deliberately broken via signing fingerprint files so that lower certificates are untrusted to tools that don't understand how the chain works