AppArmor development and integration

Registered by Kees Cook

Discuss where to focus AppArmor development and integration efforts, part 1 of 2.

Blueprint information

Jamie Strandboge
Jamie Strandboge
Series goal:
Accepted for oneiric
Informational Informational
Milestone target:
milestone icon ubuntu-11.10
Started by
Jamie Strandboge
Completed by
Jamie Strandboge

Related branches



Etherpad notes:

Userspace tools improvements: what are they
- rewrite in something other than perl?
 - not at this time. eventually yes, but other things are needed
 - new tools in another language-- python if stuff is missing, then write in in the new parser stuff split out
 - use existing tools to do profiling and make sure they do it right
 - rate limiting (short term-- flip rate limiting bit and) (aa-genprof)
  - deroot auditd and use those logs
  - learning stream not to logs
 - does not offer to edit abstractions
 - doesn't suggest to use variable (@{PROC} and @{HOME})
 - alias support
 - suggesting community profiles
 - tool workflow
  - rejects from other profiles not handled well
  - suggestions for globbing are not great
  - blacklisting of applications
  - globbing in profile attachments
  - list of log files
  - is aa-logprof still viable?
 - named profiles and binary globbing (all tools)
 - P[Uu]x
 - some bug jj knows about that is hard to describe (and has fix)
 - child profiles
  - nest 1 level
  - encapsulated child profiles (parser and tools) and how they interact with hats
- parser memory usage (patch pending)
- dfa sharing in the parser
- userspace needs to migrate away from needing compat patches (ie, use new introspection interface)
- v3 tagging
- aa-notify rate limiting/summarizing
- some sort of tool to get from notification to policy edits
- [ACTION] kees: reduce perl dependency for Ubuntu ISOs

Misc userspace
- initscripts
 - bash vs inistscript vs parser
- upstart

- New tests -- eg, new code is submitted and reviewed, tests are written and then we iterate on the tests before commit
 - dfa (patches pending)
 - take those dfa patches for userspace and do tests
 - containers (kernel side should be fine, need tests. lxc integration)
 - network (pending)
 - ipc (pending)
 - extended permissions
 - delegation (if it is exposed again)
 - look through recent kernel improvements, need the tests
- infrastructure
 - test framework improvements
 - [ACTION] sbeattie jenkins and getting testsuites
 - [ACTION] jdstrand - put test suite stuff into upstream wiki

kernel improvements: what are they
- kernel variable
- ipc
- network
  - stage 1,2,3
- delegation (maybe deferred)
- extended permission
   - mount
   - chmod, chown
   - setuid, ....
- introspection interface
- dfa improvements
- set load
- rcu
- auto cleanup of null profiles
- learning interface
- stacking
- hybrid
- v3 tag and keep semantics as we go forward
- modularization of LSM
 - tomoyo and apparmor want it
 - Debian wants this as well to reduce the memory footprint on booted kernels after selecting a given LSM
 - can relate a bit to the stacking effort, since that will put other users in Debian's position
 - review previous implementation and potentially address previous concerns in a new way

kernel upstreaming
- upstream improvements listed above
- we (Ubuntu) need to carry the compat patch for a while because of lts-backports
- need the compat patch for networking and introspection. probably need for o+1
 - to get rid of this the tools need to be updated

community growth
- wiki page
- announcement
- new profiles as security updates

- what we currently have:
- high profile security
- desktops are interesting
- anything that accepts a network connection
- tighten npviewer
- lock down plugin-container (flash)
- dropbox
- ubuntuone
- opt-in profile updates ala old scheme for things that are neither security or SRU

- ipc


Work Items

This blueprint contains Public information 
Everyone can see this information.