Tag Archives: qcon

unprivileged containers – jessie frazelle – qcon

Posted on by
Reply

For more QCon posts, see my live blog table of contents.

Today

  • Docker typically runs as a privileged user.
  • Containers are meant to limit the damage from a compromise. The world an attacker can see inside the container is a limited one)
  • Want unprivileged containers so don’t need sudo/privileged access to launch container in the first place.

Chrome sandbox on Linux

  • uses Seccomp, Namspaces, Apparmor.
  • doesn’t need to be run as root.
  • each tab is in its own namespace – process only knows about itself
  • if Chrome can do this, why not Docker

General notes

  • cgroups (Controlgroups) limit what resources a process can use and how much.
  • Each time you docker build something it spawns a new container. Just blocking things wholesale would cause issues here.
  • I had trouble following what was current/future in the examples.

Future

  • Won’t need to run as root
  • Can customize sandboxes from defaults, better UX for dealing with security policies.
  • “postgres should maintain a postgres profile”

Impression: A lot of this was recorded demos (show typing commands as graphic/video that plays out.) For the namespaces, it was helpful seeing the examples. For the Docker part, some of it went over my head. I only know a little Docker. And my system admin Linux isn’t strong enough to understand the implications of everything she brought up either. I still go something out of it though. And learned things that would be interesting to read more about.

applying java 8 idioms to existing code – trisha gee – qcon

Posted on by
Reply

For more QCon posts, see my live blog table of contents. Last year, she talked about creating new apps in Java 8. This year is about migrating to Java 8 for “legacy” code. She showed specific JetBrains IDEA features. I just took notes on the concepts that are IDE agnostic. Presentation will be at bit.ly/refJ8

Usage from audience poll

  • About half compile with Java 7
  • About half compile with Java 8
  • About a quarter (half of Java 8 people)  compile with Java 8, but apps still looks like Java 7

Why use Java 8

  • Performance improvements in common data structure
  • Fork/Join speed improvements
  • Changes to support concurrency
  • Fewer lines of code – less boilerplate
  • New solutions to problems – more elegant/easier to write code
  • Minimize errors – ex: Optional avoids NullPointerException

Before refactoring

  • Make sure have high test coverage
  • Focus on method level changes – tests should still work
  • Have performance tests too to ensure not negatively impacting system
  • Decide on goals – performance? clearer code? easier to write new code? easier to read new code? use lambdas because team used to it? developer morale?
  • Limit the scope – small incremental commits. Don’t make change that will affect whole code base.

Straightforward refactoring of lambda expressions

  • Predicate, Comparator and Runnable are common places where might have used anonymous inner classes and can switch to lambdas
  • IDEs suggest where can replace code with lambdas (SonarLint does as well)
  • Quick win – reduce old boilerplate
  • [She didn’t talk about this, but it will make your code coverage go down. Make sure your management doesn’t worry about that!]
  • Lose explicit type information when use lambda. Might want to extra to method to make it clearer and call the method from the lambda.

Abstract classes – candidates for lambdas

  • See if can use an interface (if single abstract method) so can start using lambdas
  • Tag with @FunctionalInterface to make clearer
  • Then look at implementers (especially anonymous inner classes) and see if can convert to lambda expressions

Conditional logging

  • if (debug) { log.debug() } pattern is a good candidate for logging
  • Often people forget to add that conditional so opportunity to defer evaluation for those too via search/replace. Also, protects against conditional not matching log level. if (debug)  { log.severe() }. Uh oh!
  • Use a default method on the existing logging interface that takes a supplier instead of a String and has the if check

Collections and Streams API

  • Turn for loops into collect() or forEach()
  • Remember you can call list.forEach() directly without going through a stream
  • If do something like get rid of initial list size, test performance before and after to make sure not a needed optimization
  • The automatic streams refactoring might not result in shorter code. Think about whether the surrounding code wants to be refactored as well. A more dramatic refactoring. Go back to later. Also, avoid refactoring if and else code since not  a simple filter.
  • Remember to include method references when converting code too
  • Watch for surrounding code. For example, if sorting a list, move into the the stream. Or if iterating over new list, add as a forEach instead of turning into a list.

Optional

  • Be careful. Refactor locally.
  • Easy to accidentally change something that requires changing a ton of code.

Performance

  • Lambdas expressions don’t necessarily perform better than anonymous inner classes. Similarly for streams.
  • Using lambdas to add conditional logging is a big quick win performance improvement.
  • Streams didn’t need the “initial size of list” optimization
  • Adding parallel() to stream operations sometimes performs better and sometimes worse. Simple operation often performs worse in parallel because of overhead of parallelizing.
  • Introducing Optionals increases cost.

Java 7 refactorings

  • Use static imports
  • Reudndant type in diamond operator for generics

the bad things happen when you’re not looking – ryan huber – qcon

Posted on by
Reply

See the live blog table of contents. Gist is posted at https://goo.gl/ZAxCnH (github login required)

Ryan was the first security employee at Slack. He is doing an experiment where red slides means don’t take pictures or tweet about the slide. I really like that idea. It makes speaker intent clear.

How find out about a problem

  • Don’t want to find out from Brian Krebs that you’ve been breached
  • Don’t want hackers to tell you something strange is going on. They are done at that point and are showing off
  • Even worse – don’t notice

General Notes

  • Time to detect is important metric
  • Credential theft is biggest/one of the biggest
  • Goal – watch as many things as possible, but don’t be a dashboard. Want as little as possible on the dashboard. If it is mostly empty, things will get noticed when they are there.
  • Bad model – NetCool – train people to acknowledge all alerts and they miss things because bad habit
  • The defender’s advantage – if the attackers don’t know what you are looking for/trip wire, they dont know what to avoid
  • “Zero days are not invisibility cloaks” – other boxes can pick up on it
  • The hypothetcial malicious insider – a former security team member has a lot of knowledge. And an insider with credentials has access
  • Don’t overwhelm users. Confirm bulk actions in bulk not one at a time.
  • Canaries – need to validate monitoring, recording, etc.
  • Do table top red team exercises if not doing real ones.

Slack Security

  • Setup reliable logging platform
    • RELP (reliable event logging protocol)
    • steamstash/logstash -> Elastic search (Splunk is superior but costs more)
    • Two weeks of data is about 2 terrabytes of logged data. Almost never sits on disk
  • auditd – part of Linux. Run auditctl commands and kernel looks for matching events.
  • audisp – works with auditd to transform data
  • osquery – Facebook project for system monitoring using SQL
  • ElastAlert – yelp project to pick up on ElasticSearch events. Does queries on a timer against Elastic Search.
  • AlertCenter – have SecurityBot looking at alerts. Security bot posts to Slack asking user to type “acknowledge” on phone to confirm action. That way, know have phone and not just Slack account. If no reply in X hours, goes to Pagerduty. Automated triage to avoid flood of data. Instead of security team looking at all alerts, whole company is helping. This means the security team responds to less than 5 alerts a day.

Rules

  • Listeners – specific events
  • Time awake – nobody is awake for 24 hours. Trigger an alert when this happens
  • GeoIP – Doesn’t work perfectly. T-Mobile has feature that can travel abroad without paying roaming. This works by routing some traffic through Texas so your location keeps jumping between Texas and aboard
  • IPs – less unique IPs than you’d think. Worth looking at when user comes from new IP.