[apparmor] AppArmor utils on openSUSE
john.johansen at canonical.com
Mon Dec 20 18:03:28 GMT 2010
On 12/19/2010 04:10 PM, Christian Boltz wrote:
> Am Sonntag, 19. Dezember 2010 schrieb John Johansen:
>> On 12/19/2010 07:23 AM, Christian Boltz wrote:
>>> The question is how this could be solved.
>>> Do you have updated logprof/genprof for AppArmor 2.3 that
>>> understand *x permission log entries?
>>> Or can I simply switch to the 2.5 utils without breaking something?
>> The solution is getting opensuse updated to the new tools, there have
>> been some packaging issues, but jeffm has fixed some of those and
>> steve has also done some work at improving the packaging.
> Yes, I know, and I also know that this is an ongoing effort. Jeff wrote
> today in the bugreport that he is working on some "interesting"
> packaging issues and that he expects to have 2.5.x in openSUSE 11.4
> However, this bug is open for a long time and I'm getting impatient -
> for me it is a blocker for upgrading several servers, and 11.1 (which is
> the last with working utils) is going out of support in some days...
Your frustration is understandable, it has been a long time.
>> You should be able to use the apparmor 2.5 tools, as they are
>> backwards compatible with 2.3,
> Sounds promising :-) - I'll test that.
> Unfortunately the build for 11.3 in security:apparmor:factory fails
> while trying to install a manpage, and the packages for factory don't
> match the perl version in 11.3 (which means I would at least have to
> move the perl modules around - not a big job, but nothing I want to do
> after midnight ;-)
> (If I just overlooked a working package for 11.3 somewhere, I'd welcome
> a pointer.)
sorry, I don't have an answer to this atm
>> and you will see some nice improvements. Policy compilation is faster
> Sounds like a really good thing. I have a (11.1) server with a big
> apache profile (with about 150 hats/vHosts, profile filesize 70k + 150
> abstractions [one per hat, auto-generated with a script] with 1k each +
> another (shared) 2k abstraction + 10k abstractions included by this
> abstraction - that all is included in all vHosts/hats).
> That makes
> 70k Apache profile
> + 150 * 1k = 150k abstractions/vhost_*
> + 150 * (2k+10k) = 1800k abstractions included in every vHost/hat
> = 2040k
> 2040k = 2 MB total profile size if I follow all abstractions/*. Wow.
yeah, thought text policy size doesn't actually determine what the
finally compiled binary policy size is.
> Currently rcapparmor reload takes 36s on this server (not really
> surprising) - that will make it a good performance testbed for the new
> utils ;-)
well you should see some improvement, though the improvements to speed
up policy with lots of small hats haven't hit yet.
Basically for 2.5 true dfa minimization was add, this will have the most
impact on large profiles, reducing their size and hence resulting in
faster compression. The compression phase was also sped up about 2x
For large profiles this results in a 4-6x improvement.
We still have a lot of improvements to come, some of them will hit in
2.6 and others ...
The ones that will help your policy the most are yet to come
>> and if you take the steps to setup a policy cache, policy
>> loading is very fast,
> The problem is that most times when I call "rcapparmor reload",
> the reason is a change in the apache profile or one of the hats.
> I guess caching doesn't make too much sense then?
Right, caching is done at the profile level, it will help though
if you have any other profiles on your system. It also helps
speed up booting.
More information about the AppArmor