While I agree that per-application policy overrides would be really
helpful, these suggested solutions are overkill.
Overkill is SELinux's middle name isn't it. :P It always struck me as being
intentionally heavy handed... which is kind of a good thing if you're
looking for control above all else. That being said though...
In any case, this seems like functionality best provided by
crypto-policies itself.
Agreed, the simpler and less code complex the better.
On Mon, May 2, 2022 at 12:27 PM Robbie Harwood <rharwood(a)redhat.com> wrote:
> JT <jt(a)obs-sec.com> writes:
>
> >> IMO, there's a rather desperate need to be able to override the
> >> system-wide policy for individual processes, maybe via some sort of
> >> wrapper around one of the containerization technologies.
> >
> > Alternatively I wouldn't be surprised if at some point the industry
> > doesn't unofficially opt for a legacy openssl option which could be
> > utilized by legacy code, but still allow all the modern code to use
> > the new stuff. But of course if that did exist, tons of people would
> > just refuse to update their code and deps because they have an option
> > not to.
>
While I agree that per-application policy overrides would be really
> helpful, these suggested solutions are overkill.
>
> Concretely, crypto-policies works by managing various configuration
> files. All that's needed to override on a per-application or even
> per-process basis is to look at a different configuration file.
> Exposing an environment variable (when it's not already) or
> initialization option from the crypto library suffices for this.
>
In any case, this seems like functionality best provided by
> crypto-policies itself.
>
> Be well,
> --Robbie
>