Closed monsieuremre closed 10 months ago
adrelanos
commented
11 months ago Licenses can be adjusted to make it work. No worries. I am open to change this for some repositories.
Can be GPL3+. And if upstream or you is adamant, could also be GPL2+. And if the "+" is an issue, can drop that too. Not a big deal.
Also happy after licence was adjusted to retire this git repository. Nothing would make me more happy than seeing if another upstream picks this up.
monsieuremre
commented
11 months ago Don't get me wrong I am all for GPL3 and later. It was the original project that forced the use of GPLv2 only. Also, the upstream maintainer of the project with 1500 apparmor profiles thinks it would be okay if I wanted to merge my full system policy to his project. That might be a better approach. He is also eager to add support for whonix as a seperate distro. We might choose that path.
There is also the other possibility that we leave those profiles all together and handle everything in one profile. I have tested this. It is not optimal definetely. But capabilities are severly restricted between processes. When more capability is needed, we check path, if it is one of the allowed ones, we change into one of our subprofiles. Only capabilities and network access are manages with subprofiles in this case. That way, we would only maintain a list of capabilities we allow for certain paths. Maintaining a list of capabilities for select binaries would be infinetely easier. And I would argue it provides most of the protection that we would acquire anyway.
Maintaining a full system policy with super duper fine grained profiles for everything ever is literally impossible. But this man's project is the closes thing that could ever exist. His build system is good. Profiles are maintained. They work, most importantly. There 1500 profiles, and even enforcing everything works fine. So if we decide to merge the policy to his project and you decide to use his package in kicksecure systems, that would be a better solution overall, probably. At least a rather more sustainable one. I am also open to other ideas for approaching this.
adrelanos
commented
11 months ago Don't get me wrong I am all for GPL3 and later.
That is good to know.
It was the original project that forced the use of GPLv2 only.
Risking to state the obvious about (GPL) licensing: https://github.com/roddhjav/apparmor.d could be easily mixed. What was forked and under GPLv2-only could stay GPLv2-only. No problem.
New apparmor profiles, any new supporting scripts that were not part of the original, could now in the fork be GPLv3+.
It is no issue at all to mix GPLv2(only) with GPL-any-other-version as long as it is in separate files.
But it @roddhjav's or your decision.
//cc @roddhjav
In any case, I want to make this easy. Please pick a license and send a PR to change it. Or let me know the license and I'll update the repository.
Also, the upstream maintainer of the project with 1500 apparmor profiles thinks it would be okay if I wanted to merge my full system policy to his project. That might be a better approach. He is also eager to add support for whonix as a seperate distro. We might choose that path.
Sounds all great!
adrelanos
commented
11 months ago I could even dual license it.
But then that seems not so logical. Therefore could re-license to:
That would give maximum flexibility in this case. Would resolve any (perceived) licensing compatibility issues. And this would have the added bonus of you having the ability to upgrade some source files to GPLv3(+) at a later point if that ever comes up.
monsieuremre
commented
11 months ago If we choose he more easy to maintain and sustainable path of merging with Pujol's project, then most anything would be up to him. I would create my pull with the file for the full system policy under GPL3 if he accepts. But then, the rest would be still up to him. The files from the very original project have to stay gpl2 only either way.
roddhjav
commented
11 months ago Regarding apparmor.d's license, the master license file is: https://github.com/roddhjav/apparmor.d/blob/main/LICENSE. I interpreted it as being SPDX-License-Identifier: GPL-2.0-only but I might have actually been wrong as it is the same than apparmor that is simply GPL2 (so regardless GPLv2+ or GPLv2-only).
apparmor.d is going to have more and more part merged into apparmor itself, so the aims is really to have the same license than apparmor.
Regarding full system policy, this is fully planned to support it, it even already has some dev doc. I just need to find enough time to test multiple implementations options on top of the current roadmap of the project (including coming conference).
adrelanos
commented
11 months ago Your request has been fullfilled. License has been changed to GPL-2.0-or-later just now.
Should there be any remaining licensing issues, please open a new ticket.
I would probably also grant copyright to initial major contributors and apparmor.d if it was requested.
unrelated to licensing:
This package will probably also soon be removed from deb.kicksecure.com / the Kicksecure source tree and if it gets merged elsewhere that would be amazing!
monsieuremre
commented
11 months ago Hello good sir. For a possible merger, this repository 'apparmor-profile-everything' would have to retire in any case, because it has almost nothing in common with the new approach. I have just ported some more profiles and restricted my default policy even more. At this point, the project might become difficult to be managed and maintained by a mere mortal like me. I am ready to transfer ownership to Kicksecure or Whonix. In the future, you can choose to merge the policy to Pujol's project once you think it has matured enough. Or you might keep it under Kicksecure/Whonix ownership forever. It's going to be up to you at that point.
I would just like to ask for two things. First, I want to continue maintaining the default full system policy. So I would like to be a maintainer in the repo, having maintainer privileges. Since only you or some other Kicksecure guy will have admin privileges, this shouldn't be a problem, because it can't go out of control. Which even if it could, it wouldn't anyway.
I would also like the copyright thingie in the header of the full-policy to stay there. You can modify the headers all you like. Whonix/kicksecure will be the main copyright holder for the project. But in the full-policy file, under that, I want the line with my name to stay there, granting me the same rights for that file.
Would you be interested in such a transition?
adrelanos
commented
11 months ago All reasonable and good with me.
Please send PRs for any header / etc changes. Also SPDX / reuse.software is cool but optional.
monsieuremre:
Hello good sir. For a possible merger, this repository 'apparmor-profile-everything' would have to retire in any case, because it has almost nothing in common with the new approach.
Ok. Will remove this repo from derivative-maker source tree soon.
I have just ported some more profiles and restricted my default policy even more.
What's the repository?
At this point, the project might become difficult to be managed and maintained by a mere mortal like me. I am ready to transfer ownership to Kicksecure or Whonix. In the future, you can choose to merge the policy to Pujol's project once you think it has matured enough. Or you might keep it under Kicksecure/Whonix ownership forever. It's going to be up to you at that point.
I am not sure I am following but most likely ok.
I would just like to ask for two things. First, I want to continue maintaining the default full system policy. So I would like to be a maintainer in the repo, having maintainer privileges. Since only you or some other Kicksecure guy will have admin privileges,
Sure. What repository would that be? Once I know the name, I can add maintainer privileges.
this shouldn't be a problem, because it can't go out of control. Which even if it could, it wouldn't anyway.
Indeed. Since I need to merge locally anyhow before I make redistributable / downloadable builds. So no issues with that.
I would also like the copyright thingie in the header of the full-policy to stay there.
Sure.
You can modify the headers all you like. Whonix/kicksecure will be the main copyright holder for the project. But in the full-policy file, under that, I want the line with my name to stay there, granting me the same rights for that file.
Sure.
Would you be interested in such a transition?
Yes.
monsieuremre
commented
11 months ago What's the repository?
Here: https://github.com/monsieuremre/full-apparmor-policy
Thank you very much. I'm starting the transition.
monsieuremre
commented
11 months ago It is waiting for your approval now.
adrelanos
commented
11 months ago Had no idea there are transfer requests.
@monsieuremre wants to transfer the monsieuremre/full-apparmor-policy repository to adrelanos/full-apparmor-policy.
Not sure what you have ind mind here? Accepted but good idea for you to manage a personal repository under @adrelanos? Or is this just supposed to be temporary?
Another option would be for Kicksecure/full-apparmor-policy to fork monsieuremre/full-apparmor-policy and then give you maintainer access to Kicksecure/full-apparmor-policy?
Btw I cannot archive this github repository before the next stable release tag because then building the current stable release tag might break. Any changes to this repository can be considered.
monsieuremre
commented
11 months ago Had no idea there are transfer requests.
@monsieuremre wants to transfer the monsieuremre/full-apparmor-policy repository to adrelanos/full-apparmor-policy.
Not sure what you have ind mind here? Accepted but good idea for you to manage a personal repository under @adrelanos? Or is this just supposed to be temporary?
Another option would be for Kicksecure/full-apparmor-policy to fork monsieuremre/full-apparmor-policy and then give you maintainer access to Kicksecure/full-apparmor-policy?
Btw I cannot archive this github repository before the next stable release tag because then building the current stable release tag might break. Any changes to this repository can be considered.
Hmm. Now that I think about it, I should have transferred it to Kicksecure as an organization and not to you directly. You can do the same from now on. You have control now. I'm sorry I should have probably do the transfer to Kicksecure instead. My bad.
adrelanos
commented
11 months ago What is the difference of full-apparmor-policy vs apparmor-profile-everything?
you could just become maintainer of apparmor-profile-everything and swap out most of the files?
Also wouldn't it be better if there was no extra repository and this being part of apparmor.d?
monsieuremre
commented
11 months ago Also wouldn't it be better if there was no extra repository and this being part of apparmor.d?
Yessirree absolutely can do. I can just push to pujol, but that would require some extra work on our end to define whonix/kicksecure as a valid seperate target in his installer. Which he also planned, so there would be no problem merging. But then, I would like to gently ask you transfer it back. I am really sorry for the transfering back and forth, has been kind of a messy process but hopefully will result in something good.
adrelanos
commented
11 months ago And previously I've deleted the repository from my personal account. :/ Sorry about that. Hope this won't be causing any data loss.
adrelanos
commented
11 months ago Maybe best to avoid any transfers. Adding maintainer rights doesn't require a transfer. The only thing that might bug you is the "forked from" message. Not sure that one matters to you. But a solution could be found for that too after there is a plan.
monsieuremre
commented
11 months ago And previously I've deleted the repository from my personal account. :/ Sorry about that. Hope this won't be causing any data loss.
Ouch. That was a rather quick decision you made there. Anyway, won't cause any data loss luckily, have everything local. You can just fork pujol's repo whereever you like and add me as a mainteiner. You do your licensing thing first. I will add the new files and do the adjusting to the old profiles to make it so that there is no way to get into unconfined space. Will keep my old extra header on the full policy as agreed.
adrelanos
commented
11 months ago And previously I've deleted the repository from my personal account. :/ Sorry about that. Hope this won't be causing any data loss.
Ouch. That was a rather quick decision you made there.
Yeah. That wasn't clever on my side. I'll make sure to be more careful next time.
Anyway, won't cause any data loss luckily, have everything local.
Great!
You can just fork pujol's repo whereever you like and add me as a mainteiner.
Let's see how to best handle this... [1]
You do your licensing thing first.
In that case I could just keep pujol's licensing as is?
(If there are any lintian nitpicks, I'd send PR upstream. It would only be formatting, metadata not licensing related.)
I will add the new files and do the adjusting to the old profiles to make it so that there is no way to get into unconfined space. Will keep my old extra header on the full policy as agreed.
[1] Why not contribute this upstream to pujol's repository?
On my side it seems a big task to fork a repository with thousands of appamor profiles + adding a delta on top of it.
What would be the delta and wouldn't that delta be better if non-existing and merged into pujol's instead or if not possible in a separate repository?
monsieuremre
commented
11 months ago [1] Why not contribute this upstream to pujol's repository? It is more than we need. Like we I can, but then I would have to fork it and test it. This would require blacklisting groups of profiles that are not kicksecure relevant, adjusting the existing profiles to not let any way to unconfined space, writing new profiles for random whonix specific stuff, and of course, testing. Which, is definetely more than just a days work. Isn't hard, but I can't test everything. So no can promise that it won't break on qubes and stuff. Because it most definetely one thousand percent will. Some random stuff needs profiles there probably.
adrelanos
commented
11 months ago Can we have co-install compatibility for apparmor.d and apparmor-profile-everything?
The issue is, on Debian (and probably many other Linux distributions) a file can always only be owned by 1 package. [1] For example (presumably) /etc/apparmor.d/wireplumber can only be owned by 1 package. Either:
Lets say apparmor.d ships (=owns) /etc/apparmor.d/wireplumber, and apparmor-profile-everything would also ship a file /etc/apparmor.d/wireplumber then these two packages could not be installed at the same time.
(If wireplumber were to merge and maintain the apparmor profile upstream, then it should be removed from apparmor.d to avoid code duplication and allow both packages, wireplumber and apparmor.d to be installed at the same time.)
I'd hope that apparmor.d one day gets added to packages.debian.org to make it easily installable on top of Kicksecure, Whonix. This would also lower maintenance effort for Kicksecure, Whonix.
So if you would fork apparmor.d to apparmor-profile-everything and would ship some of the same files, then both packages could no longer be installed by default. Therefore the best options I see:
I am only looking at this from a packaging standpoint to make sure that it is possible to co-install apparmor.d and apparmor-profile-everything at the same time without APT aborting because two packages are attempting to own the same file.
DPKG has no feature to declare "use files from apparmor.d but allow apparmor-profile-everything to take precedence in case it owns the same files".
That is the reason why I asked if it is possible to have everything in apparmor.d because then there are no APT (DPKG) conflicts. Also because upstream indicated to be open for Whonix support (which probably also "automatically" means Kicksecure compatibility). Quote:
https://forums.whonix.org/t/apparmor-d-full-set-of-apparmor-profiles-1500-profiles/17389/2
Author of apparmor.d here. Supporting whonix in apparmor.d is planned, but in pause due to time constraint (and a few technical issues). See: Full system policy profile - Question · roddhjav/apparmor.d · Discussion #233 · GitHub 4
If it is planned anyhow then that's perfect.
Otherwise the not so great option would be:
[1] Except if using config-package-dev which should be used as little as possible to reduce complexity.
monsieuremre
commented
11 months ago No worries. I'm gonna fork Pujol's repo just about now, and push my files. Then work on compatibility. After we feel ready and tested, we can go and merge with his project.
monsieuremre
commented
11 months ago Ok now I remember why I didn't fork Pujol's repo and instead created mine. He already has a full system policy thing that I didn't manage to make work. And I don't know go, so make --full won't look for my policy. But I have a better idea. One sec.
monsieuremre
commented
11 months ago Created my pull. If Pujol agrees to play along, then we are good, and the development & deployment of this policy will be a lot easier. If no, we are still stuck with the previous plan of making on our own.
adrelanos
commented
11 months ago Alright. Watching here:
adrelanos
commented
11 months ago With apparmor.d there's at least a skilled reviewer exceeding my AppArmor knowledge by far. Resulting in a much higher quality, security. This is my very much preferred solution.
monsieuremre
commented
10 months ago With apparmor.d there's at least a skilled reviewer exceeding my AppArmor knowledge by far. Resulting in a much higher quality, security. This is my very much preferred solution.
Absolutely. The make process has a default .deb target. With miniscule modifications, we can add a kicksecure target. I would also suggest moving anondist profiles from whonix to this repository too, one at a time. That way, not only is it easier to manage, has more eyes and has more qualified eyes, you can just build one deb package from the project that whonix would eventually install. And also in many ways I think Pujol's profiles are more restrictive than most of the kicksecure default profiles and they don't cause breakage to the extend that I could tell of. Lucky for everyone, he is willing to cooperate, is responsive and friendly and qualified. Eventhough I hesitated at first, I think merging our patches upstream and use his project is the best option kicksecure has.
monsieuremre
commented
10 months ago Closing, as moved to Full-Policy integration for Whonix/Kicksecure - And also everyone else
adrelanos
commented
10 months ago Link broken but probably still same one:
Alright. Watching here:
adrelanos
commented
10 months ago With apparmor.d there's at least a skilled reviewer exceeding my AppArmor knowledge by far. Resulting in a much higher quality, security. This is my very much preferred solution.
Absolutely. The make process has a default
.debtarget. With miniscule modifications, we can add a kicksecure target. I would also suggest moving anondist profiles from whonix to this repository too, one at a time.
Keeping lets say the sdwdate apparmor profile in the sdwdate repository as discussed in:
Hi. It is that time of the year. I wrote a full system AppArmor policy for Debian, since this does not seem to work anymore. I restricted it a lot (I guess). Combining with other profiles I ported from another project, it now functions. And by functions, I mean without breaking stuff. The base policy is relatively strict, and most sensitive root processes are covered in their respective profiles. I normally wanted to use this repo as a base but turns out licenses are not compatible with the other project. Anyway, I would like to merge the projects to bring this one back to life. This is important because there being a big name like Whonix behind a project makes all the difference for popularity and user trust. Else my project will just be some random abandonware in some years (or maybe not, but chances). Maybe the two can be rebased, license changed, or in some other way merged together. I am willing to do anything to help, if the maintainers are interested. If not, you can just close the issue.