Merged, thanks.
Somme changes in apparmor-profile-gwenview some locked masks required · troubadoour/apparmor-profile-gwenview@f21bb4c · GitHub.
Probably an old issue, discovered while viewing icons.
Merged, thanks!
Replaced the Whonix profile for Pidgin, after your topic Whonix Forum.
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.
Alright. Thanks. Tested. Merged. And added some minor commits on top.
Can you subscribe here please?
https://phabricator.whonix.org/tag/apparmor/
Or if you wish notification for all newly created tasks, see:
Done.
We probably can start with hexchat profile before jessie becomes Debian stable.
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.
FYI:
Related to Download Whonix ™ (FREE) 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
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].
Forget the previous post ( did not read fully you bug report).
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.
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).
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.
All fine. Thanks. Both merged.
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) bumped changelog version · Kicksecure/sdwdate@9ee6b42 · GitHub):
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:
Feb 4 15:39:11 host kernel: [14935.817259] type=1400 audit(1423064351.899:38): apparmor="DENIED" operation="open" parent=25161 profile="/usr/bin/sdwdate" name="/var/cache/sdwdate/" pid=25163 comm="find" requested_mask="r" denied_mask="r" fsuid=0 ouid=0Any idea how to fix that one?
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.
1Thereby found another issue with apparmor-profile-sdwdate.
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.
Your commit fixed it. Thanks! Merged.
I reproduced this. The slash is critical here. Without the slash, the error occurs.
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.
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.
apparmor_parser -r -T -W /etc/apparmor.d/usr.bin.sdwdateLooks like it does that all for us automatically? No manual reload required?