AppArmor development and integration
Discuss where to focus AppArmor development and integration efforts, part 1 of 2.
Blueprint information
- Status:
- Complete
- Approver:
- Jamie Strandboge
- Priority:
- Medium
- Drafter:
- Jamie Strandboge
- Direction:
- Approved
- Assignee:
- None
- Definition:
- Approved
- Series goal:
- Accepted for oneiric
- Implementation:
- Informational
- Milestone target:
- ubuntu-11.10
- Started by
- Jamie Strandboge
- Completed by
- Jamie Strandboge
Whiteboard
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/
- 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
Testing
- 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
- https:/
- wiki page
- announcement
- new profiles as security updates
profiles
- what we currently have: https:/
- high profile security
- desktops are interesting
- https:/
- 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
dbus/apparmor
- ipc