porting upstream profiles to apparmor.d?

[adrelanos]

@monsieuremre commented on 58b5773 yesterday

[...] Maybe stuff like sdwdate. Most whonix utils have their profiles. I think @roddhjav would be open to having those profiles ported into here, if you are into that kind of thing. If not, it might be necessary to add these profiles as install dependencies for the .deb target produced for whonix/kicksecure.

[adrelanos]

I am considering sdwdate to be upstream. Similar I would consider lets say a Firefox profile as part of firefox-esr Debian package to be maintained by upstream. (Either because Mozilla supports it or because the Debian Maintainer added it.)

What's the plan for apparmor.d? Should the example Firefox profile be removed from firefox-esr and added to apparmor.d instead?

That seems non-intuitive. It's my understanding that:

1. upstream maintaining an AppArmor profile (Mozilla) is the most preferable solution
2. Debian maintainers supporting an AppArmor profile is the next best solution
3. third-party package such as apparmor-profiles, apparmor-profiles-extra and maybe in the future apparmor.d is the least preferable solution.

Unless I am missing something, I think the sdwdate profile should stay with sdwdate. Since it's enabled by default, if changes are required, I am going to notice them and apply the changes. But if it was in apparmor.d then I'd need to send a PR here and upgrade two packages. More overhead.

So my first reaction is to say to not move the sdwdate profile to apparmor.d the same way maintainers of firefox-esr package would probably not move their apparmor profile to apparmor.d.

On the other hand, I'd very much like to see a review, hardening of any apparmor profiles by Kicksecure, Whonix but I don't think this requires moving them to another package.

Also the ownership transfer from one package to another is quite difficult to avoid an APT package manager conflict as two packages might attempt to own the very same file during upgrades.

[monsieuremre]

Unless I am missing something, I think the sdwdate profile should stay with sdwdate.

Yes absolutely. My suggestion was, if there was no profile for this, we would need to add one.

I don't really understand why a missing profile could break Whonix.

A missing profile would break whonix because we intent to use the full policy. I assume for example that sdwdate needs the capability to change the clock, which the full system policy does not grant. If it does not have a dedicated profile, it will default to running under the full-policy, which would prevent it from functioning.

If all the whonix utilities and applications are covered with dedicated apparmor profiles, then there is nothing to be worried about. But if there are some, those might need profiles to not break, unless they already require too little privileges that they can run under the full-policy. Especially in Qubes, I suspect that there might be processes/services that run with no apparmor profiles, that might break when running under the restrictive full-policy. But even those might be covered within the vast number of profiles in this project. But I can't tell without testing, and I unfortunately can't test this. If there are any custom/specific processes that require more capabilities, we would need to create profiles for them, which should not be too hard.

[roddhjav]

I had a similar discussion with some people from canonical last week. At the moment there is no definitive answer to this question.

A (not exhaustive) list of point to consider:

• sdwdate (and all whonix specific profiles) should stay in upstream - as long as you are updating them regularly. This is the case when a maintainer of a project is both security aware and knows the project better than everyone else.
• Most of the time upstream don't write apparmor profile at all, do not want to spend time on this and should probably not be trusted to write them (as in: allowing everything ensure you profile does not break your program). This is why this project exist.
• Asking distribution packager to support profiles (instead of upstream) is a problem: because there is more than Debian/Ubuntu in the Linux world. It is also a waste of resource as apparmor profiles are more program dependent (what software do you use) than distribution dependent (in term of resource access, Gnome on Arch is the same than Gnome on Debian).
• apparmor-profiles is not a third party package but a first party one as it contains all definitions of tunable and abstractions used by every other profiles (it is basically part of apparmor). apparmor.d provides a lot of new tunable and abstraction too (they are currently being upstreamed into apparmor).
• apparmor.d is still in dev (even if it is starting to be quite stable) having everything on the same project is easier (they have been a lot of changes in the past year).
• Remember, it is a full set of profiles, not a separate list of independent profiles. Splitting it would require a considerable amount of work.
• I have defined some guideline & variables used across all profiles to help with the configuration from an admin (to set some directory for all program...). Keeping this structure while splitting the profile would be hard. This is (partially) why selinux have a monolithic reference policy project too.

On the other hand, I'd very much like to see a review, hardening of any apparmor profiles by Kicksecure, Whonix but I don't think this requires moving them to another package.

Sure, I can have a look at them, no need to transfer them.

[adrelanos]

@monsieuremre

Unless I am missing something, I think the sdwdate profile should stay with sdwdate.

Yes absolutely. My suggestion was, if there was no profile for this, we would need to add one.

I don't really understand why a missing profile could break Whonix.

A missing profile would break whonix because we intent to use the full policy. I assume for example that sdwdate needs the capability to change the clock,

Right. Its systemd unit file grants the capability.

It has a dedicated apparmor profile.

If all the whonix utilities and applications are covered with dedicated apparmor profiles, then there is nothing to be worried about.

No way to know without testing and seeing what breaks.

Especially in Qubes, I suspect that there might be processes/services that run with no apparmor profiles, that might break when running under the restrictive full-policy.

That is for sure.

But I can't tell without testing, and I unfortunately can't test this.

Once some major milestone was reached (for example Kicksecure or Whonix) (non-Qubes) bootable with full apparmor profile, I have some ideas for this.

(Run in Qubes in AppArmor permissive mode a share logs would help? Would a CI server help? Maybe can be set up. Maybe Qubes can help. They already run Qubes OpenQA and any logs etc can be made available. Lack of hardware? Can be monetarily donated. But let's discuss this at a later time to not rush ahead.)

[adrelanos]

@roddhjav

• sdwdate (and all whonix specific profiles) should stay in upstream - as long as you are updating them regularly. This is the case when a maintainer of a project is both security aware and knows the project better than everyone else.

Alright. Going for this.

So my original question has been resolved.

Sure, I can have a look at them, no need to transfer them.

Excellent!