Since radare2 is a Libre Reversing Framework for Unix it requires to access to debug running processes as well as to connect to external hardware in order to perform remote debugging.
We believe this application can benefit from having an stable version in snapcraft with classic confinement.
As per the Process for reviewing classic confinement snaps a snap needs to have both a requirement for classic confinement, and fit within one of the supported categories. Can you please take a look at this and let us know.
Also I think perhaps the process-control interface may allow the required access to debug running processes. Regarding interfacing with external hardware - can you please provide more details on what hardware devices? There are various interfaces that provide access to different hardware (e.g. raw-usb (for USB device access), opengl (for access to GPUs), adb-support (if you want to use adb to access devices) and many others) - please take a look at https://snapcraft.io/docs/supported-interfaces and hopefully it might already provide the access your snap requires.
radare itself doesnt require access to usb or adb, that’s required for the frida plugin to work (which is shipped in this same snap). About opengl, i dont see wy this should be required, it’s a commandline application and doesnt uses anything graphical.
ptrace seems to be not working in confined mode
Thanks for your response
Thanks Alex for your reply.
This application can be used to:
In order to archive this using an strict confinement I tried with the following plugs:
After the installation I connected those manually but still the snap can’t debug an external process, I still see the following error:
ptrace_attach: Operation not permitted
I understand that IDE’s require classic confinement, not sure about if it is required for the debugging capabilities or to be able to use the development dependencies required for each project.
But I believe that radare project requires this both, requires to be able to debug running processes, and to launch processes with unknown 3rd party dependencies in order to be able to debug them. In this fashion I believe that it can be considered an “IDE for machine code/ assembly language”, in one of their uses.
I’m still open to test any other interface to use destined to debug processes, but I think I already tried the significant ones that are documented. Also tell me if you require more information.
Regards,
I expect this failed due to the yama ptrace restrictions - see https://askubuntu.com/a/41656/218 for more info. This would need to be resolved manually by users of radare2 regardless of whether it is granted classic confinement or not. Although please let me know if this is not the case, ie. if it does work as expected under classic confinement.
Saying all that however, if a regular use-case of radare2 is to launch arbitrary processes provided by the user, then this can only be achieved via classic confinement. And so radare2 would then be considered to have a requirement for classic confinement.
Also I do not think it would be too much of a stretch to argue that radare2 fits within one of the supported categories for classic confinement as an IDE (although I note that ghidra has recently been made a snap as well and it is able to work under strict confinement, but perhaps it does have this same use case to launch and debug arbitrary programs - @dclane can you comment on this?). And so assuming publisher vetting can be done, then it seems possible that radare2 could be granted classic confinement.
Please let me know your thoughts on all the above.
Regarding ghidra, I was expecting to run into problems similar to the above, and there are still use cases such as debugging via various methods and with non-trivial dependencies that I am yet to test. This is why I held ghidra to the candidate channel for the time being.
It’s worth noting that ghidra is just a front end for other debuggers. The simple testing that I did was with the gdb over ssh method. This works ok as it connects to localhost over ssh, and launches GDB which at that point is not confined.
FWIW, I do agree that frameworks like ghidra and radare2 fall into the IDE category without too much stretch.
Thanks @alexmurray for the clarifications. I tried disabling the yama ptrace restrictions without any luck. The only combination that I managed to work is either in classic confinement or devmode.
Also as @dclane and for what @pancake told me, the case of ghidra is performing remote debug and not attaching itself as radare2 do. So in their case it should be enough using the network plug to debug other processes. With radare2 the ptrace_attach is performed by the same radare2 (inside the snap), so classic or devmode is required for what I understand now.
Not sure if we can test anything else or what options we do have at this point.
Thanks for the update @prodrigestivill - given this, it looks like the only way for radare2 to function properly as expected by its users is with classic confinement, due to the need to execute arbitrary binaries supplied by the user from the host system.
radare2 also fits in the IDEs / debug tools category for supported use-cases for classic confinement.
As such, the requirements for classic confinement for radare2 are understood. @advocacy could you please perform publisher vetting? Thanks 
+1 from me, I verified the publisher.