On Wed, Apr 27, 2022 at 08:37:36AM +0200, Christian Ehrhardt wrote:
> The following would do, but since apparmor is an allow-list for mandatory access
> that could end up reading weird unless there is a nice trick to
> allow-all-but ...
>
> audit deny signal (receive, send) peer=/usr/bin/pv set=("exists"),
On Wed, Apr 27, 2022 at 08:40:34AM +0200, Christian Ehrhardt wrote:
> To some extent I consider this nothing more than an advanced version of
> DD having SIGUSR1 to report progress output - and that never was a problem.
>
> I wonder, is everything with an IPC msgqeue a problem or is there something
> here that I do not yet see that makes this more affected?
>
> Could you outline what level of concern you have here - see the starting
> quote of "just raising an eyebrow" and "total blocker" .
>
> And if it is important - would trying to create any of the following
> help a lot to overcome your concerns?:
> a) something like the apparmor profile Thomas suggested?
> b) an opt-out option like "--no-remote - do not create IPC
> msgqueue for later change of arguments"
> c) it was just a hint and would not be a blocker
Thomas nerd-sniped me into looking at how it's implemented :) it's a
sysv message queue! which is very exciting, I don't think I've actually
seen one used in the wild before.
I didn't try to exploit it at all, but I had the impression that the worst
outcome would be fiddling with the interval, which is passed as a double.
Floating point values are very fiddly things and perhaps passing in a NaN
or trap representation or a crazy small or large value would lead to
unexpected behaviour.
An opt-out like --no-remote might be nice but it's honestly pretty hard to
see when anyone would choose to use that. An opt-in would be better if we
were designing this from scratch, but it's pretty well-known and widely
used now, so I consider that ship sailed.
Certianly this is no blocker, but another set of eyes for a few minutes
would be nice.
Thanks
