Hi Siddhesh, On Mon, Oct 16, 2023 at 02:19:23AM -0400, Siddhesh Poyarekar wrote: > The binutils security policy[1] states that diagnostic tools should not > be expected to be safe without sandboxing, so it doesn't make sense to > recommend it as the alternative to ldd, especially since it is not a > drop-in replacement. Recommend sandboxing instead, since that is in > fact the safest known way at the moment to deal with untrusted binaries. > > [1] https://sourceware.org/git/?p=binutils-gdb.git;a=blob;f=binutils/SECURITY.txt > > Signed-off-by: Siddhesh Poyarekar <siddhesh@xxxxxxxxxx> > --- > man1/ldd.1 | 14 +------------- > 1 file changed, 1 insertion(+), 13 deletions(-) > > diff --git a/man1/ldd.1 b/man1/ldd.1 > index cca96ec4d..f86798566 100644 > --- a/man1/ldd.1 > +++ b/man1/ldd.1 > @@ -94,20 +94,8 @@ Thus, you should > .I never > employ > .B ldd > -on an untrusted executable, > +on an untrusted executable without appropriate sandboxing, > since this may result in the execution of arbitrary code. > -A safer alternative when dealing with untrusted executables is: > -.PP > -.in +4n > -.EX > -$ \fBobjdump \-p /path/to/program | grep NEEDED\fP Should we maybe keep this example, and suggest using it with sandboxing? Or is it not useful anymore? Thanks, Alex > -.EE > -.in > -.PP > -Note, however, that this alternative shows only the direct dependencies > -of the executable, while > -.B ldd > -shows the entire dependency tree of the executable. > .SH OPTIONS > .TP > .B \-\-version > -- > 2.41.0 -- <https://www.alejandro-colomar.es/>
Attachment:
signature.asc
Description: PGP signature