My system is Novell SLES 11.4 x86-64.

I was presented with:

The ldd command must be disabled unless it protects against the execution of untrusted files.

If you google the above you can easily obtain more information about it.

The oem setting of /usr/bin/ldd is root.root with permissions 0755.

It was also stated "An acceptable method of disabling 'ldd' is changing its mode to 0000"

If I do this and disable ldd completely then my system does not work. The first ramification I immediately found was YAST doesn't work.

So the first compromise was to do chmod 644 /usr/bin/ldd while leaving the file owned by root.root. This still causes problems and errors when running legitimate software (where a lot of money is spent on licensing).

So I have since concluded this request is either antiquated or just bad.

Looking for thoughts & suggestions, thanks.

  • I think that if you wanna go the secure way, chown -x -ing your ldd ain't quite the way to go. Just my 2 cents.
    – schaiba
    Aug 24, 2016 at 15:31

2 Answers 2


I've never heard of this advice before, and it's just plain wrong.

On Linux, ldd is typically a bash script and ends up doing the equivalent of

LD_TRACE_LOADED_OBJECTS=1 /lib64/ld-linux-x86-64.so.2 your_program

So ldd doesn't actually execute "any" program itself, but calls the binary loader and that tries to run your program.

(The rest of the script is basically a wrapper to work out the correct ld.so to call; eg 32bit, 64bit, etc).

Removing permissions from ldd has zero security gains on Linux.

  • The script had a known vulnerability in the past, so the advice used to be valid for distributions which hadn't fixed that... Aug 24, 2016 at 15:55
  • 1
    Note that the CVE is "disputed". All it does is stop people who don't realize that ldd could effectively be the same as executing a file. Indeed on other OS'es (eg Solaris) it does execute the file specifically. This CVE is a "band aid" along the lines of "don't put . on your PATH". Aug 24, 2016 at 16:05
  • Yes, indeed; I should have qualified that (it's valid if you consider the STIG rules to be valid). In any case, since SLES applied the fix for the CVE, the point is moot... Aug 24, 2016 at 16:12

This refers to CVE-2009-5064, which is fixed in SLES since 11 SP1. So you should be covered by the “it protects against the execution of untrusted files” clause. You can find more information on the vulnerability and a proof-of-concept here.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .