"/** r" would be too much. Then the browser could read and leak any file on hdd. What about just "/ r"? Doing an "ls /" doesn't leak anything useful.
Added “deny / r,”. That does the job, the access is refused without apparmor message. Fine for me.
[quote]Anyhow, you can create any folder under ~/Downloads, from a terminal or the file manager, and save the downloads there.[/quote]
Giving mkdir ~/Downloads permissin Tor Browser shouldn't hurt anyway?
~/Downloads has read/write access already. Allowed /usr/bin/mkdir.
[quote]
It would be OK to create the folder by default. And then recommend the user to set "Save files to -> Downloads" in the Tor browser "Edit/Preferences/General" dialog box. That might save some hassle.[/quote]
Ideally it would be best if all that would be possible without editing any prefs.
Yes, it would be best, but i am facing a problem. I cannot know what the user has in the home folder, so clicking anywhere but the chosen downloads folder in the profile will flash a message. I don’t see a way around that.
I think we agreed on that. But it will probably never work seamlessly due to technical challenges, unless well, I am not even sure what kind of feature request against AppArmor could be made. Eventually one against Firefox.
Firefox is the most likely candidate.
I have added an abstraction (will probably add more) to make the profiles more readable for the maintainers. Also trying to deny access to the files that do not seem necessary to the good functioning of the packages. I put them at the beginning of the profile, for readability too.
All the profiles using X will follow on the same line.
I forgot to mention that I had another unrecoverable problem with a snapshot. I don’t remember exactly the sequence of events that led to the situation, but anyhow, I think It would be best to recommend against using them now. My [.vbox .vmdk ~/.VirtualBox] backup was unusable after the crash.
[quote=“Patrick, post:144, topic:108”][quote author=troubadour link=topic=97.msg1586#msg1586 date=1397252181]
I forgot to mention that I had another unrecoverable problem with a snapshot. I don’t remember exactly the sequence of events that led to the situation, but anyhow, I think It would be best to recommend against using them now. My [.vbox .vmdk ~/.VirtualBox] backup was unusable after the crash.
[/quote]
Done. Removed it everywhere in the wiki. Removed it from VirtualBox’s VM import text. (Will appear in Whonix 8.2. + 1.)
This bug can really be a pain.[/quote]
Correction 8.2.
Got a new denied message.
[code]apparmor="DENIED" operation="open" parent=1 profile="/home/user/tor-browser_en-US/Browser/firefox" name="/etc/group" pid=31425 comm=4D6564696120417564696F requested_mask="r" denied_mask="r" fsuid=1000 ouid=0[/code]
Fixed (with deny).
Added two abastractions (freedesktop.org and user-download) in Tor Browser, Icedove and Pidgin. The profiles look more standardized.
In Pidgin, removed some abstractions and fixed the “Network rules not enforced” message printed when replacing the profile with apparmor_parser.
I am still wary about testing the “/* {…}” profile to replace abstractions/whonix, but it will happen, eventually. In the meantime, more to come toward standardization. and a couple of other things, the help menu in Pidgin and Xchat amongst them.
There are a few Pidgin related denied messages, but those happened with the old as well as with the new profile. Those lead to Pidgin crashing, not finishing startup and exiting.
The Pidgin profile is updated. The usr/share/fontconfig/ and /home/user/.config/oxygen-gtk/ folders are not in my workstation. I 'll put them as default in a local profile for all the packages using an interactive GUI.
I am trying to build the apparmor-profile-torbrowser package. I have some problems and I might need some frequent help there, at least at he beginning.
[code] Now signing changes and any dsc files…
signfile apparmor-profile-torbrowser_0.1-1.dsc Patrick Schleizer adrelanos@riseup.net
gpg: skipped “Patrick Schleizer adrelanos@riseup.net”: secret key not available
gpg: /tmp/debsign.jarXEDy2/apparmor-profile-torbrowser_0.1-1.dsc: clearsign failed: secret key not available
debsign: gpg error occurred! Aborting…
debuild: fatal error at line 1278:
running debsign failed
Nonetheless, the package should be fully functional and installable using “dpkg -i pkg-name”. (Can be found in parent folder.)
The signing bug is because my e-mail address is in debian/changelog. We have a few options here:
you ignore the error
you expand debian/changelog (using dch), that would be the clean way, having multiple authors
you or I change debian/changelog to your name
i can add support for command line options to be passed to debuild to the ./build script, then build --someswitch keyid could be used, easy, i can do this soon and perhaps should do that anyway
We don’t sign the package at all - no idea if this is even useful because in Whonix’s vm build process or apt repository creation, it is the repository that needs to be signed, not individual packages, and for own builds for own use, you don’t profit from signing. Package signing makes more sense if we start allowing multiple maintainers uploading packages to Whonix’s repository where there repository software checks package signatures for inclusion into Whonix repo.
I guess for now it’s simplest to go with an easy solution and to get into this stuff. Later, in case you’re interested to upload packages (you’re welcome!) to Whonix’s repository, we can do that as well.
For the moment I am struggling to get apparmor-profile-torbrowser packaged. It did work earlier after I commented the lines dealing with the signing in debuild (a very temporary solution). Now dpkg -i is working with the normal output (preparing…, replacing…, setting up…) but the package is not found (not in /usr/bin, nowhere on the disk), be it built with signing or not. Trying to find out.
- you ignore the error
Hardly, at the moment.
- you expand debian/changelog (using dch), that would be the clean way, having multiple authors
I suppose I would have to commit to do that? If I add my key locally in the changelog using dch, with the same syntax as yours, it does not work. It's probably not as simple as that.
- i can add support for command line options to be passed to debuild to the ./build script, then build --someswitch keyid could be used, easy, i can do this soon and perhaps should do that anyway
If that is easy and if it's just a matter of adding my key ID to the ./build command...
I guess for now it's simplest to go with an easy solution and to get into this stuff. Later, in case you're interested to upload packages (you're welcome!) to Whonix's repository, we can do that as well.
Regardless of the chosen solution, the idea would be to upload all the profiles packages (or a single package installing all of them) in the Whonix repository. As I maintain the AppArmor pages in the wiki, that would make sense to update the packages after a test period following the wiki updates.
It won’t install any files to /usr/bin. I think the confusion comes from how Debian handles config files in /etc.
As per debian/apparmor-profile-torbrowser.install the package installs only two important files
It takes home.user.tor-browser_en-US.Browser.firefox and installs it to /etc/apparmor.d/ and it takes local/home.user.tor-browser_en-US.Browser.firefox and installs it to /etc/apparmor.d/local/. (Plus some “less important files” in /usr/share/doc/apparmor-profile-torbrowser/.)
When you manually made changes to /etc/apparmor.d/home.user.tor-browser_en-US.Browser.firefox, then Debian will remember that and not overwrite your config file again. Which means, when you install the package, it won’t overwrite this file. To get rid of this behaviors, you can “sudo apt-get purge apparmor-profile-torbrowser” (and eventually manually delete that file beforehand). Then home.user.tor-browser_en-US.Browser.firefox can be found in /etc/apparmor.d/ after installing the package with “dpkg -i”.
[quote]- you expand debian/changelog (using dch), that would be the clean way, having multiple authors[/quote]
I suppose I would have to commit to do that?
Yes.
[quote]- i can add support for command line options to be passed to debuild to the ./build script, then build --someswitch keyid could be used, easy, i can do this soon and perhaps should do that anyway[/quote]
If that is easy and if it's just a matter of adding my key ID to the ./build command...
I will implement this today, then post again here.
[quote]I guess for now it's simplest to go with an easy solution and to get into this stuff. Later, in case you're interested to upload packages (you're welcome!) to Whonix's repository, we can do that as well.[/quote]
Regardless of the chosen solution, the idea would be to upload all the profiles packages (or a single package installing all of them) in the Whonix repository. As I maintain the AppArmor pages in the wiki, that would make sense to update the packages after a test period following the wiki updates.
Sounds good. If you want to pursue pre-test in the wiki, that is up to you to decide. Whatever you feel most appropriate. I personally don't post my updated scripts to the wiki either. I install and test them manually, then add them to developers repository, test again, then migrate to the testers repository. Again, up to you, what you prefer. I don't want to make up a giant policy for anything. Whatever works best.
As I understand it, debuild forwards options to dpkg-buildpackage which forwards options to dpkg-genchanges. “-us -uc” are options understood by dpkg-genchanges.
dpkg-genchanges’s man page, says, there is a “-mmaintainer-address” option. So you can also sign it with your key, using.
simplified debian packaging, it’s now more generic
More generic as in that package can be easier used as a template. It is now simpler to make a copy of the package, rename it, put different apparmor profiles inside it with less debian packaging overhead.
./build is now more generic.
Package name = folder name. No more need to adapt the package name.
Only thing that needs to be updated is the version variable. (Eventually I should read/extract version number from debian/changelog? No idea if that would be legitimate.)
Files in /etc/… in source folder will be installed to /etc/… on hdd, theoretically files in /usr/bin/ etc. would be installed to /usr/bin and so forth. debian/package.install file is no longer required, now obsoleted, thanks to the rsync debian/rules method as suggested on debian-mentors mailing list. This style of debian packaging will make task split Whonix into multiple packages simpler, I think, since no debian/package.install file is required anymore.
debian/changelog still needs manual maintenance using the dch tool. I don’t think that can/should be improved.
No idea how close such a style of debian packaging would be for inclusion into Debian. Some debian maintainer could help a lot.
I hope this doesn’t sound complicated. See this as a comprehensive changelog and explanation. I believe overhead for packaging should now be lower.