[apparmor] apparmor development planning sessions summary

Sat May 19 10:57:52 UTC 2012

At the most recent UDS we had 3 apparmor planning sessions

AppArmor testing - which focused on ways to improve the test suite
AppArmor Development - which focused on prioritizing dev for the next cycle
AppArmor integration and packaging in Ubuntu - which focused on packaging
  and integration mostly around Ubuntu, but also what could be pulled back
  upstream

Unfortunately I have not found audio from the sessions but if I find them
I will reply to this with the details.

Below is a summary of each of the sessions and a few other highlights from
the week.  At the bottom I have included the raw notes from the etherpads,
used during the session, with each session separated by
-------------------------------------------------------------------------

AppArmor testing:
  AppArmor has several disparate test suite, mostly grown from home rolled
  bash scripts, that have been extended over the years. They are crufty
  and have been probablematic to extend
  - The kernel regression tests will be moving to py-unit, as the driver
    and C/what ever language is appropriate helpers. New tests will be
    developed under this framework, and old tests will be eventually
    moved over.
  - Some user utils are being rewritten in python (perl is not a well
    supported language by the currently active developers), and as these
    applications are rewritten, unit tests leveraging py-unit will be
    created.

AppArmor Development:
  The discussion focused around the what improvements are highest priority
  for the next cycle. The work is largely driven by LXC, and DBus.

  LXC: the work here breaks into a few main components
  - stacking policy so that a container can have its own policy separate
    from system policy.
    - this requires improvements to apparmor namespaces and extensions
      to set up stacking
    - this will be also useful beyond lxc for composing policy dynamically
  - fixing the issues with disconnected and deleted paths. This is a long
    standing issue that needs to be resolved and will bring improvements
    to general policy. There is no single solution to this problem and it
    will require multiple improvements
    - labeling support, for some situations
    - extending mount rules even further
    - delegation of file descriptors, which again will be useful for a
      more dynamic policy.

  DBus: - a long standing problem. We need to get the prototype back up
    and beat it into shape.

  Other points covered where
  - aa-easyprof a templating tool for profile generation will be merged into
    upstream.

  - environment filtering. This was discussed last cycle and there probably
    won't be a lot of time for it this cycle but it would be nice to get
    a prototype out.

  - cgroups for resouce control. Again not a lot of time for it but there
    is a prototype I am reviving so people can play with it.

  - network mediation improvements. Needed but not a lot of resources to
    put on it.

  - pythonizing aa-enforce, aa-disable, aa-complain. This is a requirement
    for Ubuntu to be able to carry these base tools on their livecds.

  - profile repository. Some basic improvements to improve the tools so
    they can interact with it.

AppArmor packaging and integration into Ubuntu:
  - how to improve bug report information via apport
  - is it worthwhile to ship supported but disabled profiles?
    - yes but it needs to be easier to discover and enable
    - what other profiles are candidates
  - more discussion around improving the profile repository
    - how to better collaborate and improve cross polination/sharing between
      distro profiles
  - discussions around what would be needed to support apparmor backports
    if required as part of Ubuntu's LTS backport packages.

Beyond the 3 scheduled meetings we talked out of bounds about implementation
details, and requirements.

Discussed creation of a firefox plugin to make to make enabling firefox
confinement easier. This would use aa-exec, and a non-attaching profile to
allow it to be enabled per user, firefox profile.

jdstrand demoed his recently resurected sandbox utility, which leverages
aa-easyprof and aa-exec. Again the plan is to get this merged upstream
so people can play with it.

-------------------------------------------------------------------------
AppArmor testing

Welcome to Ubuntu Developer Summit!

#uds-p #track #topic
put your session notes here

Upstream Tests scripts
- parser parsing regression
- unit tests within various tools
  - parser custom unit tests
  - libapparmor (gnat)
 - aa-easy prof regression testing is pyunit
- functionality regression test suite - this is the one we mostly want to focus on
  - home rolled bash
    - brittle
    - hard to add new tests to

pyunit has some advantages
- people on team using it
- some tools are being written in it which makes it easy to test them
- supports inheritence, etc

pyunit drawbacks:
- setup/teardown could be slow dependending on how its down
- each test isn't necessarily a unit test per se, so the model doesn't fix perfectly

Decisions:
- use pyunit
- anything new should be pyunit
- start with moving some things over to start to flesh out the infrastructure
- split tests up somehow and not monolithic
- should use python3

apparmor-utils
- move to pyunit for the python tools and python-apparmor as they are written
- this is critically important for aa-genprof/aa-logropf, etc and getting them tested

kernel level stress
- focus on other areas first
- need to be able to tell the kernel stress testsuite to stop after a while
- various change_hat transitions are not currently tested under stress

Actions
[sbeattie] implement base infrastructure in pyunit so we can start moving things over
[sbeattie] once base infrastructure is written, the python library, particularly aroung profile generation, can be written so that we can use the library in the apparmor utils tools
[jjohansen] review regression tests
[jjohansen] lxc testing, serge has some tests to look at

What isn't being tested that we like to test:
- unit testing for compiler from userspace
 - dfa matching
 - make matching routines in the kernel available in the libraries as well
 - initscript testing
  - boot regression tests are in qrt
  - can we merge the Ubuntu changes for the initscript back to upstream?  yes-- because most of the upstream stuff is crufty

---------------------------------------------------------------------------
AppArmor Development

[jdstrand] Pythonize simple apparmor tools (aa-enforce, aa-disable, aa-complain)
- aa-enforce- strip out flags and remove symlink
- aa-disable - just use the symlink
- aa-complain may not be so low hanging. do symlink as first pass and then maybe strip out stuff
[jdstrand] commit aa-easyprof tree soon (trunk only)
[jdstrand] review ARB requirements and update policy
[jdstrand] start python library

Environment filtering
[jjohansen] patch in progress for direct match

LXC
shouldn't need extra flags - workarounds sufficient for now, but need to be fixed by 13.04 or so
stacking profiles is a high priority (lot of work, may not hit for 12.10)
overlayfs bug regarding private namespace (related to disconnected paths and private namespace)
[jjohansen] determine priority of the above with Gary Poster
hallyn wants to prevent a udevadm trigger
- netlink
- netlink second layer
- will need to check the policy to see if it will be blocked and if so test the policy before uploading

DBus
- porting work getting there
- interface that we can upstream for dbus to know what is happen
- get dbus work into ppa (dbus patches are still against 1.4, but patches based on upstream feedback)
- once it is in a ppa, send upstream for review
- policy language needs to be refined

Cgroups
- early protoype, not for 12.10

Network mediation
- 

Profiles repository
- existing apparmor-profiles project is bottlenecked on apparmor mailing list/merge request
- could add a 'community/' directory to help
- userspace tools are still not suggesting things
- could adjust the tools to use bzr to suggest and publish to private branch and perform a merge request

-------------------------------------------------------------------------
AppArmor integration in Ubuntu

New items:

apparmor apport spam
- most bugs due to a harmless denial
- [mdeslaur] and grep to hook so that only denials for that package trigger the hook. also verify all packages that ship policy have a hook
- apparmor hook doesn't screen the log based on profile so a bug in package X with apparmor will also a trigger in package Y that uses apparmor
- want to be able to screen on a list of profiles

shipping disabled profiles: how worthwhile is this? It has value just like shipping daemons that are diisabled by default
- how can we make it easier to discover/enable
  - /etc/default in and commented  (conf files) - 
  - debconf questions?
    - depends on package
    - what of the delta with debian?

if worthwhile, identify other candidates:
- [jdstrand] squid3
- [jdstrand] dovecot
- smbd - maybe with samba extractor

Enabled profile targets:
- nmbd
- winbind
- [jdstrand] gwibber-service
- others (https://wiki.ubuntu.com/SecurityTeam/Roadmap)

• repository. how can we improve this with reasonable effort?
 - [mdeslaur] when go to profile something, can we query the server
  - use standardized naming convention and if find something, then prompt, otherwise advertise
 - figure out a way to make Ubbuntu profiles available to others once we have shipped them
 - figure out a way to make profile sharing between distros work better

[sbeattie] post outcome of this meeting to the mailing list

* aa-easyprof - templating tool

jjohansen:
apparmor backports, with the backported kernels it may be worth while supplying a backported userspace, and may even be necessary depending on what other parts of the userspace get backported.
 - could backport the apparmor userspace
 - could also just adjust the backported policy to work with the new tools
 - lxc stuff?
- decide on a case by case basis on if we need to actually backport unless we have to

- what of packages that auto update (firefox, chromiumn) if profile is included in the package
  -only an issue if people install the upstream versions

Existing profiles in Ubuntu:
https://wiki.ubuntu.com/Security/Features#apparmor
https://wiki.ubuntu.com/SecurityTeam/KnowledgeBase/AppArmorProfiles

* profile2audit.log utility for testing of new genprof/logprof - could also be useful for merging profiles (generate faked audit.log, then run logprof on it)