[pkg-apparmor] Bug#906202: dh-apparmor should check syntax of AppArmor policy
intrigeri
intrigeri at debian.org
Sat Oct 27 13:48:57 BST 2018
Bernhard Schmidt:
> It would be great if dh-apparmor could check the basic syntax
> of the AppArmor policy included in the package and abort the build.
I've thought a bit more about it and I see a few issues with this
proposal:
1. dh-apparmor will need a dependency on apparmor, so that
apparmor_parser is available; incidentally this will guarantee that
commonly used abstractions are available.
2. It will require changes to in at least a few packages so they don't
start to FTBFS: say the AppArmor profile one wants to ship in the
package depends on an abstraction shipped in another package, e.g.
apparmor-profiles-extra (I've just seen one example today:
src:surf). Then a build-dep on that other package must be added,
otherwise the profile won't compile. I don't know how many packages
are affected. I would start with:
https://codesearch.debian.net/search?q=%23include+%3Cabstractions%2F
… and then filter out all abstractions shipped in the
apparmor package.
3. Packages that themselves ship abstractions will require special
handling: dh_apparmor cannot guess what -I parameter it should pass
to apparmor_parser in order to make these abstractions available to
the parser.
All this is doable but requires quite more work (and risks) than
I thought initially.
I'm starting to think that it would be vastly easier to do that via
autopkgtests: once the binary package that ships AppArmor policy is
installed, one can assume that the abstractions it needs are there as
well, which avoids #2. And no need to pass -I, which avoids #3.
Ideally dh_apparmor would "simply" (sic) generate these tests in
debian/tests/, somehow. I don't know if that's possible. But perhaps
it would be good enough to:
- provide the tooling to make it really simple to enable these tests
- add a Lintian check that warns when these tests are not enabled
for a package that ships AppArmor policy
As a bonus, this approach will trigger autopkgtest runs on
ci.debian.net for all packages that have this test enabled, whenever
src:apparmor is updated (because this test will need a dependency on
apparmor), which would be great.
Thoughts?
Too bad our CI runs by default in a container environment where we
cannot load AppArmor policy. Otherwise the test would boil down to
"check that installing the package did load the profile successfully".
Cheers,
--
intrigeri
More information about the pkg-apparmor-team
mailing list