Current location

narf Source control manager Git

summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorOlivier Mehani <shtrom@ssji.net>2018-01-26 11:30:22 +1100
committerOlivier Mehani <shtrom@ssji.net>2018-01-26 11:30:22 +1100
commit51db8f9fefd6d193138ce9680ff35c9ed3b457ad (patch)
treee58c86c9c9e7b53e629332634620c97878fbc510
parent1d5642b0f2be2062033fb4f1c967beff4354826c (diff)
Friday morningish
Signed-off-by: Olivier Mehani <shtrom@ssji.net>
-rw-r--r--2018lca/2018lca.tex833
-rw-r--r--2018lca/IMG_20180126_105123.jpgbin0 -> 126371 bytes
-rw-r--r--2018lca/IMG_20180126_105834.jpgbin0 -> 92815 bytes
3 files changed, 821 insertions, 12 deletions
diff --git a/2018lca/2018lca.tex b/2018lca/2018lca.tex
index 9c150ae..4bef89b 100644
--- a/2018lca/2018lca.tex
+++ b/2018lca/2018lca.tex
@@ -194,9 +194,8 @@
\end{itemize}
\end{itemize}
-\includegraphics[width=\textwidth]{IMG_20180122_153207.jpg}
-
-\includegraphics[width=\textwidth]{IMG_20180122_153453.jpg}
+\includegraphics[width=.5\textwidth]{IMG_20180122_153207.jpg}
+\includegraphics[width=.5\textwidth]{IMG_20180122_153453.jpg}
\subsubsection{Using ``old skool'' Free tools to easily publish API documentation --- Alec Clews}
@@ -223,7 +222,7 @@
\end{itemize}
\end{itemize}
-\includegraphics[width=\textwidth]{IMG_20180122_162909.jpg}
+\includegraphics[width=.5\textwidth]{IMG_20180122_162909.jpg}
\subsection{Open Source and Bioinformatics}
@@ -806,13 +805,12 @@ Why would one need access to a bio hacking lab?
\item History suggests that Linux is not forever
\end{itemize}
-\includegraphics[width=\textwidth]{IMG_20180124_112447.jpg}
+\includegraphics[width=.5\textwidth]{IMG_20180124_112447.jpg}
\subsection{Is the 370 the worst bus route in Sydney? --- Katie Bell}
-\includegraphics[width=\textwidth]{IMG_20180124_113859.jpg}
-
-\includegraphics[width=\textwidth]{IMG_20180124_114120.jpg}
+\includegraphics[width=.5\textwidth]{IMG_20180124_113859.jpg}
+\includegraphics[width=.5\textwidth]{IMG_20180124_114120.jpg}
\begin{itemize}
\item Data about busses is difficult to get
@@ -870,9 +868,8 @@ Why would one need access to a bio hacking lab?
\end{itemize}
\end{itemize}
-\includegraphics[width=\textwidth]{IMG_20180124_120154.jpg}
-
-\includegraphics[width=\textwidth]{IMG_20180124_120225.jpg}
+\includegraphics[width=.5\textwidth]{IMG_20180124_120154.jpg}
+\includegraphics[width=.5\textwidth]{IMG_20180124_120225.jpg}
\subsection{XFS: Teaching an Old Dog New Trics --- Dave Chinner}
@@ -1027,7 +1024,7 @@ Why would one need access to a bio hacking lab?
\end{itemize}
-\includegraphics[width=\textwidth]{IMG_20180124_144103.jpg}
+\includegraphics[width=.5\textwidth]{IMG_20180124_144103.jpg}
\subsection{Securing the Linux boot process --- Matthew Garrett}
@@ -1099,6 +1096,818 @@ Why would one need access to a bio hacking lab?
\section{Thursday}
+\subsection{Keynote: Wandering through the Commons --- Hugh Blemings}
+
+\begin{itemize}
+ \item A few instrumental people and organisations
+ \begin{itemize}
+ \item Lions and his book (6th ed with source code)
+ \item Pia Waugh (now Andrews, now in NZ), pushing Linux Au in 2003
+ \item Vik Oliveor, RepRap
+ \item Clare Curran (NZ), Open Government
+ \end{itemize}
+ \item AU/NZ has one of the most vibrant FOSS community
+ \item Working in FOSS and OH (Open Hardware)
+ \begin{itemize}
+ \item Be visible in projects of relevant, search engine, Github, \ldots
+ \item Be yourself (but business-friendly)
+ \item LinkedIn is a thing, no matter what you think of it, need an
+ accurate basic presence there
+ \begin{itemize}
+ \item Finding a job in FOSS
+ \begin{itemize}
+ \item personal networks
+ \item conferences, \ldots
+ \end{itemize}
+ \item Application and negociations
+ \begin{itemize}
+ \item be professional
+ \item do your homework about culture
+ \item talk to people who work there
+ \item prep interviews
+ \item think and stick to salary expectations (check with friends)
+ \item ask to keep copyright on your code
+ \end{itemize}
+ \item Working in there
+ \begin{itemize}
+ \item takes time to get into the groove, don't sweat
+ \item get out every now and then, particularly if WfH
+ \item work/life balance, tricky if passionate
+ \item know when to jump (\eg, from poisnous workspaces)
+ \item for people managers: bring your best, or don't be one
+ \end{itemize}
+ \item Look after yourself
+ \begin{itemize}
+ \item sedentary and solitary pursuit $\rightarrow$ exercise
+ \item sitting or standing all day is bad $\rightarrow$ take breaks
+ \item depression is a real thingk $\rightarrow$ Beyond Blue and
+ BlueHackers are excellent resources
+ \item Eat more veggies
+ \item Find friends/colleagues to exercise with
+ \end{itemize}
+ \item Staying current
+ \begin{itemize}
+ \item look over people's shoulder
+ \item do something that's not part of your job, on your own time
+ if needed
+ \item stay up to date with security jobs
+ \item take the lid off and tinker with hardware
+ \end{itemize}
+ \item Make hay while the sun shines
+ \begin{itemize}
+ \item quirrel away a few jobs if needed
+ \item \ldots
+ \end{itemize}
+ \item You're fired, now what?
+ \begin{itemize}
+ \item Don't panic
+ \item It's not personal: it's the position, not you that's not
+ needed
+ \item Is it legal? If you think so, seek further advice before
+ responding
+ \item Aftermath: normal to fell rubbish, beware of impostor
+ syndrome, kep 2/3 opportunities in the pipeline, don't assume
+ people will remember you, keep the search narrow in the first
+ couple of weeks, balance “taking anything” vs. “waiting for
+ dream job”
+ \end{itemize}
+ \end{itemize}
+ \end{itemize}
+ \item Hugh's current job: Power9 CPU
+ \begin{itemize}
+ \item 4\,GHz, 24SMT4 Cores
+ \item ~7\,TB bandwidth
+ \item \ldots
+ \item 40\,nm
+ \item 8\,B transistors
+ \item 25\,km of wiring
+ \item Pretty cool engineering!
+ \item Plug for OpenPOWER foundation
+ \end{itemize}
+ \item Conclusions
+ \begin{itemize}
+ \item Vibrant FLOSS/OH community here and abroad
+ \item Accomplished much
+ \item Most exciting things lie before us
+ \item Need everyone to be a part at every level of the stack
+ \end{itemize}
+\end{itemize}
+
+\subsection{SPECTRE/Meltdown panel}
+
+\begin{itemize}
+ \item Panelists: Jonathan Corbet (chair), Katie McLaughlin (SRE at ???), Benno Rice
+ (FreeBSD core dev + FreeNAS), Jess Frazelle (MS/Kebernetes security team),
+ Andrew 'bunnie' Huang (makes and breaks hardware), Kees Cook (Google,
+ upstream kernels)
+ \item How did it impact the community?
+ \begin{itemize}
+ \item JF: lots of confusion and lack of knowledge about containers (don't
+ save you from HW bugs); better fix: no embargo
+ \item BR: 11 days to fix the bug before end of embargo; better disclosure
+ process
+ \item KC: well constrained trying to make sure there was an approval
+ process so people who had to know could, but it was hard; needed more
+ visibility withing the x86 maintainers
+ \item KML: didn't hear before end of embargo, hard to work out a response
+ as a platform provider
+ \item bunnie: feel for the engineers who worked on the chip, people ask
+ for more performance, which is whas got exploited; insterested to see
+ how it plays out, risk to see everything closed to avoid disclosures
+ \end{itemize}
+ \item What does it say about embargoes?
+ \begin{itemize}
+ \item JC: created haves and have-nots
+ \item BR: embargo serves a purpose; people starting wondering about
+ performance-degrading patches getting into the kernel without complaints
+ from Linus
+ \item KC: embargo was successful (broke 6 days early for someting that
+ started in June), but notification was tricky
+ \item JF: small cloud providers were impacted worse, not clear who should
+ be informed
+ \item JC: two-tier information sharing; would hate to see a world where
+ bigger providers only have access to early info
+ \item BR: biggest Intel customers get info first, community projects don't
+ have such a relationship
+ \end{itemize}
+ \item How to avoid haves/have-nots?
+ \begin{itemize}
+ \item KML: 6 days were important, allowed to disable things quickly
+ waiting for the patches, but made everything RO; Heroku was fine with
+ building their own kernels, smaller providers couldn't do that
+ \end{itemize}
+ \item In the market for new hardware, does buying AMD/OpenPOWER help?
+ \begin{itemize}
+ \item JC: don't want to redirect to a particular manufacturer; but what
+ about more open hardware, with architecture we can review
+ \item bunnie: in the case of the bug, all information was publicly
+ disclosed. Flaw based on fake performance improvement. Seymour Cray:
+ “Memory is like an orgasm, better when you don't have to fake it.”
+ Faking memory creates side-channels.
+ \item JC: reproducible builds, how do we do that in hardware?
+ \item bunnie: it's hard, doping attacks; even OH projects don't have all
+ the source available; can't build fabs from source
+ \end{itemize}
+ \item In 1995 researchers were worrying about speculative execution, but were
+ ignored; how do we make sure this doesn't happen again with researchers
+ today
+ \begin{itemize}
+ \item JC: programming in C is risky; risky things are sometime necessary;
+ don't want to throw the baby out with the bath water
+ \item KC: may be worth paying attention to the more paranoid individuals;
+ that an attack is impractical doesn't mean all are
+ \item bunnie: it's insane we assume we can run secret and non-secrets on
+ the same hardware
+ \end{itemize}
+ \item What are the criteria used to invite people in the embargo?
+ \begin{itemize}
+ \item JC: there are mechanisms in the community, they weren't used this
+ time
+ \item KC: the existing systems are for SW vulns, not HW; things were
+ awkward with rowhammer, too
+ \item BR: asked Project Zero (Google) to give FreeBSD a hint when they
+ have to start patching their kernels urgently
+ \end{itemize}
+ \item would containers help moving away from a cloud provider to
+ another?
+ \begin{itemize}
+ \item JF: migration easier, also kernel updates
+ \item KML: done it in a whole AWS region to move to new VMs, but not available
+ in all regions
+ \end{itemize}
+ \item Buffer overflows were bugs, became security issues; OpenSSL bugs, became
+ security features; is this the next?
+ \begin{itemize}
+ \item KC: Kernel patch was (hoped to be) addressing a lot of related vulnerabilities
+ \item BR: timing attacks on cache have been a thing for a while; all the
+ performance-optimising parts of the CPU are now an attack surface that
+ is going to be looked at for a while
+ \item JC: would this impact CPU designL
+ \item bunnie: trust but verify, but verifying will slow hardware down;
+ adding noise so timing is not as predictable
+ \end{itemize}
+ \item Huge impact on society, but we have trouble understanding it; how do we
+ explain to politicians, educators, \ldots
+ \begin{itemize}
+ \item KML: use logos, create communication platforms “Not a real
+ vulnerability until it has a logo” $\rightarrow$ name a recent one that
+ didn't have a logo
+ \item JC we've been trying to increase security, but even kernel devs get
+ their laptop compromised every now and then
+ \end{itemize}
+ \item What about older CPUs without speculative execution?
+ \begin{itemize}
+ \item JC: that would be pretty old
+ \item 486 doesn't / Itanium either apparently
+ \item JC: need to get rid of the memory bandwidth problem
+ \end{itemize}
+ \item What can we take into the software side of the vulnerabitily process?
+ \begin{itemize}
+ \item JC: back to embargo process
+ \item BR: software process working better already; positive discussions
+ since this happened
+ \item bunnie: who is the embargo trying to protect against?
+ \item JC: script kiddies are last century's problem; much more commercial
+ or political interests; heard rumours of exploits being on the market
+ \item bunnie: political actors may already be listening the the comms,
+ might as well open to the whole community
+ \item BR: embargo is to let actors prepare their response
+ \item JC: there is an argument for bringing in the community process
+ earlier
+ \end{itemize}
+ \item Final words
+ \begin{itemize}
+ \item KML: good work, but depends on people applying the patches
+ \item KC: run the latest kernel, hard to backport on 2.6\ldots or 3, or 4
+ \item BR: ``shiny new things to look at'' but need to make the disclosure
+ process
+ \item JF: containers don't save you, but ease the migration pain
+ \item JC: lot of secrecy (even now) as compared to software disclosures;
+ need an end to that
+ \end{itemize}
+\end{itemize}
+
+
+\subsection{Building a Better Thermostat --- Matthew Treinish}
+
+\begin{itemize}
+ \item Came home to a very hot appartment
+ \item Poughkeepsie appartments not designed for heat
+ \item Decided to build a thermostat to control the appartment's 2 AC units
+ \begin{itemize}
+ \item Closep loop control system
+ \item Identify the AC unit is tricky, so control is difficult
+ \begin{itemize}
+ \item Can control power
+ \item Wireless control ideal
+ \item Existing comercial solutions, generally terrible because the
+ interface is push buttons and LCDs
+ \item Z-Wave power switches (15\,A) are good
+ \item Z-Wave is a low power mesh network (908.4/916\,MHz in the US;
+ 921.4/919.8\,MHz in AU due) for sensors; not open, but
+ interop testing (unlike ZigBee)
+ \item AU ISM starts at 915\,MHz, rest of the world at 900\,MHz
+ \item Z-Wave MultiSensor 6
+ \item Z-Wave USB controller
+ \end{itemize}
+ \item Can now write software
+ \begin{itemize}
+ \item or use Home Assistant (OpenSource platform in Python 3)
+ \item Over 900 supported components
+ \item Everything runs locally
+ \item Will always run on an RPi 3 by design
+ \end{itemize}
+ \end{itemize}
+ \item Home Assistant has the concept of a generic thermostat; simple YAML
+ config
+ \item Problem
+ \begin{itemize}
+ \item Only one temperature sensor, but two ACs in different rooms
+ \item Heat generating devices in the closet
+ \item Didn't want more Z-Wave sensors
+ \item Bought Dallas 1 wire DS18B20, wired to an RPi to track closet temp
+ \item No software for it
+ \item Wrote a framework for polling sensors and pushing results on MQTT
+ \end{itemize}
+ \item Next problem: short cycle times are not good for ACs' compressors
+ \begin{itemize}
+ \item Compressors are more efficient at steady state
+ \item Better for power bill and environment
+ \item Added a min cycle time parameter
+ \end{itemize}
+ \item Step further: automation rules
+ \begin{itemize}
+ \item basic time schedule
+ \item location tracking: higher temp when not home, start cooling when
+ getting closer $\rightarrow$ OwnTracks pushes location to MQTT
+ \item turn AC off if it's cold outside (need to add notification to open
+ the window, next)
+ \item increase TV volume when compressor is on
+ \item turn AC on when closet cloud starts
+ \end{itemize}
+ \item On-premises control, fine-grained, and will only fail if power goes out
+ \item \url{https://github.com/mtreinish/dallasMQTT}
+ \item \url{https://github.com/openzwave/}
+ \item \url{https://zwavepublic.com/}
+ \item \url{https://owntracks.org}
+\end{itemize}
+
+\subsection{F-Droid: The private, secure, free and open app store for Android
+ --- Peter Serwylo}
+
+\begin{itemize}
+ \item Android is Linux deployed in billion of devices around the world
+ \item Issue: first thing that happens is sign up and ToS (Google Android
+ experience; Amazon doesn't)
+ \item Skippable, but impossible to install apps if so
+ \item All required by Google for phone manufacturers to be allowed to ship
+ Android phones
+ \item Instead, the Android Open Source Project is the targed base framework.
+ \item ROMS
+ \begin{itemize}
+ \item XDA is scary installation of blobs from file-sharing site
+ \item LineageOS (device support)
+ \item Replicant (FOSS devices)
+ \item CopperheadOS (security)
+ \end{itemize}
+ \item How to install apps on ROMs? Get a binary copy of Google Play from
+ file-sharing sites
+ \item Alternative app stores incl. F-Droid
+ \item F-Droid really is a package manager
+ \begin{itemize}
+ \item Built from source
+ \item No tracking
+ \item No login
+ \end{itemize}
+ \item Getting app published
+ \begin{itemize}
+ \item Check licensing of app and dependencies
+ \item Provide source links
+ \item Flag anti-features
+ \item Build from source
+ \begin{itemize}
+ \item Security nightmare
+ \item Buildserver VM
+ \item Target attacks on building dependencies, \eg, Maven asked for a
+ fee to serve deps over SSL, hard to verify package PGP signature
+ \end{itemize}
+ \item Verification servers
+ \begin{itemize}
+ \item See Chris Lamb's LCA2018 talk on diffoscope
+ \item Info not used by the client yet
+ \end{itemize}
+ \item Signing packages
+ \begin{itemize}
+ \item Airgapped machine
+ \item Cert stored on HSM
+ \item Tranfer back to internet-connected machine via USB
+ \item Signed by F-Droid signing key
+ \item Can't update app installed from Play Store (signed by upstream
+ developer)
+ \end{itemize}
+ \item Reproducible builds
+ \begin{itemize}
+ \item Include URL to upstream app binary
+ \item Compare binaries, reuse upstream signature
+ \item Hard due to environmental factors getting embedded into binary
+ \item Dream would be to get upstream use F-Droid buildserver
+ \end{itemize}
+ \item Distributing metadata of available binary apps
+ \begin{itemize}
+ \item Signed (airgapped machine again)
+ \item Pinned certificates for a few repos baked into the app
+ \item Future feature: per-ROM pinned certificates (sitting on a
+ protected RO partition)
+ \item Certificate fingeprints embedded in repo URLs (ToFU if
+ unspecified)
+ \end{itemize}
+ \item Distributing apps
+ \begin{itemize}
+ \item Privacy: no account, HTTPS, Tor
+ \item Information leakage risk: ETags (Cookieless cookie, need to
+ \verb#HEAD#), TLS
+ sessions identifiers, language preferences $\rightarrow$ not passed
+ to the server who sends everything
+ \item Want to trust as few components (servers, networks) as possible
+ \item Mirrors: Guardian project uses ``collateral freedom'' using big
+ site (Github, S3, \ldots)
+ \item Checksums, hash checks, internal/external storage
+ \end{itemize}
+ \item Installing apps
+ \begin{itemize}
+ \item Problem with allowing unknown sources (== ``Not Google Play'')
+ \item Android trust apps on the system partition
+ \item Two options: using the \verb#PackageManager# (if allowing
+ unknown sources, now per app), or \verb#priv-ext#
+ \item Privileged extension: stub to install on the system partition
+ accepting only requests from F-Droid if signed by the same key
+ \end{itemize}
+ \end{itemize}
+\end{itemize}
+
+\subsection{Tap On to Reverse Engineering --- Michael Farrell}
+
+\begin{itemize}
+ \item Reverse-engineering unknow binary data files from contact-less cards
+ \item NFC smartcards
+ \begin{itemize}
+ \item Old: discrete logic IC
+ \item New: microcontroller running Java
+ \item Powered by induction by reader
+ \item Bidirectional coms (13.56\,MHz)
+ \item User storage, may be rewritable
+ \item Most smart phones have NFC hardware
+ \end{itemize}
+ \item Public transport
+ \begin{itemize}
+ \item 1996: South Korea
+ \item 1999: Hong Kong
+ \item Sydney started in 1999, scrapped in 2005, restarted in 2012--2014
+ \item Off-the-shelf systems with minor tweaks (except for Vic)
+ \item MetroDroid
+ \end{itemize}
+ \item Why store data on the card?
+ \begin{itemize}
+ \item Back-office system with all cards, balances and transaction ledgers
+ \item Fixed validators
+ \item Website and vending machines
+ \item On-board validators, requiring balance and recent transactions to be
+ stored on the card
+ \end{itemize}
+ \item How is the data stored
+ \begin{itemize}
+ \item Serial number + manufacturing information
+ \item Sectors containing user data and access control labels (MIFARE
+ Classic: CBR, TAS, Perth, Brisbane?; MIFARE: MLB, SYD)
+ \item Multiple application IDs, using files
+ \end{itemize}
+ \item What's in a transit smartcard?
+ \begin{itemize}
+ \item Opal MIFARE DESFire EV1
+ \item Readable by most Android phone
+ \item Compare raw read with Opal App
+ \item Prefix: 308522, last bit check digit
+ \item Balance in bitstring
+ \item Date of last use: epoch 1980-01-01
+ \item Doesn't require encryption to read real data (unlike Oyster card,
+ and SF Coppa cards)
+ \end{itemize}
+ \item Manly Fast Ferry
+ \begin{itemize}
+ \item MIFARE Classic 1K (2009) readable with NXP NFC
+ \item First sectore readable, othe locked with per-card keys
+ \item 15 sectors with 48\,B user data (except first which has serial +
+ manufacturer info, ond 32\,B)
+ \item Ask for a print out of the balance
+ \item Only card number in open sector
+ \item stumped
+ \end{itemize}
+ \item Go Card (Brisbane)
+ \begin{itemize}
+ \item MIFARE Classic 1k
+ \item All sectors except for serial number
+ \item Luhn checksum
+ \item key-diversification function on readers to return a 48\,B key
+ \item stumped
+ \end{itemize}
+ \item MIFARE Classic Research
+ \begin{itemize}
+ \item home-made crypto introduced in 1994: Crypto1
+ \item probably flawed (see Netscap Navigator an Nokia XXXX)
+ \item Fundan Microelectronics FM11RF08 (2004) implements Crypto1, MIFARE
+ compatible
+ \item First attacks published in 2007--08: break a key in a week for \$100
+ \item Key recovery possible in second with 2 authentication method
+ \item Nested attack 2009, offline without any access, but need one key
+ \item Darkside attack 2009, don't need to know any key,
+ but longer
+ \item NXP respose (2008) request for time to address issue
+ \item Fixes: doc now available only with NDA, and new card
+ \item Cards also used for payment and access in many system
+ \item UK decided to break MIFARE Classic to update to safer cards
+ \item Still need to disable MIFARE classic compatibility
+ \end{itemize}
+ \item How to break MIFARE classic cards
+ \begin{itemize}
+ \item Darkside to get first key, then Nested attack
+ \item Mifare Plus: interact with a valid reader
+ \end{itemize}
+ \item Back to Go card
+ \begin{itemize}
+ \item Bought PN532 NFC reader form Adafruit
+ \item Bunch of others\ldots
+ \item Travelled to Brisbane, and travelled around, logging trips
+ \item \verb#vbindiff# on before and after card data
+ \item Debit: default \$10 taken and, then credit on tap off
+ \item Need to find a preamble to identify the Go card
+ \end{itemize}
+ \item System re-use
+ \begin{itemize}
+ \item LA Tap card using Cubic Nextfare
+ \item 8\,B differenc beteewn a Tap card and a Go card
+ \end{itemize}
+ \item Manly Fast Ferry
+ \begin{itemize}
+ \item 1 open sector
+ \item can use Nested attack
+ \item different epoch for dates (2000-01-01)
+ \item no serial number on transactions, but the balance does
+ \end{itemize}
+ \item MyWay (CBR) and Smartrider (Perth)
+ \begin{itemize}
+ \item MIFARE Classic 1K
+ \item per-card keying, 2--3 fixed keys on every card
+ \item reader developed rom dumps
+ \end{itemize}
+ \item Lessons for system operators
+ \begin{itemize}
+ \item Open data formats ar better
+ \item otherwise anyone can figure it out
+ \item Since Opal gave info freely, he didn't try to break the rest
+ \item NFC smartcards have security weaknesses
+ \item Plan on compromise
+ \item Build fraud detection in
+ \item Don't store secret or PII
+ \end{itemize}
+ \item EMV: need on-line verification $\rightarrow$ latency
+\end{itemize}
+
+\subsection{PGP Keysigning}
+
+\begin{itemize}
+ \item Verified a bunch of keys
+\end{itemize}
+
+\subsection{Linux: the first second --- Alison Chaiken}
+
+\begin{itemize}
+ \item ME: a pain, Dell sells ME-disabled as an option for \$20
+ \item u-boot has a sandbox image allowing to simulate booting the host
+ \item can single-step bootloader
+ \item Boot process
+ \begin{enumerate}
+ \item On-chip bootloader
+ \item Bootloader
+ \begin{enumerate}
+ \item Read ACPI/device tree
+ \end{enumerate}
+ \item Boot kernel (ELF binary, after decompression)
+ \begin{enumerate}
+ \item \verb#_start#, sets up the stack, heap, FDs, env for an ELF binary to start
+ \item \verb#x86_64_start_kernel#, sequentially:
+ \begin{enumerate}
+ \item \verb#boot_cpu_init#
+ \item \verb#setup_arch#
+ \item \verb#page_alloc_init#
+ \item \verb#mm_init#
+ \item \verb#sched_init#
+ \item \verb#init_IRQ#
+ \item \verb#init_timers#
+ \item \verb#console_init#
+ \item \verb#rest_init# preemption,
+ multithreading, locks, RCU, \ldots); first CPU thread, then
+ \verb#cpu_idle#
+ \end{enumerate}
+ \item \verb#kernel_init# starts SMP
+ \item \verb#do_initcals# gets into device drivers
+ \item start userspace by calling \verb#init#
+ \end{enumerate}
+ \end{enumerate}
+ \item Tools
+ \begin{itemize}
+ \item \verb#u-boot# in sandbox
+ \item \verb#acpidump#
+ \item \verb#offcputime.py# from BCC (eBPF CC), to track the duration of each
+ thread of execution
+ \end{itemize}
+ \item Question: what would she change if making it all over again
+ \begin{itemize}
+ \item Express dependency between subsystems
+ \end{itemize}
+\end{itemize}
+
+\subsection{Unions: The way to hack society's operating system --- Robert Lechte}
+
+\begin{itemize}
+ \item Python, SQL queries, run servers
+ \item Most people don't see the point of unions
+ \begin{itemize}
+ \item 8 hour day
+ \item superannuation
+ \item paid-leave
+ \end{itemize}
+ \item How employment really works: money goes towards (example from Walmart)
+ \begin{itemize}
+ \item raw materials
+ \item staff (~2M\,people)
+ \item owners (mostly 4 children)
+ \end{itemize}
+ \item startups: blurry between staff and owners
+ \item still sounds bonkers that 4 people may get 100$\times$ more than the
+ people that actually do the work
+ \item Actually the same in tech space (leftover per employee)
+ \begin{itemize}
+ \item Facebook \$600k
+ \item Apple \$393k
+ \item Google \$270k
+ \item MS \$147k ?
+ \end{itemize}
+ \item Capital: anything that you own that can bring you a flow of money
+ (Thomas Piketty)
+ \item Conflict between thosewho do the work, and those who own the capital
+ \item The goal of unions is to move the balance of the line (\eg, material
+ comfort for a few vs. better conditions for everybody)
+ \item Personal adecdote
+ \begin{itemize}
+ \item Free speech incident
+ \item At risk of losing job
+ \item Unions provided support and advice
+ \item Good insurance policy
+ \end{itemize}
+ \item Australia: Professionals Australia / PESMA (ASU also covers software
+ devs)
+ \begin{itemize}
+ \item IP law
+ \item salary observancy
+ \item counselling
+ \end{itemize}
+ \item Don't be a product of your work environment, make your work environment
+ a product of you
+ \item Unions $\rightarrow$ a seat at the table (Scandinavia: >25 employees)
+ \item Hard to imagine what an alternative would look like (without naive
+ utopianism)
+ \item Public wealth decreasing into private hands except for Norway
+ \begin{itemize}
+ \item publicly held capital
+ \item built from selling oil resources, invested in non-oil resources
+ \item other countries can set up similar funds
+ \end{itemize}
+ \item Swedish m8
+ \begin{itemize}
+ \item move control of capital to unions (80\% of staff unionised)
+ \item flow to public
+ \end{itemize}
+ \item Must directly challenge capital, by rebuilding organised labour
+ \begin{itemize}
+ \item As tech workers, we have the strength to push for this
+ \item We can build the tools to do so, building a movement out of code
+ \item \url{http://www.ratemyboss.com.au} for Hospitality Workers
+ \end{itemize}
+ \item NGO tool: NationBuilder (proprietary)
+\end{itemize}
+
\section{Friday}
+\subsection{Keynote: Containers aka crazy user space fun --- Jess Frazelle}
+
+\begin{itemize}
+ \item (at some point) introduce syscall whitelist
+ \item tested by downloading all Dockerfiles from GitHub and checking that they
+ work
+ \item missed 32-bit \verb#send# and \verb#recv# in 64-bit containers
+ \item forbid cloning and prevent new privieges being given to a container
+ (through a flag)
+ \item limited \verb#CAP#s
+ \item systemd-nspawn gives \verb#CAP_SYS_ADMIN# to all containers
+ \item Intel Glass Containers (katacontainer): actually fast booting VMs (with kvm)
+ \item History of Linux containers (not Glass)
+ \begin{itemize}
+ \item Way before Docker, but made them more usable
+ \item OpenVZ, 2005
+ \item Linux-VServer, 2008
+ \item LXC, 2008
+ \item Docker, 2013, initially used LXC as a backend, then replaced by
+ native libcontainer
+ \item lmctfy (let me contain that for you)
+ \item rkt, 2014 (beginning of container wars)
+ \item runc, 2015, part of OCI (Open Container Initiative)
+ \item Container runtimes are the new JS frameworks
+ \end{itemize}
+ \item Are containers secure?
+ \item Containers are like LEGO
+ \begin{itemize}
+ \item VMs, Jails and Zones are like LEGO pre-assembled with glue
+ \item Containers are the box with all the bricks and a suggestion of what
+ you can do with them
+ \item You can turn certain namespaces on and off
+ \item You can share namespaces between containers (\eg, PID namespace, run
+ \verb#strace# in a container; or network, and run \verb#wireshark# in a
+ container)
+ \item Kubernetes pod share PID and NET namespaces among all containers
+ \item Docker has sane default
+ \end{itemize}<++>
+ \item Game: \url{http://contained.af}
+ \begin{itemize}
+ \item container game to learn about container
+ \item CTF: flag in host VM
+ \item noone has got it to dat
+ \end{itemize}
+ \item Containerising the desktop
+ \begin{itemize}
+ \item \verb#runc# (had to convert everything from Dockerfiles, has a tool
+ that kinda works); no networking, \verb#netns# to work around that
+ \item root-less containers, sandboxed apps
+ \item moved from Debian to CoreOS (derived from ChromeOS, incl. security
+ features; itself based on Gentoo)
+ \item force you to use containers
+ \end{itemize}
+ \item Generate \verb#seccomp# filters at build time
+ \begin{itemize}
+ \item more exhaustive than profiling
+ \item avoid getting bored and just disabling the security policy
+ \item the Go compiler writes the assembly for all the syscalls
+ \begin{itemize}
+ \item some issues:
+ \item \verb#exec.Command# can't get other binaries' profiles
+ \item Go plugins (\verb#plugin.Open#)
+ \item Run-time syscall being specified to \verb#syscall.RawSyscall#
+ \end{itemize}
+ \end{itemize}
+ \item Alternative code library: \url{https://metaparticle.io/}
+ \begin{quote}
+ The goals of the Metaparticle project are to democratize the development
+ of distributed systems. Metaparticle achieves this by providing simple,
+ but powerful building blocks, built on top of containers and Kubernetes.
+ \end{quote}
+ \item SCONE protection against compromised host
+ \begin{itemize}
+ \item not DDoS or chache attacks
+ \item enclave where everything in the container is trusted, but the host
+ isn't
+ \item syscalls outside of the enclave are expensive
+ \item doesn't protect aganst side channels (Meltdown/SPECTRE)
+ \end{itemize}
+ \item Multi-tenancy
+ \begin{itemize}
+ \item Soft multi-tenancy: trusted tenants
+ \end{itemize}
+ \item Conclusion
+ \begin{itemize}
+ \item Containers with sane defaults are sandboxes, bewore of changing them
+ \item Need to apply same principles of sandboxes to containers
+ \end{itemize}
+\end{itemize}
+
+\subsection{Let me secure that for you --- Kirk Jackson}
+
+\begin{itemize}
+ \item Building a secure web application
+ \begin{itemize}
+ \item Start with the user's needs
+ \item Software Development LifeCycle (SDLC)
+ \item Eventually put it up on the Internet
+ \item \ldots
+ \item Put a firewall in front
+ \item \ldots
+ \item PCI: Web application firewal + Proxy + AV on server
+ \item \ldots
+ \item IDS, Data Loss Prevention, IAM
+ \item \ldots
+ \item SIEM to capture logs
+ \item \ldots
+ \item Is the code secure? Security training/reviews/analysis, \ldots
+ \item RASP ??
+ \item OS hardening
+ \item File integrity monitoring
+ \item \ldots
+ \item Governance, patching, configuration management, monitoring
+ \item Policies, standard operating procedures
+ \item \ldots
+ \item Audit, configuration reviews, pen testing
+ \item Will attacks manage to bypass all this
+ \end{itemize}
+ \item In summary \begin{itemize}
+ \item Building securely
+ \item Hosting securely
+ \item Making sure it is and remain secure
+ \item Expensive
+ \end{itemize}
+ \item Big companies tend to get breached through bugs in their code
+ \begin{itemize}
+ \item None of the security stack will catch \emph{business logic} bugs
+ \item How quickly can business logic bugs be fixed
+ \item Should the rest of the process be shortcut in those cases?
+ \end{itemize}
+ \item Idea: replace WAF with virtual patching layer: lmstfy
+ \begin{itemize}
+ \item Available to security teams in lieu of software develompent
+ \item Only patch known vulnerabilities and issues
+ \end{itemize}
+ \item What does it do?
+ \begin{itemize}
+ \item \verb#mod_security# + OWASP Core RuleSet + node.js to write
+ capture/rewrite code
+ \item Redis for session context storage
+ \item like a WAF, but only for known, business logic, vulnerabilities
+ \item One config file + module per found vulnerability (use issue tracker
+ number)
+ \item Tricks (because no Db access)
+ \begin{itemize}
+ \item deny admin access if session didn't receive
+ a 200 on login previously
+ \item object access: parse returned list of items for a session, only
+ allow those URLs
+ \end{itemize}
+ \item ability to run JS code
+ \begin{itemize}
+ \item (JS $\rightarrow$ full DOM access)
+ \item can log meaningful errors
+ \end{itemize}<++>
+ \end{itemize}
+ \item PenTest tool: \verb#sqlMap#: use SQL injection to discover the DB setup
+ \item OWASP ModSecurity Core Rule Set: lots of coverage, tuned to avoid false
+ positives
+ \item Conclusion
+ \begin{itemize}
+ \item Virtual Patching is a thing
+ \item faster turnaround waiting for a proper bugfix in dev
+ \item prepare the infrastructure in advance
+ \end{itemize}
+\end{itemize}
+
+\includegraphics[width=.5\textwidth]{IMG_20180126_105123.jpg}
+\includegraphics[width=.5\textwidth]{IMG_20180126_105834.jpg}
+
+\subsection{Driving Virtual Reality from Linux --- Keith Packard}
+
\end{document}
diff --git a/2018lca/IMG_20180126_105123.jpg b/2018lca/IMG_20180126_105123.jpg
new file mode 100644
index 0000000..66ec7fb
--- /dev/null
+++ b/2018lca/IMG_20180126_105123.jpg
Binary files differ
diff --git a/2018lca/IMG_20180126_105834.jpg b/2018lca/IMG_20180126_105834.jpg
new file mode 100644
index 0000000..5b99cd5
--- /dev/null
+++ b/2018lca/IMG_20180126_105834.jpg
Binary files differ