I missed your first posts on that one.
Probably found cause and workaround:
Yes. That was one way, since we cannot modify abstractions.
The apparmor_parser error
profile has merged rule /usr/bin/obfsproxy with conflicting x modifiers
is true to the letter. In the local profile, we declare "/usr/bin/obfsproxy rix,", and suddenly says, out of the blue, "/usr/bin/obfsproxy PUx,". apparmor_parser cannot replace the profile with these conditions. [The '-r' switch stands for "replace", not "reload", that makes a difference if the profile is cached or not, and might explain why the problem has been delayed for me].
The problem does not lie with the process being run unconfined, but with two contradictory declarations. In the local profile, replacing "/usr/bin/obfsproxy rix," with "/usr/bin/obfsproxy PUx," solves the problem too. As far as I know. AppArmor does not care whether a process exists or not.
I am not that happy with what The Tor Project did in file
Rightly.. I guess someone upstream was using obfsproxy AND AppArmor. Giving the "PUx" mask was the easiest way to get around the problem (tor would not start, most likely), but, as it concerns the whole population of tor+AppArmor users, the line should not be in abstractions. Most of them won't be affected (outside Whonix, I do not believe many people have a 'system_tor' local profile), but the group of people using this configuration should have created and used a local profile. In that sense, it would probably be worth filing a complaint (or whatever, I don't know the procedure).
As a fix for Whonix 10, we should probably remove the whole
and eventually provide a separate AppArmor profile package for obfsproxy or submit a profile upstream.
Yes, we could create a profile for obfsproxy and use "/usr/bin/obfsproxy Px," only in local/system_tor. Then, we could submit it when we are happy with it.
does in that list anyway? Should be outside that list?
May be obfsproxy has to write its own log somewhere? Anyhow, that could be investigated when we use it.