not really a fan of adding OS-specific features in general, and OS-specific sandboxing mechanisms in particular.

for linux we'd need to add seccomp, for openbsd pledge, and for freebsd capsicum.
not only does each of them clutter the code with ugly ifdefs, but it also easily breaks when new features are added or some code in the vecinity changed. it adds maintenance burden.

therefore imo the better approach is to use sandboxing mechanisms that aren't intrusive (code of every program needs to be changed), but work with unmodified programs. examples are tomoyo linux, containers, chroot/jails, or USER_NS style sandboxes (nsjail, bubblewrap et al).

Hi, I understand that you are not a fan , maintaining all the mechanisms is difficult and maybe not in scope of a project like tinyproxy. I also agree that it would clutter the code, or at least requires a different architecture, so that each mechanism can be implemented using a plugin like mechanism. I could change the code to to this instead of doing ifdefs in all the code places. But implementing the same in pledge or seccomp would not be easy, this is due to the build in casper server which separates the capabilities into separate processes under freebsd.

OS-level sandboxing can help to mitigate the issues to some degree, but all mentioned mechanisms are allowing a great deal of privileges, far more than needed to do the tasks done by tinyproxy. I plan to use tinyproxy in a jail btw. So this is an added layer of security. I would not agree to say these mechanisms are equivalent in the protection they provide, but I assume everyone knows that.

In my eyes 12a8484 shows how important these mechanisms are to prevent an intruder from running any code he likes after finding a hole. I don't want to argue with you about adding the code if you don't want. Especially if you can't maintain it, I want to thank you for all the time and effort you put into this project.

PS: The GPL requires me to share my modifications, which did with this PR :-) . I assumed others might find the code helpful as well. I can continue to maintain a fork for it.

so that each mechanism can be implemented using a plugin like mechanism.

i doubt that this could be made flexible enough to be useful for all the different sandbox mechanisms, and would probably add even mode complexity.

I would not agree to say these mechanisms are equivalent in the protection they provide

well, at least in the case of tomoyo and nsjail one can run tinyproxy with a profile/list of allowed syscalls, which can either automatically be gathered by tomoyo's helper programs or extracted via strace. in such a case it's advisable to run tinyproxy in a minimalistic config that only uses stdout logging (no syslog or logfiles), no pidfiles and no user switching. using such a config it should even be possible to deny opening any files in write mode.

I can continue to maintain a fork for it.

that might be the best solution for the moment. maybe it could even be maintained as a patch for the official freebsd package, just like openbsd maintains their own set of pledge patches.