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

Whonix AppArmor Profiles Development Discussion


#1

This thread is a continuation of https://www.whonix.org/forum/index.php/topic,24.0.html, with a more appropriate subject description. The profiles are in https://www.whonix.org/wiki/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.

For a introduction to AppArmor, you can read http://wiki.apparmor.net/index.php/Documentation

@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… :slight_smile:

Edit by Patrick:
Changed title.


#2

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?

When I run.

I get.

Even though, I did run.

Beforehand. Perhaps that’s related?


#3
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.


#4

I agree, X shouldn’t crash no matter what AppArmor rules are in place. Using KDE and never had GNOME installed.

Will try the updated profile…


#5

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.


#6

Can you let me know your findings about X crashing?

I have added a profile for Icedove. See the comment in front of of the listing. I am working on it.


#7

Yes, will tell you.

And I will fix the link from the Advanced Security Guide.


#8

In a new VM now… A new browser profile is functional. My old browser profile causes a DENIED message which also prevented it from starting.

Then I switched back to a new profile. Got a DENIED message, that I didn’t get earlier.


#9

The Icedove profile works. Breaks enigmail addon, though. Denied messages.

apparmor="DENIED" operation="open" parent=4168 profile="/usr/lib/icedove/icedove" name="/etc/gnome-vfs-2.0/modules/" pid=21189 comm="icedove" requested_mask="r" denied_mask="r" fsuid=1000 ouid=0 apparmor="DENIED" operation="open" parent=4168 profile="/usr/lib/icedove/icedove" name="/etc/xul-ext/enigmail.js" pid=21189 comm="icedove" requested_mask="r" denied_mask="r" fsuid=1000 ouid=0 apparmor="DENIED" operation="open" parent=4168 profile="/usr/lib/icedove/icedove" name="/usr/share/applications/mimeinfo.cache" pid=21189 comm="icedove" requested_mask="r" denied_mask="r" fsuid=1000 ouid=0 apparmor="DENIED" operation="exec" parent=21189 profile="/usr/lib/icedove/icedove" name="/usr/bin/gpg2" pid=21248 comm="icedove" requested_mask="x" denied_mask="x" fsuid=1000 ouid=0


#10
Then I switched back to a new profile. Got a DENIED message, that I didn't get earlier.

apparmor="DENIED" operation="open" parent=6702 profile="/home/user/tor-browser_en-US/Browser/firefox" name="/home/user/tor-browser_en-US/.cache/event-sound-cache.tdb.b08dfa6083e7567a1921a715000001fb.i486-pc-linux-gnu" pid=6714 comm="firefox" requested_mask="rwc" denied_mask="rwc" fsuid=1000 ouid=1000

This message should be fixed by the line ‘deny owner @{HOME}/.cache/* rw,’. Will chek.

For Icedove, I am not using enigmail. I should! I will install the addon.


#11

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.


#12

[quote=“troubadour, post:10, topic:108”][quote]Then I switched back to a new profile. Got a DENIED message, that I didn’t get earlier.

apparmor="DENIED" operation="open" parent=6702 profile="/home/user/tor-browser_en-US/Browser/firefox" name="/home/user/tor-browser_en-US/.cache/event-sound-cache.tdb.b08dfa6083e7567a1921a715000001fb.i486-pc-linux-gnu" pid=6714 comm="firefox" requested_mask="rwc" denied_mask="rwc" fsuid=1000 ouid=1000[/quote]

This message should be fixed by the line ‘deny owner @{HOME}/.cache/* rw,’. Will chek.[/quote]
This worked.

Now I’ve got new DENIED message.

I guess we need to allow read access to whole /usr/share/fontconfig/conf.avail/.


#13

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.


#14
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.


#15

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…


#16
Now I've got new DENIED message.

apparmor="DENIED" operation="open" parent=1 profile="/home/user/tor-browser_en-US/Browser/firefox" name="/usr/share/fontconfig/conf.avail/51-local.conf" pid=9478 comm="firefox" requested_mask="r" denied_mask="r" fsuid=1000 ouid=0

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.


#17

The icedove profile works well so far. Got a few denied messages. Such as this one.

Needed to add 3 extra lines.

/usr/bin/gpg2 r, /usr/share/fontconfig/conf.avail/* r, @{HOME}/.local/share/applications/kate-2.desktop r,

Can you check please if they are sane and add them?


#18

I keep getting this as well.

Strange? No risk in allowing it, though, I think.


#19
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.

Can you please test that way?


#20

I guess it will work.

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.

  1. it can lead to instability, iceweasel could show error messages when a website or the user triggers a feature we haven’t triggered yet
  2. 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”.

Got another denied message.