Merge lp:~kgunn72/mir/snappy-packaging-with-secprofile into lp:~mir-team/mir/snappy-packaging
| Status: | Work in progress |
|---|---|
| Proposed branch: | lp:~kgunn72/mir/snappy-packaging-with-secprofile |
| Merge into: | lp:~mir-team/mir/snappy-packaging |
| Diff against target: |
999 lines (+932/-2) 8 files modified
Makefile (+1/-1) overlay/meta/framework-policy/apparmor/policygroups/client (+6/-0) overlay/meta/framework-policy/seccomp/policygroups/client (+1/-0) overlay/meta/mir.apparmor (+74/-0) overlay/meta/mir.seccomp (+403/-0) overlay/meta/mirdemosvr.apparmor (+45/-0) overlay/meta/mirdemosvr.seccomp (+393/-0) overlay/meta/package.yaml (+9/-1) |
| To merge this branch: | bzr merge lp:~kgunn72/mir/snappy-packaging-with-secprofile |
| Related bugs: |
| Reviewer | Review Type | Date Requested | Status |
|---|---|---|---|
| Jamie Strandboge (community) | 2015-07-28 | Needs Fixing on 2015-07-31 | |
| Mir development team | 2015-07-28 | Pending | |
|
Review via email:
|
|||
Commit Message
first draft additions to confine the mir snap and client
Description of the Change
first draft additions to confine the mir snap and client
used the Qt clock reference app as the means to exercise the mir operation, which my not be exhaustive and other client applications may need to look for AA denials or bad sys calls during debug.
| Chris Halse Rogers (raof) wrote : | # |
Commented about AUTH_ADMIN requirement. I don't think we actually need chown in the regular case, and the option which *does* need it probably shouldn't be allowed system-wide.
| Daniel van Vugt (vanvugt) wrote : | # |
I think this proposal has stagnated because ~mir-team isn't familiar with any of this.
I say just land it. If anyone on ~mir-team does have a clue about what they're modifying in these areas, they can probably just commit directly to the snappy-packaging branch. Doing a merge proposal seems counter-productive at this early stage of Snappy.
| kevin gunn (kgunn72) wrote : | # |
true on the stagnation, as I did the snappy confinement work but I need help with some of the comments as my technical depth isn't deep enough.
But please don't land it, the point of the MP was to capture security team feeback on the snappy confinement.
| Kevin DuBois (kdub) wrote : | # |
I suppose lets move to work-in-progress then?
| kevin gunn (kgunn72) wrote : | # |
OK, based on the current changes in snappy this is now strictly historical.
All security policy is going to be defined by the system for the "display-server" capability which is based on the confinement work done here, this is happening b/c snappy is deprecating the concept of a framework that provides it's own security policy.
Unmerged revisions
- 26. By kevin gunn on 2015-07-28
-
final seccomp change
- 25. By kevin gunn on 2015-07-28
-
seccomp updates for demo of clock app
- 24. By kevin gunn on 2015-07-24
-
seccomp profile changes, mir launches
- 23. By kevin gunn on 2015-07-24
-
final aa profile changes, clock example launches
- 22. By kevin gunn on 2015-07-22
-
apparmor profile updates, mir launching
- 21. By kevin gunn on 2015-07-14
-
update more aa profile
- 20. By kevin gunn on 2015-07-14
-
update from trunk
- 19. By kevin gunn on 2015-07-14
-
update apparmor and seccomp files for mir & better server script
- 18. By kevin gunn on 2015-06-18
-
mir-comp sec prof updates and add mir-demo-server files
- 17. By kevin gunn on 2015-06-16
-
first adds of security profile

Things are really coming along! Most of my comments are inline, however I did want to mention that in looking at the mir_demo_server packaging and security policy, I think you can simplify things and have mir_demo_server simply use the default security policy with the @PACKAGE@_client cap. Ie, update the yaml to be:
binaries: bin/mir_ demo_server
- name: mir_demo_server
exec: debs/usr/
caps:
- network-client
- @PACKAGE@_client
Then do: meta/mirdemosvr .apparmor overlay/ meta/mirdemosvr .seccomp
$ rm -f overlay/
Note: framework binaries and services may reference the framework-policy from this snap.