Future of Arkose and application sandboxing for Precise

== From etherpad ==
Originally arkose just did CLONE_NEWPID and CLONE_NEWNET et al.
Now does LXC
Has options to allow/disallow networking, bind-mounts, then provides shell
Also has GUI that does same thing
Can optionally pass through D-Bus, other services
Because it's LXC, doesn't help if you start it as root
Can specify specific directories should be bind-mounted or cow-mounted with aufs/overlayfs
Can write profiles in a file for what specific programs can dodo we
Has basic network filtering using point-to-point IP inside container
Working on filtering D-Bus proxy

Requires privilege
Shows prompt on every startup

Installed in edubuntu, but not used by anything currently
Some people use Skype profiles

Want to be able to generate Apparmor profiles in addition to LXC containers
 - Some capabilities of Arkose can be done in Apparmor, some not
 - Have mechanism to express capabilities of underlying sanboxing system, then choose the one that needs to be written
 - Want user to be able to modify profiles

We know how to remove the need for privilege to create namespaces in certain circumstances
 - Networking will probably take privilege

Can we combine apparmor profiling with Arkose's networking et al filtering
  - (though apparmor is growing networking filters soon)

Can start Arkose container in an arbitrary chroot

Could move to D-Bus/PolKit service?
 - Hard to separate UI and "backend", because needs access to X, session bus, etc.
 - But want to be able to say "this profile is good, don't prompt me again"

Service needs to run as root, and start things as the user
 - Risky (duh)
 - Adds attack service for things which may not be risky in the first plcae

Apparmor doesn't require privilege once profile is loaded

Option to do filesystem stuff using unionfs-fuse+fakechroot
 - Not as safe
 - Doesn't require privilege
 - Can still do D-Bus, X, etc. passthrough/filtering
 - D-Bus library is slow

Setting up LSM interface to D-Bus
 - Moving apparmor pieces to that where possible
 - Could do Arkose D-Bus filters with that
 - (Not this cycle)

How to distribute profiles?
 - Currently distributed by example with arkose package
 - Should they be distributed with other packages?
 - apparmor includes with firefox, etc.; also ships apparmor-profiles for reference
   - Now includes non-conf file that can be customized
   - Can't include skype profile with skype package; shipped in /usr/share/doc (not by default)

Spawning commands in existing containers
 - Needs kernel fixes
 - Hopeing it will land in next few weeks

Does it help with privileges?
- Could use lxc commands to get console, but command line only

schroot? Can we sell arkose as a better schroot?
 - Can emulate buildds not having networking

Future LXC work will likely include seccomp_filter support. This is available since Oneiric.
http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-oneiric.git;a=blob;f=Documentation/prctl/seccomp_filter.txt;h=5afb4787e6aa88905861f3994757abd4e48802ef;hb=HEAD
(Oneiric lacks exec support, which should be available in Precise.)

Any work with capabilities should be wary of potential escalations:
http://forums.grsecurity.net/viewtopic.php?t=2522&p=10276

= Security team review =
The session did not capture the security team's thougts on arkose and application confinement. Here is our position

* The good:
 - arkose works very well as a schroot replacement for developers, as namespaces in the Linux kernel are like supercharged chroots
 - arkose provides a nice gui and cli frontend that makes it easy for people to specify what access an appliaction should have
 - arkose could theoretically be integrated with schroot/sbuild
 - arkose uses the new dbus-proxy, which can be used for dbus mediation/filtering

* the bad:
 - namespaces are not considered secure at this time by upstream kernel and lxc developers (there are still several places in /proc, etc that are exposed)
 - namespaces require a lot of privilege to setup (via arkose/LXC or otherwise)
 - arkose uses bind mounts and overlay filesystems (aufs presently) that require a lot of privilege to setup
 - setting up a namespace can be a heavywight operation
 - because the dbus-proxy is a separate daemon, there is a not-insignificant performance hit when using it. DBus is already too slow, so this is a problem for applications that use DBus heavily
 - arkose requires configuring the isolation on each application launch, which is a usability issue
 - username namespaces are not present (ie root in the container is not root in the host and uid 1000 in the container is not uid 1000 in the host). While patches exist, probably won't be in time for precise)

Current problems:
Based on the 'good' and the 'bad' above, namespaces are not considered a mature technology to rely on for security at this time. Work is ongoing in this area. The current design of arkose (because of the limitations of namespaces) requires a lot of privilege to setup container. When weighing the risk of the application to be confined vs the large attack surface that is added by arkose/etc, it is probably not worth confining the application in this manner. Additionally, applications that are not confined could use the arkose tools to attack the system (eg, arkose needs a lot of privilege. That privilege must be granted somehow. Once it is granted, a remote attacker could attack the tools for setting up a container, which actually adds *more* risk and a larger attack surface to the Ubuntu desktop than not having the tool at all, thus *decreasing* the overall security of the desktop)

Moving arkose forward:
 - dbus-proxy should move to dbus proper using the dbus plugin framework (LSM-style, currently in development for dbus 1.5 -- not for precise)
 - namespaces need to be blessed by upstream kernel as a security tool before we use them in a security context
 - removing privilege from arkose: this cannot be done until the LXC tools and overlay fs setup can be run unprivileged (not likely). Currently, arkose uses sudo/pkexec, which is problematic because it is neither best practice for desktop applications and we have sudo ticket timeouts. It has been proposed that the privileged actions be moved to a dbus service that runs as root and use policykit to protect it. This is fraught with danger and extremely easy to get wrong. This begs the question-- what are we trying to protect that requires a privileged daemon to run on its behalf to protect it? The best course forward for arkose is to have a concept of 'profiles'. The arkose gui can output a profile that the user can then put somewhere that only root can write it, and have an upstart job that loads these profiles on boot. This takes the privileged actions away from the user such that they can't be used in an attack, and also improves usability so that the container configuration is done only once.
 - the security team is developing a small tool for use by the ARB and Ubuntu developer SDK for outputting apparmor policy (will be available in precise). The arkose gui could also use this as a backend to emit apparmor policy (note that arkose actually loading the apparmor policy requires privilege and suffers from the same privilege problems as above. Of course, the emitted policy can simply be dropped into /etc/apparmor.d)

Moving application confinement forward:
Since many teams are interested in application confinement and arkose/LXC confinement is not suitable for precise (or possibly 'Q'), here is the security team's recommended course forward:
 - the ARB, developer SDK, and any other teams should be using apparmor at this time:
  - apparmor is a mature technology, actively maintained and in use in default Ubuntu since 7.10
  - the security team is writing a cli tool to make policy development extremely easy (taking cues from arkose)
  - Ubuntu contains a dh_apparmor already. Package integration of apparmor policy is one line in debian/rules
  - apparmor policy is shipped in the package. This allows for ease of auditing by ARB, confinement not modifiable by applications in the users session (ie, attack surface of Ubuntu desktop is unchanged) and maintenance of confinement is centralized (eg, new version of app now needs expanded/reduced access -- package for new version ships new apparmor policy with everything needed)
  - apparmor policy load is nearly instantaneous on boot and there is no overhead when the application loads (ie, no 'setup' of the confinement). Real world usage has apparmor being used on systems with thousands of profiles loaded
 - Limitations
  - resource controls for apparmor are coarse-grained. basic cgroups control is planned, but not currently a priority for precise (this can be adjusted)
  - network controls for apparmor are coarse-grained. bind/send network controls are planned and at least bind should hit in precise. Future will have auto iptables rules and secmark
  - dbus mediation won't be finished until 'Q'

== Actions ==

NOTE: (jdstrand) aa-profile task is being tracked in security-p-app-isolation. Removing task for jdstrand and adding dependency on that blueprint

Work items for precise-alpha-2:
[stgraber] Support for different root path in wrapper (allowing to start an app from a chroot running a different version of the distro): DONE
[stgraber] Add support for lxc-attach (won't be supported by 12.04's kernel): POSTPONED

Work items for ubuntu-12.04-beta-1:
[stgraber] Extend the arkose cli to provide all the options the python module support: DONE
[stgraber] Finish implementation of "filtered" networking (needs more thinking on how to deal with IPv6 and offer a reasonable interface to iptables probably through ufw): POSTPONED

Work items:
[stgraber] Look at possible apparmor support for the wrapper: POSTPONED
[stgraber] Look at moving code from the arb-wrapper into Arkose, allowing to create environments without ever needing root (very limited feature set): POSTPONED
[sbeattie] review apport library to look for sensitive information filtering: POSTPONED
[stgraber] Find ways to "remember" a profile and re-execute it without prompting the user (dbus service + polkit is a candidate): POSTPONED