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