# 2017-06-07
Time: **9am PDT** (12pm EDT, 5pm BST) [see the time in your timezone](https://www.timeanddate.com/worldclock/fixedtime.html?msg=Linuxkit+Security+SIG&iso=20170607T09&p1=224)

Meeting location: https://docker.zoom.us/j/779801882

Announcement: [Moby project forum post](https://forums.mobyproject.org/t/2017-06-07-linuxkit-security-sig-meeting/58)

Video recording: https://youtu.be/GkjswX75K08

Previous meeting notes: [2017-05-24](2017-05-24.md)

## Agenda
- Introductions & Administrivia (5 min)
- RFC on `"probational"`/`"hardened"`/`"staging"` channel (15 min)
  - proof-of-concept in LinuxKit repo
  - proposed process for promotion to channel, out of channel
- buildchain security: PIE/ASLR for packages @fntlnz (10 min)
- `miragesdk` deep dive - @avsm @samoht @yomimono @talex5 (20 min)
  - What is it?  Why do we care?
  - RFC: which system daemons should we implement?
  - architecture deep dive
  - demo: `dhcp`
- Project updates (10 min)
- Next meeting: 2017-06-21
  - landlock demo and deep dive - @l0kod
  - we can propose additional deep dives and discussion topics!

## Meeting Notes
Scribe: @mgoelzer

- Introductions for new attendees - welcome!

- probational channel:
    - calling it “Probational Channel” (vs “hardened” to avoid implying that LinuxKit itself is soft)
    - goal is to have a curated channel of what’s in `/projects`
    - also goal:  reduce bit rot
    - RFC here:  https://docs.google.com/document/d/1V3R_eF-_JTEcWmw_pKERuRAWMDxZ3iCy_6piLPhtZSA/edit#heading=h.99zlrcqz1kzx
    - goal of RFC is build your project based on a delta against base LinuxKit (e.g., add Wireguard, add Landlock)
    - @cschaufler:  let’s have at least one that is all the projects, and then others for explicitly requested combos of projects
    - @justincormack:  probation/promotion is orthogonal to the tooling problem.
    - against any tooling in the project, tooling should be upstream.
    - @avsm:  just have a Makefile snippet you can include, will help with the bit rot problem

- buildchain security:
    - discussion lead:  @fntlnz
    - issues are PIEs, ASLR, signing.  Binaries today are not using linker best practices.
    - two concerns:
        - we should be using PIE, ASLR - current state discussed on [issue](https://github.com/linuxkit/linuxkit/issues/1902)
            - golang compiling produces [static PIE executables](https://github.com/linuxkit/linuxkit/blob/master/tools/go-compile/compile.sh#L100)
            - c compiling benefits from Alpine Linux default flags
        - we have to check that future binaries in LinuxKit builds should be compiled with the appropriate flags
            - including stuff written in other languages like Rust
    - we would benefit from tools to start binary in isolation, look at its runtime environment - works with anything (libc, muscl, etc)
        - @cschaufler: take a look at Yocto’s buildchain checks
        - @avsm:  need to modify some language configs as well (for OCaml binaries)
    - @justincormack:  runc is not linked correctly
    - @riyazdf:  next meeting let’s also discuss how we can go beyond signing, better checks

- mirageSDK
    - discussion lead:  @avsm
    - slides:  https://speakerdeck.com/avsm/a-modern-services-sdk-for-linuxkit
    - goal is to rebuild the services on top of LinuxKit with advanced security features:
        - type safety
        - container-native daemons
    - daemons:  [dhcpd in repo today](https://github.com/linuxkit/linuxkit/tree/master/projects/miragesdk), working on others.  Open to feedback for prioritizing future type-safe daemons (ntp, dns, https, etc)
    - containerized, but still written in C and require high system privilege
    - want to make these components less monolithic, more container native.
    - dhcpd:
        - in a cloud environment, you really only need it once.  You’re more likely to kill machine than want to change its IP after boot.
        - requires very low level access - eg IP route tables
        - described 3-part priv separated architecture
    - Capnp - RPC system for how these 3 processes communicate
    - @yomimono: demo fuzz testing with American Fuzzy Lop (afl)
        - asciinema of demo: https://asciinema.org/a/3ljccmn19m25uj02kve678xp6
        - afl:  http://lcamtuf.coredump.cx/afl/
    - Also focusing on other services:  DNS, HTTPS