This thread is a continuation of Whonix Forum, with a more appropriate subject description. The profiles are in AppArmor. Anyone ready to use them for further testing is welcome. The more users and error reporting, the earlier the profiles could be integrated in a future Whonix update. I am using the Tor browser in confined mode now.
@Patrick
About the new denied message you get in the fresh Whonix 8 VM, I had the same one and it is fixed now. Anyhow, it does not prevent TBB to work properly.
I see that you have reorganized the profiles, I was going to do it. I have updated the Tor browser profile and I will add a profile for Icedove. It should be completed shortly. Once you have the hang of itâŚ
No DENIED messages in syslog with the updated TBB profile anymore. But in the old Whonix 8 VM, I still get logged out. Still havenât figured out what extra configuration is triggering it. And without DENIED message it seems difficult figuring why X crashes. Any idea how to diagnose this?
Eventually I am still using an old profile? But when I replace the old file with new content and re-run aa-enforce, it should enforce the new profile?
In the Pidgin profile we use apparmor_parser, not for the TBB profile. Is this a required difference? Why? Should we rather use apparmor_parser everywhere or drop it at all if unnecessary?
No DENIED messages in syslog with the updated TBB profile anymore. But in the old Whonix 8 VM, I still get logged out. Still haven't figured out what extra configuration is triggering it. And without DENIED message it seems difficult figuring why X crashes. Any idea how to diagnose this?
It is very strange that it crashes X, with or without DENIED message! First, I donât undestand why TBB makes a call to â/etc/gnome-vfs-2.0/modules/â in your old Whonix 8 VM. As far as I know, it should not, as you are running KDE. I am walking blind folded here, so I have modified the lines referring to gnome. Could you try it?
Eventually I am still using an old profile? But when I replace the old file with new content and re-run aa-enforce, it should enforce the new profile?
As far as I know, yes. Although, before running aa-enforce, I use to run aa-disable first. I do not think it is necessary. The easiest way is still âapparmor_parser -râ.
The ânetwork rules not enforcedâ warning is very unlikely related to the problem. It was caused by one line I had forgotten to remove from the original profile (ânetwork tcp,â) and that was not much bothering me, since âanything not specified is not allowedâ, quoting the AppArmor documentation. The message should not pop anymore, either at boot or with apparmor_parser.
Still crashes X. I get the feeling, I wonât find out before starting with a fresh install, keeping installing and customizing until I trigger that bug.
A bit off topic, commenting a remark you made earlier about not putting general AppArmor profiles in the wiki or updates.
To make things clear, for the moment, I work with AppArmor exclusively in Whonix. Because it is relevant to Whonix, I will just try to push the VirtualBox profile through Ubuntu, in the hope that it migrates back to Debian. By the way, should I put it in the wiki, after some trimming?
The reason is not only the poor response from Debian (nothing back from the apparmor team there, yet). It is true that it is more rewarding to try to help in a distribution where you are sure to get a strong feedback where it matters. And seeing the sort of support you begin to receive since you came out in the clear is encouraging not only for you but for for the users too, because it shows that Whonix can become a usable alternative for those who are keen on their anonymity/privacy. So if the work on AppArmor can give a slight lead in security, all for the best. Except for Ubuntu, I do not see any distribution really trying in that field.
Whatever information useful to share with anyone is welcome in the wiki. We could also create whonix.org/wiki/Dev/AppArmor for development notes. Iâd like to see the VirtualBox profile on AppArmor as well.
The reason is not only the poor response from Debian (nothing back from the apparmor team there, yet). It is true that it is more rewarding to try to help in a distribution where you are sure to get a strong feedback where it matters. And seeing the sort of support you begin to receive since you came out in the clear is encouraging not only for you but for for the users too, because it shows that Whonix can become a usable alternative for those who are keen on their anonymity/privacy. So if the work on AppArmor can give a slight lead in security, all for the best. Except for Ubuntu, I do not see any distribution really trying in that field.
The only ones who replied my Debian AppArmor specific inquiries was intrigeri. I donât think there is already a Debian AppArmor team.intrigeri maintains lots of packages in Debian and Iâve seen itâs (pseudonymous person, I donât know if male or female) work on Debian all over debian.org. And itâs also a Tails developer. I have no idea how a single person can get so much work done in the time available.
Contributing to Debian seems difficult. They have a strict policy and you probably also have to understand their social bonds. I guess meeting up with them in real life would help. Itâs a huge project. Difficult to coordinate that many volunteers. While I think that many of Debianâs approaches are outdated, and ineffective (such as their bug tracking system which I still find cumbersome to use and which deters newbies), we may not forget, that Debian still is the base for many other Linux distributions, such as Whonix, Ubuntu, many more. Many things in Debian seem to be ingrained. You may be able to put into a lot effort and change one thing or another, but it requires too much effort. Due do things being deeply ingrained, I donât think the Ubuntu developers (before it became a spyware encumbered distribution) could have contributed to Debian instead and I donât think it would be possible to let debian.org look like ubunut.com. I mean, Debian seems too established for huge and fast changes. Many things are in urgent need for a revision, but no one is up to do the work that would be required to 1) fork Debian 2) make huge changes required 3) convince current Debian developers to join the new project 4) forget the old Debian 5) become the new Debian. This of course includes me. Again, letâs be happy that Debian, even while non-perfect exists, because no Debian would mean no Ubuntu, no Whonix, etc.
What you could do is asking if they could create a real AppArmor mailing list. Or join their IRC channel. Become the one in charge in Debian responsible for Debian, since I think there currently is no one really working on it except for intrigeri who is very involved. Itâs up to you of course. I am just making suggestions. No one can force you to contribute to Debian as no one can force me to contribute to Tails rather than maintaining Whonix.
I am not criticizing Debian, and people like intigeri certainly do what they can and they certainly do more. At least she/he took the time to reply to my inquiry. For the moment, I just donât feel an urge to collaborate with them as it might become a waste of time I prefer to devote to Whonix.
About Ubuntu. It is fortunate that debian.org never becomes an ubuntu.com bis (I hope so). ubuntu.com looks like a marketing platform and the forums are a shambles, and there is another reason why I dropped them, apart from your comments in this forum, about Canonical especially. When I upgraded to 13.04, there was an Amazon button in the Unity panel. I deleted it straight away, but it left some tracesâŚ
Whatever information useful to share with anyone is welcome in the wiki. We could also create whonix.org/wiki/Dev/AppArmor for development notes. I'd like to see the VirtualBox profile on whonix.org/wiki/AppArmor as well.
I will put the VirtualBox profile in the wiki. Creating the Dev/AppArmor page is a good idea, although perhaps I should take some time and gain a little more experience to put down some clear and sensible literature on the mechanics for writing profiles. After all, I am quite fresh in the field, and so far, I have been operating by trial and error. May be thatâs the only wayâŚ
I guess we need to allow read access to whole /usr/share/fontconfig/conf.avail/.
I have added the line to the profile. Itâs funny, because this directory is not in my system.
Also modified the Icedove profile with Enigmail. It should be working as it was tested creating and importing keys (yours), and sending signed and encrypted messages between different mail accounts.
Needed to add 3 extra lines.
[code]
/usr/bin/gpg2 r,
/usr/share/fontconfig/conf.avail/* r,
@{HOME}/.local/share/applications/kate-2.desktop r,
[/code]
Can you check please if they are sane and add them?
I have allowed â/usr/bin/gpg2â as I think it might be required. I have no â/usr/share/fontconfigâ directory and I have not met a kate-2, yet :'(, so, to play it safe, I have added two lines in the deny list at the beginning of the profile. Denied âfontconfigâ the TBB profile too.
I am not sure it is a good idea to deny access to these files. As far I understand the AppArmor approach, the profile ought to allow every legitimate action of the confined application. For example, writing into /Download/Iceweasel might be a legitimate action. The idea is, should iceweasel get exploited, i.e. get controlled by a remote adversary, it will for example try to access ~/.gnupg/private_key to send the key to the adversary. Obviously iceweasel has no business doing so. AppArmor is our last line of defense here.
Denying access to which arenât malicious is bad for two ideas.
it can lead to instability, iceweasel could show error messages when a website or the user triggers a feature we havenât triggered yet
from an anonymity perspective (browser fingerprinting by destination servers), TBB AppArmor users want to look as TBB non-AppArmor users. For example, when we forbid reading fontconfig, this could result in firefox using fallback code or error handling code which is different from TBB non-AppArmor users.
(If everyone would use your profile, i.e. if TBB for non-Whonix users came with your profile by default enabled, then 2) wouldnât apply to to a less extend, but thatâs not the case yet.)
From a security perspective, reading the fontconfig folder that doesnât include any private data doesnât pose a risk, even if an adversary read it.
Forbidding access to a few files TBB has legitimate reason to read such as /etc/resolv.conf may be in exception to this. This is even more true for non-Whonix users. Those exceptions need to be carefully considered.
Could you please re-check your profiles for these conditions?
(Please feel free to challenge my thoughts on this topic. To get wider input for your profiles, the tor-talk mailing list would be a good place. No worries. I wouldnât consider this an offense. Just saying. Only thing I am interested in here is best possible software.)
Other notes:
TBB also needs mkdir access for â~/tor-browser_en-US/.cacheâ.
