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?
Blueprint information
- Status:
- Not started
- Approver:
- Jamie Strandboge
- Priority:
- High
- Drafter:
- Marc Deslauriers
- Direction:
- Approved
- Assignee:
- Marc Deslauriers
- Definition:
- Approved
- Series goal:
- None
- Implementation:
- Deferred
- Milestone target:
- None
- Started by
- Completed by
Whiteboard
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
jdstrand, 2013-11-26> per outcomes of Oct 2013 sprint, Ubuntu SDK apps will use U1DB, therefore this can be postponed until 14.10
Work Items
Work items for ubuntu-14.04:
[desrt] write new dconf agent: POSTPONED
[tyhicks] write apparmor bits for dconf agent (high) (3): BLOCKED
[tyhicks] regression tests for dconf agent plugin (high) (2): BLOCKED
[jjohansen] extend parser/language for dconf rules (high) (3): BLOCKED
[jjohansen] parser regression tests for language extension (high) (1): BLOCKED
[desrt] write a separate gsettings backend: POSTPONED
[tyhicks] create Ubuntu packaging for new dconf agent (high) (1): BLOCKED
[tyhicks] add new gsettings backend patch to Ubuntu package (high) (0.5): BLOCKED