Whonix AppArmor Profiles Development Discussion

Further simplified packaging. Updated my post above.

Tested again GitHub - Kicksecure/apparmor-profile-torbrowser: AppArmor profile for The Tor Browser Bundle (TBB) - https://www.whonix.org/wiki/AppArmor - for better security (hardening).. Works very well for me. Maybe soon we can call for wider testing?

Works well for me too. One missing piece though.

I did the following:

  • ./build -us -uc # ./build - mymail@mail.com does not work.
    The profile is in the the source etc/

  • dpkg -i apparmor-profile-torbrowser_0.1-1_all.deb
    dpkg reports an apparmor_parser error, not finding abstractions/whonix
    The profile is in /etc/apparmor.d

But before delving further into the intricacies of debian packaging, one important question: How do you update the profiles? In the earlier version, there was a file home.user.tor-browser… that I could edit.

Answering the easy question first.

It’s here.

apparmor-profile-torbrowser/etc/apparmor.d/home.user.tor-browser_en-US.Browser.firefox apparmor-profile-torbrowser/etc/apparmor.d/local/home.user.tor-browser_en-US.Browser.firefox

And gets installed to.

/etc/apparmor.d/home.user.tor-browser_en-US.Browser.firefox /etc/apparmor.d/local/home.user.tor-browser_en-US.Browser.firefox

Isn’t that awesome? Minimal overhead for packaging. :slight_smile:

The syntax is a bit weird (not my idea, using what Debian provides). It is “-m” directly followed without space by your e-mail address. Try this. Note the bold part.

./build -mmymail@mail.com

[And you need a gpg key with that e-mail address in ~/.gnupg [configurable].]

[quote=“troubadour, post:163, topic:108”]- dpkg -i apparmor-profile-torbrowser_0.1-1_all.deb
dpkg reports an apparmor_parser error, not finding abstractions/whonix
The profile is in /etc/apparmor.d[/quote]

I guess this is a problem with the AppArmor profile apparmor-profile-torbrowser/etc/apparmor.d/home.user.tor-browser_en-US.Browser.firefox because it does “#include <abstractions/whonix>”.

Are you sure you have a /etc/apparmor.d/abstractions/whonix file?

If I don’t have one, I get your error.

[code]sudo mv /etc/apparmor.d/abstractions/whonix /etc/apparmor.d/abstractions/whonix_

ls /etc/apparmor.d/abstractions/whonix
ls: cannot access /etc/apparmor.d/abstractions/whonix: No such file or directory

sudo dpkg -i apparmor-profile-torbrowser_0.1-1_all.deb
(Reading database … 136023 files and directories currently installed.)
Preparing to replace apparmor-profile-torbrowser 0.1-1 (using apparmor-profile-torbrowser_0.1-1_all.deb) …
Unpacking replacement apparmor-profile-torbrowser …
Setting up apparmor-profile-torbrowser (0.1-1) …
AppArmor parser error for /etc/apparmor.d/home.user.tor-browser_en-US.Browser.firefox in /etc/apparmor.d/home.user.tor-browser_en-US.Browser.firefox at line 14: Could not open ‘abstractions/whonix’[/code]

But if I have one, it works for me.

[code]sudo mv /etc/apparmor.d/abstractions/whonix_ /etc/apparmor.d/abstractions/whonix

ls /etc/apparmor.d/abstractions/whonix
/etc/apparmor.d/abstractions/whonix

sudo dpkg -i apparmor-profile-torbrowser_0.1-1_all.deb
(Reading database … 136023 files and directories currently installed.)
Preparing to replace apparmor-profile-torbrowser 0.1-1 (using apparmor-profile-torbrowser_0.1-1_all.deb) …
Unpacking replacement apparmor-profile-torbrowser …
Setting up apparmor-profile-torbrowser (0.1-1) …
[/code]

I guess this problem with be temporarily solved when you re-create /etc/apparmor.d/abstractions/whonix or when apparmor-profile-torbrowser/etc/apparmor.d/home.user.tor-browser_en-US.Browser.firefox no longer sources abstractions/whonix, when the whonix specific thing became it’s own profile (the old idea, you know, the one we discussed earlier).

Isn't that awesome? Minimal overhead for packaging. :)

Yes, awesome! It’s making life much easier, and I will be able to package the other profiles, too.
And ./build -m… works, so the package is signed with my key. I thought the ‘m’ was a typo in your first post.

Very encouraging.

Are you sure you have a /etc/apparmor.d/abstractions/whonix file?

No, my mistake. I am running with a fresh workstation because I had a strange problem with a Python IDE (eric), and after trying everything I could think of, I reinstalled the whole workstation, and had not reinstalled the apparmor profiles.

I guess this problem with be temporarily solved when you re-create /etc/apparmor.d/abstractions/whonix or when apparmor-profile-torbrowser/etc/apparmor.d/home.user.tor-browser_en-US.Browser.firefox no longer sources abstractions/whonix, when the whonix specific thing became it's own profile (the old idea, you know, the one we discussed earlier).

I realize that the big problem with abstractions/whonix is that if the file is not included in the distribution, apparmor_parser replace will fail. I will try to include the whonix profile as a child profile in TBB first. As far as I know, apparmor_parser does not care whether the allowed/denied files exist or not, as long as the masks are understood. It will still show in the profile to advanced or curious users, but it should be packaged transparently.

In the meantime, I have tried to package apparmor-profile-torbrowser with abstractions/whonix, adding it to the source etc. Not possible. This is for my own enlightement :), correct me where I’m wrong. The postinst part is managed by dh_apparmor, including the folders where to install the files (/etc/apparmor.d and /etc/apparmor.d/local), and they are the only folders we should allow to update. Realistically, we cannot tamper with the abstractions, because they are written upstream.
Conclusion: abstractions/whonix is definitely out.

[quote=“troubadour, post:168, topic:108”][quote]
I will try to include the whonix profile as a child profile in TBB first. As far as I know, apparmor_parser does not care whether the allowed/denied files exist or not, as long as the masks are understood. It will still show in the profile to advanced or curious users, but it should be packaged transparently.
[/quote][/quote]

The latter is true, but as to include a child profile, why not use the local profile.

Digest. abstractions/whonix is no longer an alternative. Nor is the whonix profile. At best, with ‘/*’, it has no effect. At worst, if i push it to ‘/**’, it has a regrettable tendency to crash the workstation beyond recoverability.

I have moved the content of local/home.user.tor-browser_en-US.Browser.firefox back into the main profile and pasted the content of abstractions/whonix in the local profile, then removed the line ‘#include <abstractions/whonix>’.

With hindsight, that is probably what I should have done from the beginning.

Now, trying to build the modified profile package. Following debian/gain-root-command:

make clean
make[1]: Entering directory `/home/user/apparmor-profile-torbrowser'
make[1]: Warning: File `Makefile' has modification time 0.44 s in the future
git clean -df
make[1]: warning:  Clock skew detected.  Your build may be incomplete.
make[1]: Leaving directory `/home/user/apparmor-profile-torbrowser'
 dpkg-source -b apparmor-profile-torbrowser
dpkg-source: info: using source format `3.0 (quilt)'
dpkg-source: info: building apparmor-profile-torbrowser using existing ./apparmor-profile-torbrowser_0.1.orig.tar.gz
dpkg-source: info: local changes detected, the modified files are:
 apparmor-profile-torbrowser/etc/apparmor.d/home.user.tor-browser_en-US.Browser.firefox
 apparmor-profile-torbrowser/etc/apparmor.d/local/home.user.tor-browser_en-US.Browser.firefox
dpkg-source: error: aborting due to unexpected upstream changes, see /tmp/apparmor-profile-torbrowser_0.1-1.diff.zg6_wB
dpkg-source: info: you can integrate the local changes with dpkg-source --commit
dpkg-buildpackage: error: dpkg-source -b apparmor-profile-torbrowser gave error exit status 2
debuild: fatal error at line 1357:
dpkg-buildpackage -rdebian/gain-root-command -D -us -uc -sa -mtrobador@riseup.net failed
+ '[' '!' 29 = 0 ']'
+ exit 1

There is “aborting due to unexpected upstream changes”.
If I try to modify changelog with dch according to the literature in /tmp/apparmor-profile-torbrowser_0.1-1.diff.hGsTAX, it results in a parsing error.

Should I commit first, without modifications?

After making changes to any files in the source folder, you need to commit them before you can use ./build again. Otherwise you get this error.

Background:
Debian wants an upstream tarball. This is quite messy imho nowadays. The upstream tarball is created deterministically using git archive in the build script (you won’t notice). It’s all a bit messy, but that’s it. I wouldn’t know how to make it any less messy than it currently is. Already tried to make it as generic as possible. You get used to it.

Slightly advanced git stuff:
To clean the history, for testing, I usually create a temporary branch. Ex:
git branch test
git checkout test
git status
git commit -a -m .
./build
git commit -a -m .
./build
git checkout master
git merge --squash test
git status
git commit
git branch -D test

No need to edit any files in /tmp/.

Yes. I’d prefer if we somehow manage to have nothing “whonix” inside apparmor-profile-torbrowser. [Otherwise we would have apparmor-profile-torbrowser to depend on a apparmor-profile-whonix profile, which would be bad, since then the profile wouldn’t be usable outside Whonix.] Souring abstractions/whonix from apparmor-profile-torbrowser is indeed bad.

In the meantime, I have tried to package apparmor-profile-torbrowser with abstractions/whonix, adding it to the source etc. Not possible. This is for my own enlightement :), correct me where I'm wrong.
Just for enlightenment: You could create a folder in apparmor-profile-torbrowser/etc/apparmor.d/abstractions and drop a file apparmor-profile-torbrowser/etc/apparmor.d/abstractions/whonix there. It should be installed just fine by dpkg.
The postinst part is managed by dh_apparmor, including the folders where to install the files (/etc/apparmor.d and /etc/apparmor.d/local), and they are the only folders we should allow to update.
I think /etc/apparmor.d is okay to be used by packages such as apparmor-profile-torbrowser, but /etc/apparmor.d/local/ is only for users. We should avoid the latter if possible.
Realistically, we cannot tamper with the abstractions, because they are written upstream. Conclusion: abstractions/whonix is definitely out.
Yes.
why not use the local profile.
Because the latter is for the user. The user should be able to make local additions/changes, which won't conflict with any changes by us. If possible, we should avoid the local profile. As last resort, it would be in violation of debian policy but within the freedom of being a debian derivative to use the local folder.
At worst, if i push it to '/**', it has a regrettable tendency to crash the workstation beyond recoverability.
Are you sure this isn't happening by chance? I am willing to test this in one of my less important workstation VMs. Can you post the /etc/apparmor.d/whonix with '/**' that we would like to use?

I will be deleting /etc/apparmor.d/abstractions/whonix and testing the following + apparmor-profile-torbrowser.

## This file is part of Whonix.
## Copyright (C) 2012 - 2014 Patrick Schleizer <adrelanos@riseup.net>
## See the file COPYING for copying conditions.

## Whonix AppArmor Profile

## Workaround for: config-package-dev clashes with AppArmor profiles
## https://github.com/Whonix/Whonix/issues/66

/* {
   /etc/hosts.whonix r,
   /etc/resolv.conf.whonix r,

   @{HOME}/.whonix/* rwk,

   /etc/whonix.d/ r,
   /etc/whonix.d/* r,

   /etc/hosts.whonix r,
   /etc/resolv.conf.whonix r,

   /usr/bin/gpg.whonix rix,
   /usr/bin/gpg.whonix-orig rix,

   /usr/lib/whonix/confirm_open rix,
   /usr/lib/whonix/uwtwrapper rix,
   /var/lib/whonix/whonixblog/ r,

   /usr/share/whonix/kde/share/config/kdeglobals r,
}

## End of Whonix AppArmor Profile

Okay, I changed to ‘/**’ and removed “@{HOME}/.whonix/* rwk,”…

Then I keep getting.

VM crashed. This is strange.

Is this a bug in AppArmor or something very wrong with the profile?

Could be recovered by booting in recovery mode and “aa-disable /etc/apparmor.d/whonix”.

Can you ask please on AppArmor list please if it’s possible to create a global profile? (For our /etc/apparmor.d/whonix /** use case?)

Can you post the /etc/apparmor.d/whonix with '/**' that we would like to use?

I am using the content of abstractions/whonix, like you.

Then I keep getting.
error while loading shared libraries: libselinux.so.1: cannot open shared object file: No such file or directory

VM crashed. This is strange.

Is this a bug in AppArmor or something very wrong with the profile?

Same error here, and VM crashing. I don’t think there is anything wrong with the profile. I have tried

/** { }

with the same result.

May be a bug in AppArmor, but I doubt it. When declaring /** as profile name , we are trying to confine the whole disk, probably with unexpected consequences. Also, as far as I remember, the use of wildcards is not authorized in the profile name. We talked about it for home.user.tor-browser_*.Browser.firefox. Now, as the wildcard is not inserted inside the name, it seems to be accepted by apparmor_parser.

I did ask on the AppArmor list, but so far, I had zero success with my inquiries. I’m on the apparmor IRC channel, there is a better chance to get a reply there, I think (if someone shows up).

Had chat with jjohansen on the apparmor IRC channel.

An excerpt.

I thought about it and here is what I think is going on once /** is loaded just about everything is confined (early init may not be, unless you have it reexec it self, or explicitly change its profile) some programs will link to libselinux and use that to detect if selinux is available they will use it to change their behavior, examples would be dbus passing the security context through, and doing selinux policy modiation gnome displaying the security context in the file info dialog ls showing the security label on a file your profile (/**) isn't allowing access to libselinux, so these apps, die instead of continuing its likely they are just using the dynamic linker, and making the library a hard dependency (that is the symbol is required vs weak) the reason you need recovery mode is because the apparmor profile is being every time you reboot

For the sake of trying, I have added ‘/lib/i386-linux-gnu/* mrix,’ in the profile. Then any command outputs ‘permission denied’. Allowed the whole /usr/bin/ and /usr/sbin without change.

I do not think we can push further in that direction as we would end up allowing the entire file system.

For the moment, the solution seems to be a local profile for each profile. I do not know what Debian’s position is, or how edgy they are when it comes to packaging for them, but they do package all the Ubuntu abstractions. We do not add an abstraction, we just call a local profile without any reference to Whonix in the main profile. The local profile may be empty, that won’t make a difference when running the profile outside Whonix.

Debian is very picky. I am quite sure, they won’t allow shipping local profiles.

To keep the Whonix-specific stuff out of apparmor-profile-torbrowser I have another idea.

apparmor-profile-torbrowser profile does…

#include <abstractions/base> #include <abstractions/user-tmp> #include <abstractions/bash> #include <abstractions/fonts> #include <abstractions/kde> #include <abstractions/gnome> #include <abstractions/audio> #include <abstractions/freedesktop.org> #include <abstractions/user-download>

Do all profiles created by you share a common abstractions/… file? abstractions/base perhaps?

We could displace abstractions/base using config-package-dev. A package apparmor-profile-whonix could take over ownership of abstractions/base. Then we add Whonix specific stuff to the bottom of abstractions/base.

Whonix is doing this with a few files already. See Whonix-Gateway “ls /usr/share/tor/tor-service-defaults-torrc*”.

  • When Debian pushes an upgrade, it will go to /usr/share/tor/tor-service-defaults-torrc.whonix-orig.
  • When Whonix pushes and upgrade, it will go to /usr/share/tor/tor-service-defaults-torrc.whonix.
  • /usr/share/tor/tor-service-defaults-torrc is a symlink to /usr/share/tor/tor-service-defaults-torrc.whonix

Very clean, simple and robust solution so far. Disadvantage: when Debian upgrades /usr/share/tor/tor-service-defaults-torrc.whonix-orig, it must be manually checked if these changes have to be added to /usr/share/tor/tor-service-defaults-torrc.whonix.

This is easy to package once you got the hang for it. I can easily do this if it looks like an okay solution. In case of apparmor-profile-whonix it would be even easier to maintain. /etc/apparmor.d/abstractions/base.whonix could include /etc/apparmor.d/abstractions/base.whonix-orig. So when Debian upgrades abstractions/base, we don’t have to update Whonix’s displaced version. If it sounds too theoretic, I can do a proof of concept.

Updated the Tor Browser profile.

‘/etc/gai.conf’ required when setting transparent torification. I use a VPN when the Debian wiki bans Tor, once in a while. Have you experienced that?

Looking into your abstraction/base displacement. It looks sound. First of all, all the profiles use abstractions/base.

Yes. I am using startpage proxy in that case.

Good, will be done shortly.