Christoph Anton Mitterer wrote on Fri, Jan 21, 2022 at 04:16:36PM +0100:
> > Another possibility to implement this functionality
> > while avoiding all of the above disadvantages
> > would be to augment the recently proposed --file option
> > to also support removing, or passing if set functionality
>
> Hmm sounds rather ugly for my purpose? It would require a sidecar file
> for every such script, wouldn't it? And also adding further unnecessary
> stats and the like.
FWIW nixos will create a shell wrapper for many scripts (shell, python
etc) which sets appropriate environment variables then runs the original
script.
It's not a security feature though, so if someone wants to call the
underlying script directly they obviously still can
Here's one for youtube-dl for example:
$ cat $(which youtube-dl)
#! /nix/store/l0wlqpbsvh1pgvhcdhw7qkka3d31si7k-bash-5.1-p8/bin/bash -e
export
PATH='/nix/store/5bh6rpya1ar6l49vrhx1rg58dsa42906-python3-3.9.6/bin:/nix/store/h3ak1b5l5mv0g77vqyzx2rifcrk34zjb-python3.9-youtube-dl-2021.06.06/bin'${PATH:+':'}$PATH
export PYTHONNOUSERSITE='true'
export
PATH='/nix/store/8dwwqmzx0bisy0zsvaj09g8wcyd51zk9-atomicparsley-20210715.151551.e7ad03a/bin:/nix/store/jim7ngfm62sldfjs84ww9mnswc9mkmx4-ffmpeg-4.4.1-bin/bin:/nix/store/gaq8yl3avsrg9nwd844h1jkvrgvs85dj-rtmpdump-unstable-2019-03-30/bin'${PATH:+':'}$PATH
exec -a "$0"
"/nix/store/h3ak1b5l5mv0g77vqyzx2rifcrk34zjb-python3.9-youtube-dl-2021.06.06/bin/.youtube-dl-wrapped"
"$@"
(hmm I thought it also baked in the python paths, but these are actually
carved in at the start of the script itself; but I just meant it as a
note that with enough automation wrapping most of everything is possible)
> Even sounds like something that is rather delicate in terms of
> security.
> Consider a script that's started with such file, but the file is not
> actually existing.
> An attacker is somehow able to create the file and add things like
> LD_PRELOAD_LIBRARY to it.
Note if your goal is to protect yourself from LD_PRELOAD there isn't
much you can do at this level: the preload library just has to hook over
all kind of exec() functions and they can add themselves back there.
I've seen at least one library that does it and the only way I'm aware
of to get rid of it is to use the linker's "secure-execution mode"
(AT_SECURE bit set in getauxval, usually setuid or capability program),
but it might not always be practical...
(I'd be more than happy to be proven wrong here, but it's a tricky
problem when the said library can intercept just about anything you can
think of)
--
Dominique
