Yeah for sure, I not make myself clear, i just would say ISO is mandatory for some pentester who work with ParrotOS, i have a dedicated laptop for that, and for all reason Paluniro said i prefer an iso also if i work with some VM.
Thanks for your answer i agreed with pratically all
So from what I have been able to spend time with, it is very difficult to setup and configure networks, I think the idea with gateway and workstation is a network hop? The documentation doesnt make it clear how to import and configure each. Any other documentation?
Hi @palinuro@Nico_Paul. Another Whonix dev here. We have distro agnostic packages installable for plain Debian. Their benefits go beyond anonymity purposes and would benefit you too:
Others are KDE specific and tune up its security and performance:
Some our projects like our secure time daemon could see use beyond our distro with a few tweaks. (Making sure an adversary cannot manipulate your clock has implications for SSL security and ensuring no RCE against an old/crufty NTP daemon is possible.
Your reluctance on embracing vitualization for performance reasons is understandable. Though in my experience as the KVM maintainer, running two VMs on your average machine nowadays has negligible overhead (assuming it has virtualization extensions). Benchmarks show KVM as the best performing on Linux. The only limited performance area is 3D acceleration but that will change when this feature is merged in Debian stable next.
I’ve considered containers a while back, but the security guarantees were much less than full fledged hypervisors can provide and so I went that route. Nonetheless if you want containers I can look into assisting on this front.
If you consider shipping Whonix KVM already installed in ParrotOS for people to use optionally, then this has the potential to lower usability barrier for newbies and help adoption.
There are some privacy/security solutions that people from the research community contributed to us a while back that would be useful to you too. The code is feature complete but needs help packaging which we would be grateful for.
Do you know specifically what of the 3D rendering processes is lower? If its anything that could be utilized by say hashcat etc its going to be difficukt to sell that simply due to the fact they are used so effectively when allowed. I honestly need to go find a whitepaper regarding the container vs virt security as i can make arguments in my head that pan out both ways; i know the basics on the differences of course but i can see how each would have a separate set of potential pitfalls. Depending on what would need to be configured and the like i would agree that options typically come with mostly positives, I have a kachine that is not limited on any front so i tend to overlook portability and light resource use but it is a huge factor to 90 % of our users i would estimate so that’s definitely something that would have to be tested to see the viability and at what expense if any it has on the rest of the system. Thank you for some reading material for tonight! Im glad this got revived and i hope we can at least form a long term academic collaboration if not obviously working towards this goal that the thread exists to discuss. Would there be any conflicts or difficulties in regards to keeping up with our update schedule? Its one of the core core core features that invoke such a deep admiration for parrot for many of our users, myself included, i really enjoy that there are typically significant updates versus easier, less noticeably affected “bugs”. If it needs fixed it gets fixed plain and simple (likewise with if it needs explored, we explore it!) i think if whonix stays rather true to those values as well then it would be reasonable to explore at least (not that it hasnt been done, i mean more along the lines of i think (Lorenzo will give you more thorough and accurate information than my brief thought on the matter) I would also rather go “back to the drawing board” a few handfuls of times before releasing something that doesnt live up to its potential. Again really glad this got revived, im going to get some reading in!
Thanks for your reply. Our major release cadence follows Debian’s release of stable-next, however we also tend to release in between that time whenever major tasks are completed according to volunteer availability or if there is an emergency security update (upstream apt bug for example).
As for the work on the host (which I think is what would most concern you) it is mostly a done deal once a virtualizer config is figured out. I tend to update it whenever new interesting features come up in the new stable libvirt package or to tweak settings for more security if I come across advice in research papers.
I have no problems figuring something out on the host side if needed.
A wise motto indeed. Also one which we tend to follow thanks to an active userbase that brings such problems to our attention
Well we can both be happy with at least being a step closer as we plan on supporting a Long Term Support that is based on Debian stable as well! You can find some more info under the release notes of 4.3 on the Parrot Blog, with more to info to come!
It happens on virtualized systems too, as many vulnerabilities allowed an attacker to exploit guest syscalls to the host system inside kvm/qemu, virtualbox and other major virtualization platforms, but probably it is way easier to break a container than to break a VM.
I think we are on the same track here.
We configured the system to prevent the startup at boot time of all the useless services by default, and it reduces not only the boot times and the memory footprint, but it significantly reduces the attack surface as well.
The security edition of parrot, which by design is meant to provide A LOT of pre-installed tools and services, exposes zero opened ports at boot, and all the services are frozen. Parrot Home and Parrot Security have the same programs running and the same memory footprint (and network exposure), and all the security tools and services (and their dependencies) are just dormant and disabled.
Our projects are on completely different rails, but i believe we are both going in the same direction.
For this reason i would like to re-open (or at lease try to) this discussion once we finish our conversion from a rolling release model to a more reliable LTS model.
Another big news for you is that we are starting to do a little audit on whonix to get familiar with your code, test your patches, read your code and eventually try to improve it as possible.
I am up to start this little audit session with the security club of my local linux user group here in Palermo.
i don’t have enough spare time to take a look at them by now, but i absolutely have to add it to my todo list for the next months.
I would also like to share our firejail configs with you as previously promised in another thread.
I wanted the firejail configs to become a standalone package (as some of you suggested) and i’m working on it.
It’s not just a matter of performance impact (as you said kvm is very well optimized), but it’s also a matter of flexibility. If we close every single process inside a kvm container, then programs can’t easily interoperate with eachother, it is very hard to merge them into a single workspace and none of us here at parrot os are capable of doing something better than qubes os.
We wanted to adopt containerization over virtualization because it adds a easily configurable and pretty decent level of confinement at an application level, not at a context level, and firejail allows us to to it with zero overhead, where overhead does not just mean cpu time, but also memory footprint, storage resources, network access etc.
Choosing an application level isolation system based on containerization over a context one based on virtualization offers another interesting feature for cheap: by closing an application into a VM does not automatically offer you a proactive defense against unknown exploits, like memory execution protection, syscalls limitations, controlled network access, filesystem isolation enforcement etc. instead you just create a virtual machine where the isolated application behaves identically as before, but now it damages another system instead of the host one, and any additional safety measure has to be taken apart in a way which is not related to what virtualization does.
The containerization technologies on the other side offer fine-grained control over what a containerized process can or cannot do on both the host system or the guest overlay.
Do you want to deny file executions in the home directory for that process? do you want to enable write-memory protection? do you need that process to not exceed a specific amount of memory? to allow only tcp traffic? to allow network routing to a different gateway? do you need to exclude some resources to the process? do you need to expose a completely different filesystem instead of reusing the original one? all of these goals (plus many many more) can be achieved by just writing an instruction in a config file.
I am not saying that containerization is safer than virtualization, or that process isolation is better than context isolation. I am just saying that these are different levels of the same technology, and the only way to achieve a decent level of security is to mix them in the proper way.
I see Parrot as a good brick to be used for a specific context, and virtualizing multiple instances of parrot for different isolated contexts would be an awesome way to isolate things.
Every context would be isolated from the other in full Qubes OS style, and every process of the same context would be not only isolated from the other, but its capabilities would be limited too.
I believe that opening a malicious pdf inside a kvm machine is NOT a secure way to open that pdf, while disabling memory execution network access, unnecessary syscalls and limiting filesystem access is a better solution. The combination of the 2 worlds is just sublime. I, as a parrot developer, am focusing on what happens when the kernel runs a process and how to make the system secure from that process and that process secure from the outside world, all of this on an almost general purpose distro with a pretty famous pentest edition. Qubes OS is doing an awesome job on both my field and context-based isolation with a project with only one goal: to provide a system as secure as hell. I think that you at Whonix are working on another important field, which is how to make network communication private an anonymous and how to keep the system as secure as possible from the outside (without being a firewall of course).
none of us is ready at the moment to co-operate in a practical way because none of us are actually working on the same bricks of the whole thing, but we have a lot to share eachother and a lot to experiment by merging our worlds and seeing what comes out.