interfaces: add apparmor support for hooks. #1373

Merged
merged 4 commits into from Jun 22, 2016

Conversation

Projects
None yet
5 participants
Member

kyrofa commented Jun 21, 2016

More progress on LP: #1586465. Also port AppArmor integration tests to Spread and include tests for hooks. Note that this isn't a complete port (it requires a reboot), so the old integration tests are left alone.

interfaces: add apparmor support for hooks.
Also add Spread tests for app and hook AppArmor profiles.

Updates: #1586465

Signed-off-by: Kyle Fazzari <kyle@canonical.com>
@@ -0,0 +1,2 @@
+name: basic-hooks
+version: 1.0
@zyga

zyga Jun 21, 2016

Contributor

Hmm

Don't you have to declare the hooks here?

@kyrofa

kyrofa Jun 21, 2016

Member

Only if they require plugs. Otherwise they're implicit just by being included in the snap.

interfaces/apparmor/template_vars.go
- fmt.Fprintf(&buf, "@{APP_NAME}=\"%s\"\n", appInfo.Name)
- fmt.Fprintf(&buf, "@{SNAP_NAME}=\"%s\"\n", appInfo.Snap.Name())
- fmt.Fprintf(&buf, "@{SNAP_REVISION}=\"%s\"\n", appInfo.Snap.Revision)
+ fmt.Fprintf(&buf, "@{APP_NAME}=\"%s\"\n", appName)
@niemeyer

niemeyer Jun 21, 2016

Contributor

A bit worried here as we're mixing app name and hook name on the same namespace with the same variable name. How is this variable being used today, and what is the potential for security issues?

@kyrofa

kyrofa Jun 21, 2016

Member

It's not used at all as far as I can see (so I'd prefer to remove it all together). @jdstrand or @zyga might have more information, as @zyga recommended I re-use the APP_NAME variable here.

@niemeyer

niemeyer Jun 21, 2016

Contributor

Reusing sounds quite dangerous, even more if we have no use case to understand why it'd be okay to reuse it without it being a security issue. If we're not using it today, let's please drop it.

@kyrofa

kyrofa Jun 21, 2016

Member

From @jdstrand:

I can say we used APP_NAME extensively on touch and may with personal. I'd prefer not to drop it until we know we don't need it, and I can't say we won't for personal.

So maybe it comes down to whether we want to re-use APP_NAME, or introduce HOOK_NAME?

@niemeyer

niemeyer Jun 21, 2016

Contributor

We agreed to drop this var for the time being.

tests/apparmor-profiles/task.yaml
+ done
+execute: |
+ echo "AppArmor profiles are generated and loaded for apps"
+ sudo snap install ./basic-binaries_1.0_all.snap
@niemeyer

niemeyer Jun 21, 2016

Contributor

Spread runs everything as root by default, so sudo may be dropped.

I'd also suggest dropping all the "./" prefixes.

tests/apparmor-profiles/task.yaml
+prepare: |
+ for snap in basic-binaries basic-hooks
+ do
+ snapbuild ./../fixtures/snaps/$snap .
@niemeyer

niemeyer Jun 21, 2016

Contributor

I forgot to talk to @fgimenez about this. Can we please move these snaps to under tests/lib/snaps, so we have a single place for all test aiding content?

The "./" prefix may also be dropped here and on the rm below.

@kyrofa

kyrofa Jun 21, 2016

Member

Sure thing-- done.

@fgimenez

fgimenez Jun 22, 2016

Contributor

I forgot to talk to @fgimenez about this. Can we please move these snaps to under tests/lib/snaps, so we have a single place for all test aiding content?

@niemeyer ok, the current test snaps are moved in #1381

tests/apparmor-profiles/task.yaml
+ for snap in basic-binaries basic-hooks
+ do
+ sudo snap remove $snap
+ rm ./${snap}_1.0_all.snap
@niemeyer

niemeyer Jun 21, 2016

Contributor

Removing the built file makes sense, but no need to remove the snap. The suite restore-each script is resetting the whole snapd state for every test.

Contributor

niemeyer commented Jun 21, 2016

A few trivials, and one point worth talking about interactively.

kyrofa added some commits Jun 21, 2016

tests: move fixtures/snaps into lib/snaps.
Signed-off-by: Kyle Fazzari <kyle@canonical.com>
interfaces: remove APP_NAME from apparmor profiles.
Signed-off-by: Kyle Fazzari <kyle@canonical.com>
Contributor

niemeyer commented Jun 21, 2016

LGTM

var buf bytes.Buffer
- fmt.Fprintf(&buf, "@{APP_NAME}=\"%s\"\n", appInfo.Name)
@zyga

zyga Jun 21, 2016

Contributor

Hmm?

+ profile := filepath.Join(dirs.SnapAppArmorDir, "snap.foo.hook.test-hook")
+
+ // Verify that profile "snap.foo.hook.test-hook" was created
+ _, err := os.Stat(profile)
@mvo5

mvo5 Jun 22, 2016

Collaborator

You could use osutil.FileExists(profile) here (but stat is fine of course).

@kyrofa

kyrofa Jun 22, 2016

Member

Yeah using os.Stat() here keeps the tests consistent with the rest of the suite.

Collaborator

mvo5 commented Jun 22, 2016

Branch looks good! It seems fine to drop APP_NAME, we should just double check that it is not documented externally somewhere (looks like we don't have it in docs/*).

Member

kyrofa commented Jun 22, 2016

Branch looks good! It seems fine to drop APP_NAME, we should just double check that it is not documented externally somewhere (looks like we don't have it in docs/*).

Thanks for the review @mvo5! Agreed about the documentation: It's not mentioned in snapd anywhere and I'm not seeing anything on google. That combined with the fact that it wasn't being used for anything makes me feel fairly comfortable removing it.

Merge branch 'master' into feature/1586465/hook_apparmor
Signed-off-by: Kyle Fazzari <kyle@canonical.com>
Contributor

zyga commented Jun 22, 2016

LGTM when tests pass

@kyrofa kyrofa merged commit 7112458 into snapcore:master Jun 22, 2016

2 checks passed

Integration tests Success 19 tests run, 0 skipped, 0 failed.
Details
autopkgtest Success
Details

@kyrofa kyrofa deleted the kyrofa:feature/1586465/hook_apparmor branch Jun 22, 2016

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment