-
-
Notifications
You must be signed in to change notification settings - Fork 14.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
nixos/security.cyber-toolnix: add module #345300
Conversation
This module is used to install pentesting tools based on the chosen role. Options are: * `blue` (Blue Teamer), * `bugbounty` (Bug Bounty Hunter), * `cracker` (Cracker Specialist), * `dos` (DoS Tester), * `forensic` (Forensic Specialist), * `malware` (Malware Analyst), * `mobile` (Mobile Specialist), * `network` (Network Specialist), * `osint` (OSINT Specialist), * `red` (Red Teamer), * `student` (Student), * `web` (Web Pentester)
Is there any precedent for using |
I would propose to deny this pull request, I am not familiar with the governance and RFC's in Nix, but apparently Meta-Packages are not official features Discourse and would add another layer of complexity/maintaining to the repository. |
How manage "metapackages"-like? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
First, thanks for your effort and creating this great collection.
However, as already stated from others, I am unsure how fitting this collection is for the nixpkgs as meta-package. Maybe providing these roles outside of the nixpkgs would be more useful, e.g., in another repository or in the wiki.
Lastly, this may be just a personal or cultural thing, but the name "cyber" is a bit vague. Just call it pentesting-tools
or the like.
blue = import ./roles/blue.nix { inherit pkgs; }; | ||
bugbounty = import ./roles/bugbounty.nix { inherit pkgs; }; | ||
cracker = import ./roles/cracker.nix { inherit pkgs; }; | ||
dos = import ./roles/dos.nix { inherit pkgs; }; | ||
forensic = import ./roles/forensic.nix { inherit pkgs; }; | ||
malware = import ./roles/malware.nix { inherit pkgs; }; | ||
mobile = import ./roles/mobile.nix { inherit pkgs; }; | ||
network = import ./roles/network.nix { inherit pkgs; }; | ||
osint = import ./roles/osint.nix { inherit pkgs; }; | ||
red = import ./roles/red.nix { inherit pkgs; }; | ||
student = import ./roles/student.nix { inherit pkgs; }; | ||
web = import ./roles/web.nix { inherit pkgs; }; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
With no offense, I think the roles are a bit arbitrary and I am unsure that someone specially wants all tools from a one rule, and not select those tools necessary for the task at hand. Thus, I am unsure how helpful the whole idea of this PR is.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Instead of roles we can set categories (i.e., nix-wireless, nix-networking, nix-recon, and so on). I am open to change that name. About pentesting-tools
, yes, even if there are some tools (i.e., for the part of the defense) that I dont think can be under the "pentesting" terms, despite they are used in the cyber security context (for Blue Team part).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Instead of roles we can set categories (i.e., nix-wireless, nix-networking, nix-recon, and so on).
Pardon, but what is the difference between roles and categories? I would think about smaller categories (to stick with the name), but then allow multiple categories, not just one.
Furthermore, it should be document what each category contains, as at the moment it just loads hundreds (!) of packages in your environment without really communicating what will be available. So the user will end up with lots of tools, but not known which or how to deal with them.
Btw, have you evaluated how much storage is necessary for the bigger categories?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No, but I can try to do that. I mentioned categories just as occurs in other pentesting distros as Kali Linux or BlackArch.
Yeah, same. I don't think there is much point of those meta package lists and I don't think it is a good reason to do it because Kali installs does things by default or with a meta package. If people need a tool or specific set of tools for some specific project or task or course or something, then that should be tracked outside of nixpkgs.
That reminds me of https://www.youtube.com/watch?v=WY6KkRsS26M :) |
Thank you for your feedbacks. If you agree, and there is no a more efficient way or interest to organize pentesting tools, I can close this PR. Please let me know. |
My simple way to track the toolset is https://github.com/fabaff/nix-security-box. There the packages are grouped at my personal discretion. The grouping is done not so much on a role-based model but more on tasks. |
This module is used to install pentesting tools based on the chosen role. Options are:
blue
(Blue Teamer),bugbounty
(Bug Bounty Hunter),cracker
(Cracker Specialist),dos
(DoS Tester),forensic
(Forensic Specialist),malware
(Malware Analyst),mobile
(Mobile Specialist),network
(Network Specialist),osint
(OSINT Specialist),red
(Red Teamer),student
(Student),web
(Web Pentester)Description of changes
Things done
nix.conf
? (See Nix manual)sandbox = relaxed
sandbox = true
nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD"
. Note: all changes have to be committed, also see nixpkgs-review usage./result/bin/
)Add a 👍 reaction to pull requests you find important.