[apparmor] Packaging of Profiles
John Johansen
john.johansen at canonical.com
Tue Aug 10 13:33:57 BST 2010
On 08/10/2010 06:31 AM, Christian Boltz wrote:
> Hello,
>
> Am Freitag, 6. August 2010 schrieb John Johansen:
>> Ideally the profile merge be done by a dedicated tool that
>> understands apparmor profiles and can take into account changes in
>> profile structure, rule reordering, includes, pattern matching and
>> permissions. However lacking that tool a 3 way diff text merge
>> would be better than nothing.
>
> Just an idea: would it be possible to generate an audit.log-like file
> from a profile? With this method, logprof could read the generated log.
> The advantage is that logprof already has the code for merging etc. -
> there would only be a need for two things:
> a) write a profile-to-audit.log converter
> b) find a way for logprof to handle things like variables, wildcards
> etc. (maybe as a commandline flag)
>
Except it doesn't. It cheats really well at it but it has a lot of
missing logic and assumptions that would make this difficult and best.
It really is relying on profile addition behavior and the parser
with a few special case rules for eliminations.
The plan is to make the parser front ends and backends available to
it. The front end does the parsing, the backend does the run merging
dominance relations etc. Once we can get this logic shared it will
make logprof a lot better but at the same time then it makes it
available to other tools.
> The only remaining problem I see is how to give logprof a hint which
> execution method (ux, ix etc.) should be used - this can probably be
> solved with a slightly changed log format. Even if not, profile merging
> would still be much easier than currently.
>
Well its more than just x transitions, logprof would need to be able
to properly handle deny rules (yes it does something now but its
basically just accumulating a list). Change_profile, nested children
profiles, and many other rules that it is currently just cheating
on (it will load and save them but it can't manipulate them).
>
> Maybe it is also possible for logprof to read two profiles (without
> converting them to audit.log format before) and merge them without too
> much coding work?
>
Uh, define not too much work, sadly log prof has some real problems
internally that would make this difficult. Also while supporting
a two way merge would be nice, the ultimate goal is a 3 way diff/merge
so that it is capable of more than just expanding the permissions set.
>
> BTW: Talking about logprof - it seems the current version on openSUSE
> 11.2 and 11.3 can't handle execute events in the log file and create a
> null-xy hat instead. Is there a chance to get this fixed?
>
Hrmmm, yes sort of, Jeff tried and there were some packaging/build issues
that prevented him from updating them for 11.3. Oh and you really want
the newer parser as I have seen what load times are on suse :( It is
several times faster, produces smaller policy and has the ability to
cache binaries. I can't say we will get the initscripts in shape for
suse right away (maybe darix can help) but with a little manual setup
to build the initial caches, loading profiles is nearly instantaneous.
I can't speak for suse pulling in the updates, but once we get 2.5.1 together I plan to take a stab at getting the packaging up on the build
service, which will make it available for 11.2 and and 11.3. And if we can
keep it up to date then it will make it much easier for suse to pull in the
changes in the future.
More information about the AppArmor
mailing list