unified packages and post install

[roddhjav]

This issue is the follow-up of #464, the final solution is going to be quite different to the original proposal. Fell free to comment the current proposal

The problems

• They are too many profiles, most are only useful in specific setup
• At this scale, the compilation of apparmor profiles is slow and heavily RAM hungry.
• Files in /etc/apparmor.d get replaced by package updates, thus any user modification is lost.
• For admin/user, it is hard to select the profiles they want to install

Solution proposed in #464

The original solution was to split the profiles in various editions: all packages would conflict with each other.

• Default: apparmor.d, apparmor.d.enforced
• Server: apparmor.d.server, apparmor.d.server.enforced
• FSP: apparmor.d.server.fsp, apparmor.d.server.fsp.enforced

However, it is not enough, we may as well provides packages for each supported DE, furthermore we also have some very specific development edition: test (for autopkgtest) and debug (to generate a tree of visited profiles in FSP mode). Then, we also add some core packages such as apparmor.d.base (abstraction, tunables) and apparmor.d.tools (for aa-log such as actual profiles packages are not architecture dependent)

As this is getting out of hand, we need a better solution.

Unified package solution

There is going to be only three packages:

• apparmor.d-tools: for apparmor.d tools such as aa-log, aa-config and aa-install
• apparmor.d-base: for abstractions, and tunables. Installed in /etc/apparmor.d/
• apparmor.d: for all prebuilt profiles, installed in /usr/lib/apparmor.d/

Upon installation of apparmor.d, and after each install of a new program, a trigger/hook ( aa-install) will:

• Install the profiles only for programs that are present on the system
• Apply any configuration needed (such as complain/enforce mode, FSP mode...). This configuration is provided by:
  • A general parameter in /etc/apparmor/install.yml to select the main mode: enforce/complain
  • Per profile configuration can also be provided in /etc/apparmor/install.d/ as yaml files.
  • Other flags can also be provided (such as attached_disconnected, mediate_delete)
• Some profiles can be explicitly installed or ignored by providing a list of profiles to install in /etc/apparmor/install.yml
• Default configuration is also shipped by the package under /usr/lib/apparmor/install.d/

Configuration is for now limited to what profiles in which mode, another tools (aa-config), will later be added to adjust other parameters (such as security model targeted, common paths, boolean...). See #969

[chovanecadam]

I believe it would be useful to have a configuration option to disable all auto discovered profiles and only install profiles listed in install.yml. It would provide user more control and would help with development of profiles.

[roddhjav]

Yes, and no:

• Yes, it is possible
• No: handling of nested dependencies across profiles is a massive pain. Not handling this part correctly would break everything. This is why manual local installation is still a thing.

For dev, the solution that works the best to me is just dev (https://apparmor.pujol.io/development/workflow/#individual-profile)

[jrjohansen]

Upstream there is movement to address the compile time and memory use issues in multiple ways that should be considered here.

Compiler improvements

• rewrite of the expr tree simplication (target 5.0)
• user space zstd compression of policy (target 5.0)
• compile units (think pre-compiled headers in C/C++)

Delayed and On demand policy load (target 5.0)

• profile annotations for when a profile should be loaded (early, boot, deferred)
• the ability to load a stub profile in place of a deferred profile
• AppArmor daemon - to handle
  • deferred compiles via notification interface
    • old interface
      • compile and load profile to replace stub, async to load on boot
    • new interface
      • deferred profile compile async to load on boot
      • load deferred profiles on demand

Better selective profile enable/disable is also being investigated but will be post 5.0

[roddhjav]

Thanks, this should solve some of the issues. Sadly, I think most of this new structure would still be needed:

• I (and most people) do not want a profile for gnome-shell on a server or on a KDE desktop. In some setup, it can have security consequence: the existence of a profile means a program can run. So less profile, is more confinement.
• There is a need of configuration such as flags and profile to (not) install system side.

[valoq]

Apparmor does not only come with a performance cost but most importantly with maintenance cost for every user/admin and for every profile installed.
When I decide to install a profile, it will be to address the applications specific attack surface. Every profile that is installed without my explicit choice is an obstacle.

With the recent update I just had to reinstall apparmor and apparmor.d today and this is my experience:

• Update appamor to version 4.1.3 -> everything breaks, system unbootable due to Basic Installation of apparmor.d #989
• start system recovery with the complete removal of apparmor
• reinstall apparmor, notice it once again installs a bunch of nearly empty profiles (for userns) that clog my apparmor.d directory
• try to clean up the default profiles, breaks entire system again because dbus wont start for some reason (no profiles are installed)
• system recovery again, reinstall apparmor, leave default profiles in place (basically giving up)
• install apparmor.d, try to install only partial profiles, breaks system again
• reinstall apparmor.d again, find a number of new bugs aa-enforce - Syntax error: include rule filename cannot contain spaces #991 Conflicting profiles for certain programs defined in two files / aa-logprof errors #852

If I wasn't invested in this project, I would just give up on apparmor at this point.

One option I have some hope for is to make it an explicit user choice to install every single profile without any that come by default, meaning:

• apparmor should be installed with zero profiles
• apparmor.d should install all abstractions and zero profiles
• apparmor.d should ask explictly for any profile to be installed. There must never be a single profile the user did not chose to install.

There can of course be the simple option to just install everything or install profiles for applications that are present, but that cant be the default without annoying users to the point of giving up.

[jrjohansen]

@rodhajav: sure there is definitely a need to improve packaging, and make enablement/disablement/changes better/easier.

The deferred load, really only goes to helping reduce boot compile time, and kernel memory use of policy. It really doesn't do anything to address the other points.

It makes sense to a point to split policy into desktop, server, ... However there are issues around that, its really not a clean separation. People install remove packages, and you policy is out of sync with that etc. Ubuntu side we have done some investigation into dpkg triggers (problematic), but apt has a mechanism that can be made to work (unfortunately apt only).

Disabling/removing profiles works okay for leaf profiles, it becomes problematic when there are interdepencies. Basically there is no one perfect solution to this. The more tools we have to deal with different cases, the better.

[jrjohansen]

@valoq:

Apparmor does not only come with a performance cost but most importantly with maintenance cost for every user/admin and for every profile installed.

Yes, there are trade-offs on different types of maintenance costs all over the place.
Costs/trade-offs for having extra profiles installed
Costs/trade-offs for not having profiles by default
Costs/trade-offs for having profiles bundled with the application
Costs/trade-offs for shipping policy separate from the application.

What is optimal will differ by distro, and by user/admin. That isn't to say that there isn't maintenance costs to having a lot of unused profiles installed; there absolutely is a cost. There is also a maintenance cost of user/admin has to search for install a profile separate from installing the application. There is a cost in installing unmaintained or useless profiles that are installed by an applications package maintainer ...

One admins needs/wants are different from another, etc. Same goes for different users, and distros.

When I decide to install a profile, it will be to address the applications specific attack surface. Every profile that is installed without my explicit choice is an obstacle.

this works for you as an admin/user but I don't think it works for a lot of admins/users. It is definitely a valid way to use it, but not the only way.

Update appamor to version 4.1.3 -> everything breaks, system unbootable due to #989

ouch! I am sorry to hear that. This is obviously something that needs to be fixed, and I am sorry it happened. The solution here is a work in progress, where the upstream apparmor project and apparmor.d are working towards better integration. AppArmor.d (or at least parts of it) will become part of the upstream. Achieving this is tacking time, and both projects are going to be doing releases, before the end goal is achieved.

reinstall apparmor, notice it once again installs a bunch of nearly empty profiles (for userns) that clog my apparmor.d directory

yeah, I hate those too. We are working on getting rid of them. Its an interim state/solution to allow rolling out the unconfined user namespace restriction.

try to clean up the default profiles, breaks entire system again because dbus wont start for some reason (no profiles are installed)

yes, profiles with interdependencies make just removing some profiles a really bad idea. Instead putting those profiles into unconfined mode is a much safer option.

One option I have some hope for is to make it an explicit user choice to install every single profile without any that come by default, meaning:

apparmor should be installed with zero profiles

this should indeed be an option. We have been discussing how best to split policy from the base apparmor, and how to handle the packaging dependencies around it.

in the end it will be up to the distro that does the packaging, but the goal for upstream reference packaging would be a minimal base package. Possibly a base abstractions package (it could potentially be part of the tooling), a base system policy package with core profiles that have interdependencies that reall need to move together, and then packaging for things like server, desktop, all.

The other bits that are needed are:

• a policy overlay, which will allow users to make local changes/replacements without causing packaging problems.
  • Note:
  • that the overlay could potentially be used to hide/disable all system policy, so only what the user copies over is enabled.
  • the overlay could be used as a means to allow apparmor.d to hide/mask base apparmor poliyc without breaking things.
• better control over profiles being enabled/disabled
• better toolling to help with interprofile dependencies
• and yes lots of tooling bug fixes

apparmor.d should install all abstractions and zero profiles
that is a possibility that has been discussed some. But not just apparmor.d, same option for upstream apparmor

apparmor.d should ask explictly for any profile to be installed. There must never be a single profile the user did not chose to install.

that might be an option for one of the profile packages, but it really should provide packages that provide large sets of profiles without prompting as well.

[valoq]

Costs/trade-offs for not having profiles by default

I dont see it, what cost comes with not having a profile by default?

The main objective should be to not get in the way of the user or even cause stability issues. Not having a profile installed by default does that. Having any profile installed increases the risks of breaking things.

One admins needs/wants are different from another, etc. Same goes for different users, and distros.

But every installed profile increases the risk of breaking things, even if a system with profiles for all applications is the intent.

One central questions I keep wondering about is why apparmor manages its own abstractions and why apparmor.d uses them. This seems a most common source of problems liek the recent changes of variables moving from one to the other package. The obvious solution would be for apparmor.d to copy the bastractions from apparmor under a different name and reference them instead. That should avoid any issues between the packages at least, right?

[jrjohansen]

Costs/trade-offs for not having profiles by default

I dont see it, what cost comes with not having a profile by default?

There are several trade-offs, but what they are depends on the security threat model you are dealing with.

At the distro level, we get both users upset that apparmor blocks something by default, and users upset that it doesn't, and their system is not a secure as it could be.

If you are running a trusted/untrusted application model. Profiles become part of the trust chain, and not having the profile actually can end up breaking things. Eg. in ubuntu those unconfined profiles that do nothing actually prevent applications from breaking when the untrusted user namespace restriction is enabled.

Also dealing with information flow/permissions between applications can mean not installing one profile can break another. It will of course depend on the type of restrictions (security model) you are trying to enforce, but profiles on system services, dbus, etc become very important in establishing tighter policy.

The main objective should be to not get in the way of the user or even cause stability issues. Not having a profile installed by default does that. Having any profile installed increases the risks of breaking things.

it depends on what you are trying to enforce/protect. I can tell you that not having profiles installed can very much break things on systems with tighter confinement.

I am not trying to down play your concerns, and frustrations with breaking things. Its a very real problem, and leads to disabling security altogether to get things done. Its something we are actively trying to improve, but it takes time, and resources, and is very dependent on the type of system, and user.

One admins needs/wants are different from another, etc. Same goes for different users, and distros.

But every installed profile increases the risk of breaking things, even if a system with profiles for all applications is the intent.

yes, but so does not having a profile. In fact in the tighter confinements not having a profile is treated as untrusted and is the mostly likely way to break the application.

One central questions I keep wondering about is why apparmor manages its own abstractions and why apparmor.d uses them

AppArmor existed before AppArmor.d and has always offered policy, and a base set of abstractions. AppArmor.d built on top of this. Policy wise the two projects have evolved together but also separately. The current plan is to split AppArmor policy for the core tools work towards merging much of AppArmor.d, and the base AppArmor policy.

There is a lot of work todo before the planned merge will be completed. You are currently seeing baby steps towards that end goal.

This doesn't mean AppArmor.d will go away, more like it will be split into the new base AppArmor reference policy with @roddhjav as one of the maintainers, and an add on project where @roddhjav is still doing things that aren't ready for base AppArmor policy, or maybe are experimental, etc. It is possible that in time the split will completely disappear but it is also possible that it will never go away. Either way there will be a less deviation in the future.

his seems a most common source of problems liek the recent changes of variables moving from one to the other package. The obvious solution would be for apparmor.d to copy the bastractions from apparmor under a different name and reference them instead. That should avoid any issues between the packages at least, right?

that would be one solution, it would be a trade-off in different types of maintenance. I am not sure it would be better.

There are improvements that will help with several of these types of issues, but there is also more work to be done, and the best way to handle some things still needs to be figured out.

[valoq]

But every installed profile increases the risk of breaking things, even if a system with profiles for all applications is the intent.

yes, but so does not having a profile. In fact in the tighter confinements not having a profile is treated as untrusted and is the mostly likely way to break the application.

I see what you mean here, but this is only the case if you aready have some confinement in place that depends on the additional profiles.

When users/admins install additional security layers, the perhaps most important aspect is the visibility of what is installed and enforced. From my perspective apparmor seems very intransparent with the default installation of some profiles, as my recent issues with their removal showed as well. To give users control over how their system is secured, they need to be actively involved in every restriction step. Having some default confinement doesnt help when users are not aware. I am still searching for how my system broke yesterday just because I removed the default pprofiles. After all there should be no confinement if no profile exists in /etc/apparmor.d/ or so I at least assumed. The fact that some services (like dbus) are confined without a profile present is rather unsetteling and gives me an even greater impression of intransparencey. I probabaly just misinterpreted the way apparmor works but so will others most likely. Which is why I am convinced there should be absolutely no confinement by default. Have the service print a warning if no additional packages are installed to add profiles, that may address other concerns. But again I dont think there are many users that assume complete protection profiles after installing apparmor, it wouldnt even be the case with apparmor.d
Users that complain about apparmor breaking things seem the most common complains though.

this seems a most common source of problems like the recent changes of variables moving from one to the other package. The obvious solution would be for apparmor.d to copy the abstractions from apparmor under a different name and reference them instead. That should avoid any issues between the packages at least, right?

that would be one solution, it would be a trade-off in different types of maintenance. I am not sure it would be better.

I dont really see much of an alternative. As long as both packages exists in parallel with variables depending on each other, they will break at every change.

My suggestion going forward would be to split apparmor like this:

• apparmor (base package): provides the apparmor service deamon and tools. Zero profiles, zero abstractions

• apparmor-profiles: provides what the current apparmor package includes with the base abstractions and profiles. This is optional and not required by apparmor.d

• apparmor.d: provides the apparmor.d ressources with all abstractions completely independant from other apparmor packages. Zero profiles installed by default

Now the user can run somthing like "aa-install" which allows the user to chose profiles to be installed, maybe as some tui tool and optionally using a commandline argument for a list. By default this tool could list all packages that are installed to provide a more sensible choice and reduce work. Any profile that includes dependencies will automatically mark those dependencies as install targets as well. Before confirming, the user is presented with a list of all profiles to be installed, thereby making it an active conscious choice.

My take may be a bit naiive and I still dont have nearly the in depth knowledge compared to you two maintining these pacakges, but I am convinced that these user facing issues need to be addressed first if there is supposed to be any user acceptance for apparmor as a security tool. Regardless of wheather I want a few or many profiles, I should at least get the feeling of control so that when things break, I know they break because I installed it and not because some hidden dependency that was installed by default without my awareness.

[roddhjav]

First and foremost, yes, breakage caused by upstreaming things to apparmor/apparmor-profiles is a big issue. It is even more a concern as moving forward more and more resources may be upstreamed. Even more considering that apparmor.d may become the experimental / advanced / security model specific edition of apparmor profiles.

There is actually already some safeguards in place. For example, the PKGBUILD currently explicitly requires apparmor>=4.1.3 and apparmor<5.0.0. However, it is obviously not narrow enough. The problem is: if we narrow it more (e.g apparmor==4.1.3) the apparmor and apparmor.d packages would have to be updated at the very same time, which is not possible while apparmor.d is in the AUR. However, I think it is the best (and only) sustainable way to handle this issue. Maybe it would be nice to have feedback from a Arch/Debian/Ubuntu/OpenSUSE packager about this.

@jrjohansen

It makes sense to a point to split policy into desktop, server, ... However there are issues around that, its really not a clean separation. People install remove packages, and you policy is out of sync with that etc. Ubuntu side we have done some investigation into dpkg triggers (problematic), but apt has a mechanism that can be made to work (unfortunately apt only).

Can you explain the issues with dpkg triggers? I have done tests with them and pacman hooks, and they seem to work fine.

@valoq

When I decide to install a profile, it will be to address the applications specific attack surface. Every profile that is installed without my explicit choice is an obstacle.

Even if I very, very strongly disagree with this statement (more on that later), this new package structure should be able to allow this. It will obviously be at your own risk

I want to be clear on this: some of the issues you had with the recent update were worst because of your very setup. The new package structure may help you, however, it will always be at your own risk.

apparmor.d should ask explictly for any profile to be installed. There must never be a single profile the user did not chose to install.

Absolutely no. It is against the very core goal of this project.

The first purpose is to provide a default confinement for everyone including people that do not know what apparmor is, or do not care about it. Even if it means implementing a less restricted security model. This is a fundamental security principle: secure by default.

Is this default confinement stable enough yet? No, obviously not (but I can tell you they have been HUGE progress).

The second purpose of this project is to provide sane ground for more advanced security models (including extreme one), various, and specific uses cases as well as some tooling and to documentation to manage them. It is where your personal use case can fit in.

See #873 (comment) as a side conversation.

I dont see it, what cost comes with not having a profile by default?

An example of what @jrjohansen mentioned is mkosi.

One central questions I keep wondering about is why apparmor manages its own abstractions and why apparmor.d uses them. This seems a most common source of problems liek the recent changes of variables moving from one to the other package. The obvious solution would be for apparmor.d to copy the bastractions from apparmor under a different name and reference them instead. That should avoid any issues between the packages at least, right?

First, and I think it is a major point when someone is contributing to existing software: I tried to provide as little changes as necessary to the existing apparmor profiles (and general structure). Furthermore, apparmor-profiles is already widelly used, packaged and trusted by anyone using apparmor. Setting up apparmor.d in conflict with apparmor-profiles would be a total no go for most users (and companies).

Secondly, duplicating the abstractions would be a nightmare to maintain. Lastly, as there is a will to merge these abstractions, well, it is way easier to do this when apparmor.d is ship as a drop in addition to apparmor-profiles.

his seems a most common source of problems liek the recent changes of variables moving from one to the other package. The obvious solution would be for apparmor.d to copy the bastractions from apparmor under a different name and reference them instead. That should avoid any issues between the packages at least, right?

Only from a maintenance point of view it is a total no-go. Strong version link between apparmor / apparmord.d is a much simpler solution. For example regarding the recent breakage, the fix was:

1. Obvious,
2. Ready since the breaking changes made it to the master branch of apparmor,
3. Only applicable to a specific version of apparmor.

The fact that some services (like dbus) are confined without a profile present is rather unsetteling and gives me an even greater impression of intransparencey.

I know that no one read documentation, but you cannot say it is not transparent: https://apparmor.pujol.io/development/dbus/#profiles

More globally, I think the way you use this project is causing some of your issues. aa-install could be part of the solution.

To sum up, apparmor profiles are not single configuration files that can be easily cherry-picked.

These are security policies implementing (part of) various security models for a whole system. They have (a lot of) interdependencies between them. Some of these dependencies are due to implementation decision. And these are everywhere: on top of the abstractions and tunables, the dbus implementation differentiate between system, session and accessibility profiles, and it has consequences on all dbus rules. Furthermore, most communications between processes (dbus, signal, unix) use peer label, which means that the programs of the communicating process must be confined.

To sum up, selecting only a few sets of profiles to deploy on a system is like selecting only a few source files to compile a program expecting it will work without issue. It may work, but it is very likely to break things even more if you do not have a deep understanding of the project structure. In the case of profiles, it can only work for leaf profiles that do not have any dependency (with a lot of bases profiles installed)

A possible solution to this could be to ensure that all core internal (the dependencies) profiles are shipped in the apparmor.d-base package (i.e. with the abstractions). While using this base, you would be free to configure aa-install to your needs.

[valoq]

apparmor.d should ask explictly for any profile to be installed. There must never be a single profile the user did not chose to install.

Absolutely no. It is against the very core goal of this project.

The first purpose is to provide a default confinement for everyone including people that do not know what apparmor is, or do not care about it. Even if it means implementing a less restricted security model. This is a fundamental security principle: secure by default.

I see what you intend to do here, but I dont see how this has any chance of coming even close to a realistic solution.

Any change by any application can create an issue. If we consider the dependencies of profiles that becomse even more severe.

The chance of breaking a system with apparmor could be estimated by the number of profiles installed, or with dependencies considered, the number of profiles times their dependencies. How would that ever become stable?
I can see this happening for a stable distribution like Debian or Ubuntu, but rolling releases are doomed from the start.

Most importantly though, while I can understand your reasoning of providing full system confinement, I dont see it following any valid threat model. Confining agetty or some other internal service may provide some defense in depth in some scenario, but it does not address any realistic attack surface that I can see. A profile for tar or zip on the other hand addresses a real threat that is exploited regularely and could be confined with apparmor.

Attempting to target the entire system when it involves so much maintenance effort and risk of instability for no valid threat model seems unreasonable to me.

The IPC communication of many desktop profiles is a valid point to some degree, but there is also no need for complete isolation to provide a effective security boundary. Lets say you have an image viewer that needs to talk to a wayland compositor: If the later is unconfined, it still does not allow the image viewer to escape its own confinement (unless you exploit a vulnerability in the compositor) Assuming you dont expose its IPC socket

If on the other hand your confined application talks to a confined X11 server, it wont matter anyway given the trivial escape to any other X11 window.

The fact that some services (like dbus) are confined without a profile present is rather unsetteling and gives me an even greater impression of intransparencey.

I know that no one read documentation, but you cannot say it is not transparent: https://apparmor.pujol.io/development/dbus/#profiles

The issue with dbus was triggered when I removed the default apparmor profiles and before I reinstalled apparmor.d

More importantly, I understand apparmor to use only profiles that are located in /etc/apparmor.d and I dont see where the documentation contradicts this.

More globally, I think the way you use this project is causing some of your issues.

While I dont disagree, I doubt it would help much if I ran all default profiles as enforced. Based on my aa-log it would break most distributions instantly.

To sum up, apparmor profiles are not single configuration files that can be easily cherry-picked.

Id argue they should be. Dependencies can be solved at install time. Then again I am unsure if either of our views on what apparmor should do is realistic anymore. No matter how I look at it, it will decrease the system stability

A possible solution to this could be to ensure that all core internal (the dependencies) profiles are shipped in the apparmor.d-base package (i.e. with the abstractions). While using this base, you would be free to configure aa-install to your needs.

I dont think what we each have in mind is that much different.

[jrjohansen]

First and foremost, yes, breakage caused by upstreaming things to apparmor/apparmor-profiles is a big issue. It is even more a concern as moving forward more and more resources may be upstreamed. Even more considering that apparmor.d may become the experimental / advanced / security model specific edition of apparmor profiles.

There is actually already some safeguards in place. For example, the PKGBUILD currently explicitly requires apparmor>=4.1.3 and apparmor<5.0.0. However, it is obviously not narrow enough. The problem is: if we narrow it more (e.g apparmor==4.1.3) the apparmor and apparmor.d packages would have to be updated at the very same time, which is not possible while apparmor.d is in the AUR. However, I think it is the best (and only) sustainable way to handle this issue. Maybe it would be nice to have feedback from a Arch/Debian/Ubuntu/OpenSUSE packager about this.

@jrjohansen

It makes sense to a point to split policy into desktop, server, ... However there are issues around that, its really not a clean separation. People install remove packages, and you policy is out of sync with that etc. Ubuntu side we have done some investigation into dpkg triggers (problematic), but apt has a mechanism that can be made to work (unfortunately apt only).

Can you explain the issues with dpkg triggers? I have done tests with them and pacman hooks, and they seem to work fine.

sure triggers work well for some things, not for the use case we were looking at. Specifically we were looking at using triggers in the apparmor/apparmor.d profiles packages to enable/disable profiles when an application package that has not been updated for apparmor (so the triggers for said file would have to be done via the profile package) is installed. Doing this could be used to reduce policy compile time, and also how much kernel memory policy is using.