[HOME] [DOWNLOAD] [DOCS] [BLOG] [SUPPORT] [TIPS] [ISSUES] [Priority Support]

Whonix AppArmor Profiles Development Discussion


#481

Merged, thanks.

Somme changes in apparmor-profile-gwenview https://github.com/troubadoour/apparmor-profile-gwenview/commit/f21bb4c3837be047d6e7f299862257faee5bdaca.

Probably an old issue, discovered while viewing icons.


#482

Merged, thanks!


#483

Replaced the Whonix profile for Pidgin, after your topic https://www.whonix.org/forum/index.php/topic,845.0.html.

Changes from the original Ubuntu profile:

  • removed the Ubuntu abstractions. Not for that reason, but one of them was crashing the profile, most likely because of the AppArmor version used in Debian wheezy.
  • added abstractions/kde
  • added a few lines for KDE, not included in the abstraction.
  • added @{PROC}/*/cmdline, most likely for Virtualbox.

I left the Gnome settings, not required in our case, but they might be needed i the future.


#484

Alright. Thanks. Tested. Merged. And added some minor commits on top.


#485

Can you subscribe here please?
https://phabricator.whonix.org/tag/apparmor/

Or if you wish notification for all newly created tasks, see:


#486

Done.

We probably can start with hexchat profile before jessie becomes Debian stable.


#487

For reference:
https://phabricator.whonix.org/T40
I worry more about getting the non-Apparmor work done, since there is so much difficult Whonix dev tasks.


#488

FYI:
Related to https://www.whonix.org/wiki/Download#AppArmor_Warning_during_Boot since Ulrike encouraged me to write a bug report since she is now working on Apparmor in Debian, I made a bug report:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=774888


#489

I thought we agreed that, in Whonix 10, we would not install the Debian profiles [apt-get install apparmor apparmor-utils], but not [apt-get install apparmor-profiles].


#490

Forget the previous post ( did not read fully you bug report).


#491

We did. But it was to get rid of the concerned forum posts that were generated because of these warnings. If I remember right?

Those messages are fixed in jessie.

The question now is, should we pre-install apparmor-profiles and/or apparmor-profiles-extra? But not enforce them by default? Would that increase usability? I guess it would save a few lines of instructions if users want to test some of these profiles. Not sure if it’s worth it.


#492

Yes, the profile are working in jessie (AppArmor 2.9).

If we install the Debian profiles, they will be enforced at boot by default (anything in /etc/apparmor.d is) unless we disable them (sudo aa-disable profile-name).

apparmor-profiles-extra will install the profile for Pidgin, which, unless Debian agrees to include abstractions/kde and the few extra lines for KDE, will not work in Whonix.

Most of the Debian profiles are confining packages that are not used in standard Whonix, so all in all, I think we should concentrate on our own profiles, but try to use as much as possible forked profiles from Debian, like we did with Pidgin.

I have yet to get in touch with Ulrike (lack of time for the moment).


#493

Pushed an update to apparmor-profile-sdwdate. A message popped up a couple of times. + /usr/bin/whoami

Updated all troubadoour apparmor-profiles repositories with latest debhelper too. There is a minor change to apparmor-profile-timesync. Nothing critical, probably a old update that was not pushed.


#494

All fine. Thanks. Both merged.


#495

Updated apparmor-profile-sdwdate for latest version for sdwdate (in testers / developres repository, Whonix 10.0.0.3.1-developers-only, sdwdate (3:1.8-1) https://github.com/Whonix/sdwdate/commit/9ee6b42b059c88d4801ea64e8329637507fa1232):
https://github.com/Whonix/apparmor-profile-sdwdate/commit/edc577eb0783746265bba38b963b227464b4b7dc

Profile link:
https://github.com/Whonix/apparmor-profile-sdwdate/blob/master/etc/apparmor.d/usr.bin.sdwdate

Even after reboot, I am still getting this:

Any idea how to fix that one?


#496

Not a solution to my above question, but something I was finding by chance, that we should use.

Reading log entries from /var/log/syslog.
Updating AppArmor profiles in /etc/apparmor.d.

Profile /etc/apparmor.d/usr.bin.sdwdate contains invalid mode rwcux.

1

Thereby found another issue with apparmor-profile-sdwdate.


#497

The last denied error should be fixed (missing “/”, /var/cache/sdwdate is a folder. It might work without slash, it might not).

The aa-logprof is an old one, could have been fixed earlier. Anyhow, done. I removed the tlsdate line too.


#498

Your commit fixed it. Thanks! Merged.

I reproduced this. The slash is critical here. Without the slash, the error occurs.


#499

Good. A question: is it a problem to update the corresponding AppArmor profile when we update a confined package in the testers/developers repositories? Or perhaps better, include the profile in the package, for sdwdate, timesync and whonixcheck? Would have to reload AppArmor in the kernel after installation.


#500

Good questions indeed!

In past the testers repository held preliminary fixes that were supposed to be migrated to stable soon. At the moment, the testers repository contains packages for the next version of Whonix (Whonix 10). Much higher versions. So adding stable-fixes (for Whonix 9) to that repository doesn’t work anymore. This dual purpose is really bad. It’s an issue, should the tb-updater package be upgraded just again, the package would have to go directly into stable without being able to give Whonix 9 stable-fixes testers an easy way to try it out. Besides manually getting that package. Dunno how otherwise that could be done better. I don’t know how well this answers your question. You tell me.

We could do this as a release goal for Whonix 11. Since we fully control these packages, this should be doable. If we well test this before release, there shouldn’t be much need for AppArmor fixes then?

Maybe. Probably not?

Long version: Gathered some information:
https://www.whonix.org/wiki/Dev/AppArmor

Short version:
We do enable AppArmor by default since Whonix 9. This is done by the grub-enable-apparmor (https://github.com/Whonix/grub-enable-apparmor) package.

During installation, the auto generated debhelper code will run, if apparmor is enabled (i.e. if “sudo aa-status --enabled” exits 0), the following command.

Looks like it does that all for us automatically? No manual reload required?