• 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
• ogoshbo
• 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, DevSummit/201308/Security/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
• oshgobo
• 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).