This is a dump from the various session's etherpads, hopefully I haven't missed
anything
AppArmor LXC development
------------------------
Features in development
- stacking
* POC in 2-3 weeks for base stacking (ie, not userspace namespaces, have
aa_stack_profile as opposed to change stacking in policy)
* this allows is to both limit the container and have profiles within the
container
- conditional rules
* base conditionals by 13.04
* eg:
fs=procfs proc/foo rw,
label=foo /foo/bar rw,
- mount fixes/improvements
* 'umount /mnt/{**,},' - delegation (parent hands capabilities to the child)
Cleaner way of dealing with things like:
deny /sys/[^f]*/** wklx,
deny /sys/f[^s]*/** wklx,
deny /sys/fs/[^c]*/** wklx,
deny /sys/fs/c[^g]*/** wklx,
deny /sys/fs/cg[^r]*/** wklx,
* should be in 13.04 as part of conditionals work
- extended regex matching and boolean operations
eg. allow /** - /sys/fs/cgr*/** wklx,
- netlink? (to filter uevents) - eg network netlink (create,bind,rw),
- on schedule. will look like regular network rule. First pass, mask off a
family or not. planned for 13.10, maybe sooner
- this will also bring in abstract unix domain socket mediation
- labeling
- bug on declaring variables outside of the preamble (ie, in a .d directory)
Can we have all of the above by 14.04? Yes. Work is planned and in progress
- stacking prototype is almost done
- conditional rules are a bit later (base conditionals in 13.04, others later)
Usernamespaces - 14.04
Work items:
These are already planned and need to be brought forward from quantal bps.
These are assigned to members of the security team and will be
reprioritized/revised for raring
Application Confinement (Content Access Helper)
-----------------------------------------------
Application isolation ensures that applications can only access the data that
is required to run. Often data needs opportunistic access. Eg, a photo
application needs access to an image file for upload. We should provide a
helper to enable confined applications to access files and other content
selected by the user.
Requirements for first iteration:
- file type specific (eg, photos, contacts, etc) with different handlers
1. files
2. photos (needs design)
3. contacts
- need to be able to handle different backends
- need to be able to handle multiple files of same type
- as toolkit agnostic as possible
Future:
- Legacy applications and file selector: could patch gtk to invoke helper
Other helpers need an api that developers would program to
Code to be written:
- trusted helper daemon
- library for API (getFile, getContact, get...)
Questions:
- saving
- how do you save a contact?
- Is the permission grant temporary, or persistent for the sandbox?
- ie. next time the application is launched, or after a reboot is the
extended access remembered
- Is the grant of new permission local to the task or a sandbox?
- this is irrelavent if each application gets its own sandbox but if the
sandbox can be shared...
Prior art:
- iOS does source review for applications that need access to files out of the
sandbox
- Android has an API, but can access anything on the shared drive and anywhere
in its sandbox
- OS X sandbox: has a trusted helper
- http://plash.beasts.org/powerbox.html works with gtk, changes file selection
to do it
- new Windows 8 has something like a trusted helper
- Some similar design work going on at GNOME:
https://live.gnome.org/GTK%2B/ContentSelection,
http://afaikblog.wordpress.com/2012/05/10/gnome-design-update-part-two/
2 parts:
1. API (needs to be defined). Eg the developer wants to upload a picture, or
access a contact.
- define by list of mimetypes
2. How to integrate this with apparmor
- hard link file into directory where there is access (with cleanup)
- new functionality in apparmor to dynamically update the profile
- object delegation
- transfer file over dbus
- helper itself could provide a socket and the helper could shove data into
the other end
Work items:
[mterry] file selector
[mpt] design for photos selector
[mpt] design for contacts selector
[security] dbus
[security] decide on how to expand the permissions
[security+mterry] design of how to make security desicions
Application Confinement (Gnome-Keyring)
---------------------------------------
= Background =
gnome keyring can store passwords and when offline the storage is encrypted.
when online it is decrypted
previous versions had ACLs to control access to the keyring. patched out
because security consider when everything is running under the user session and
several issues. (spoofing, tricking, X spoffing, opening keyring file
itself,etc, etc).
Default assumption "when in the default user session with trusted components,
we don't need the ACLs"
Going forward, this assumption changes because of the extras repository. Those
applications will run under a sandbox. Some applications in default install of
Ubuntu also run in a sandbox.
How can we protect the security of the contents of gnome keyring now that the
assumptions about everything running under the user's session is not trusted
How to move forward:
- a daemon could be in place that runs as a different uid - if the application
is already confined
- we could
No point if we applicatoin has:
- read and write to user's home - a confined application
- arbitrary access to dbus
Assumption: an unconfined applicatoin is trusted and can do anything. A
confined application has limited access to HOME directory, and no access to DBus
Two options:
1. bring back ACLs and have gnome-keyring make decisions by having it ask
apparmor to see who it is talking to. Then gnome-keyring can prompt that this
application can access the keyring
2. Could have an agent that denies access to everything and then apps are
forced to work through it being using different backends for gtk, gsessions,
etc. gvfs, file chooser, dconf, keyring, show notifications, wm applicaton
integration. New applications could be forced to use this.
* have different backends that forces the confined application to only
communicate via a socket
* on the other end of the socket is another application (the agent) that is a
helper. It is in a position to make access decisions
* how does the agent make these decisions (opening a single file could be via
file open dialog helper)
* could virtualize paths for legacy applications
* the program uses the platform in the normal way. So a program tries to get a
password from libsecret like normal. The backend forces communication over the
socket. The agent on the other end of the socket has the policy and can make
decisions.
* where does the policy live for this? is it in the agent, is it somewhere
else?
Need to also support legacy apps and apps that may be statically compiled
Why does it have to be so complicated? gnome-keyring could ask for the security
context of the application asking for the access, then the ACLs could be in
place to make decisions based on that. The application is confined anyway and
isn't allowed to talk to everything
Juju charm security
----------------------
https://blueprints.launchpad.net/ubuntu/+spec/security-r-juju-charms
example: http://jujucharms.com/security-notices/jcsn/jcsn-001
juju/security tag: https://bugs.launchpad.net/juju/+bugs?field.tag=security
Charm security and update process
* Juju features to watch:
- Adding arbitrary actions (for applying security updates) - this is for
updating deployed software (not the charm itself)
- "security" tagged bugs in juju and juju-core launchpad project
* Ideas for improvement:
- Review points for preventing security bugs
- Static analysis for preventing security bugs (charm proof)
* charm proof captures known problems
* it could have a pedantic mode that warns for red flags
- Better tools and docs for applying apparmor
* currently people aren't doing this
* juju team is pushing for more knowledge
Charms with AppArmor
* what is the current status?
* what could be done better?
* would it help if the security team could produce a representative charm or
two for charming with apparmor?
* unattended-upgrades charm?
* Juju bootstrap should generate ssh host keys locally, push them to the
instances, load them automatically into a local known_hosts.juju file, and
prune them on destroying the environment
- juju team has a plan (needs to be in core), but needs time to do it
- a branch is available
* Juju should inject a random seed via metadata for each instance launched
Work items:
[jdstrand] unattended upgrades charm
[clint-fewbar] formally document juju/charms security process (maybe look at
SecurityTeam/UpdateProcedures
[jdstrand] review process and review the security notices page
[charmers] some sort of command for 'are there upgrades available for this
charm' (over the charms in an environment)
[jdstrand] discuss charm proof additons
[jdstrand] get information to the juju team on how to use AppArmor
[jdstrand] demo charm for moin
[security] demo charm for backend/infrastracture one (rabbitmq maybe)
[security] maybe demo charm for samba?
[security] look at apache non-prefork
[] recover ssh key handling from bitrot, attach it to a bug
lp:~jimbaker/juju/ssh-known_hosts; https://bugs.launchpad.net/juju/+bug/802117;
https://lists.ubuntu.com/archives/juju/2011-November/001034.html
[security] comment on bug for ssh key handling
[] push high entropy seed from client as part of cloud-init medata
Application Confinement (Online Accounts)
-----------------------------------------
Online Accounts runs within the user's session which is fine for trusted
applications, but not for untrusted applications that are running confined.
How can we improve online accounts so that applications can only access what it
needs or nothing at all.
Online accounts consists of 2 parts:
1. accounts db (an sqlite db). Not meant to store secrets-- stores things like
the URL of the server to connect to. Does not use a DBus service
2. authentication service (can store password and access tokens to various
services. This is a DBus service. This is currently in gnome-keyring)
- this can set the owner of the identity
- which auth methods can be used by the application
- applications use client library to access the authentication service
Has security plugin interface
* one for meego (old)
* tizen (new, uses SMACK)
* prompting user for granting access to an application is not implemented at
this time (Meego used a different method)
* going forward, we can write a security plugin that uses the apparmor "tag"
for this.
* plugin could consult a whitelist and somehow preseed so the user isn't
prompted for something we trust.
* for things we don't preemptively trust, prompt the user. This should
consider spoofing. Could create a library so other applications could take
advantage of this. (we can have a modal application dialog now (per tedg) since
we know the secure id and we can trace that all the way back to the window --
this would draw over the application)
* if we do this, can we make sure that the security tag is always available?
yes, with the unconfined tag (maybe we could differentiate if the tag contained
the security label plus binary or something)
The accounts db does not have these projections. In Meego they would create a
hash of the info it needs, then if it was modified the application would know.
How to handle intepreted scripts? if launch by script name, then apparmor will
have the appropriate tag. If launched with 'python' then unconfined, but not a
concern for confined apps.
Actions:
[] write a security plugin for online accounts
[] investigate how to protect the accounts db (ie, the settings. maybe dbus
api, maybe only allows read-only access to the accounts db via apparmor, maybe
use the hash. first iteration, ro?)
[] write generic authentication helper/library for prompting the user to allow
access to some resource
[jdstrand] ensure that desktop files don't specify the interpreter
(AppDevUploadProcess)
Support autogenerating apparmor profiles from declarative templates
-------------------------------------------------------------------
NB! all names of the tools are subject to change / be finalised
NB! policy groups to be defined
To support the appdev initiative, a new declarative format is wanted,
representing the subset of capabilities that third-party apps are allowed to
opt into. These declarative files should be converted to apparmor profiles at
package build time. Specify a new tool that implements this in idiomatic
debhelper fashion.
Existing tool to generate profiles from basic policy is aa-easyprof.
* provide a UI to select predefined set of capabilities
* ... which generates "settings file"
* and use aa-easyprof or something else to generate the actual apparmor profile
* Secure WIN! =)
application-confinement & dh_containment
- dh_containment to be a per binary "settings"/tags, e.g.
debian/binary.confinement
- if prefix is, e.g. "apparmor" pipe that through aa-easyprof
- if prefix is something else you have other helpers to extend confinement
policy
At the end you get the apparmor profiles for each individual executable.
cat debian/binary.confinement:
mybinary: access-private-photos,
networking-internet,
networking-local
logger: access-system-logs
game-*-bla: private-dirs
<TARGET>: policies
internal details:
apparmor: template=com.ubuntu.extras.template
apparmor: policy-groups=user-dirs, system-dirs
apparmor: /opt/foo/bin/FooApp
<TARGET>: <OPTION> <VARIABLES>
proposition:
/path/to/binary: access-private-photos
/path/to/binary: networking unixsocket ipv4 ipv6
/path/to/binary: networking-all
/path/to/binary: my-other-abstraction parameter1 parameter2
"/path/to/binary" should be relative to the installation target
Actions:
[jdstrand] Get aa-easyprof to read pipe with easyprof syntax as an alternative
to command line parameters
[jdstrand] discuss with stakeholders all possible confinement keywords
[xnox] define the config syntax with jdstrand for the dh_appconfinement (use
debhelper perl lib)
[xnox] Implement new dh_appconfinement debhelper hook, containing the list of
confinement policies supported and what tool to call to handle them
???
man dh_appconfinement [--template]
dh_appconfinement is sensitive to environment variable
DH_APPCONFINEMENT_TEMPLATE=com.ubuntu.extras
cat debian/rules:
%:
dh $@
Application Confinement (GSettings)
-----------------------------------
Discuss how to improve gsettings security for applications running within the
same user context. For example, if application 'foo' is installed from extras,
how can we:
* allow it to have write access to only its settings?
* prevent it from having read access for 'bar'?
What other scenarios should be handled? Should this be integrated with AppArmor
and if so, what would it look like?
Current architecture
- various backends (dconf for linux)
- reads are off disk for speed
- writes are via dbus for integrity
What we would like to mediate:
- should be able to read/write its own settings
- maybe or may not be able to read other application's settings
- may need access to system settings (eg, proxy, themes, etc)
Problems for mediation with dconf backend:
- dconf might read from unexpected places
- database is all or nothing affair
Ideas:
1. different backend for dbus for system settings but a file backend for its
own stuff
- maybe have a list of keys that the backend knows to ask for over dbus for
access outside
- pro: can clean up easily
- con: can't use standard tools like dconf-editor, etc
- con: sysadmin wouldn't easily be able to setup defaults
2. use dconf backend but do reads over dbus for mediation. The dconf daemon
could have a security hook to add a call for the security checks. The checks
could be to maintain a whitelist or query apparmor.
- pro: can mediate with apparmor or any other security plugin
- con: slower than mmapped file, but likely acceptable for single applications
- what about caching? Might be worth it if reads are over dbus (could even
prefetch all the keys)
3. agent could use apparmor directly. it acts like a regular dconf client. it
knows about apparmor
- app uses same api
- set env variable to use this backend
Security module:
- read or 'give me a list of keys'
- write (maybe specify a list of paths)
Option 3 is the one we've selected
--
AppArmor mailing list
AppArmor@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/apparmor
