12

If I want to set a capability (capabilities(7)), such as CAP_NET_BIND_SERVICE, on an executable file and that file is a script, do I have to set the capability (setcap(8)) on the interpreter starting that script or is it sufficient to set it on the script file itself?

Note: the question concerns Scientific Linux 6.1 in particular, but I think it can be answered generically.

Gilles 'SO- stop being evil'
  • 829,060
0xC0000022L
  • 16,593

2 Answers2

12

Setting capability on the script will not be effective. It's the similar situation as not working setuid bit on script. Similar as in the latter case it's the implementation of how execve handles shebang and the security reasoning behind it (for details see: Allow setuid on shell scripts).

I think you have these options

  1. set the capabilities on interpreter itself (actually rather a copy of it)

    • you have a problem here that anybody who is able to execute it will run with those elevated capabilities (be able to execute some arbitrary script or start it interactively)

  2. write a wrapper executable which will have a hardcoded logic to execute your script, and set desired capabilities on this executable

    • make sure that nobody is able to modify nor remove / replace the script
    • still by doing chroot one might missuse such wrapper

In both cases you would have to make sure capabilities set will survive execve by setting inheritable flag. You might also use pam_cap distributed with libcap usually, to actually activate desired capabilities by configuration only for selected users.

And in general you want to make sure nobody is able to modify behavior of your interpreter by changing environment eg. PYTHON_PATH or something similar.

Community
  • 1
Miroslav Koškár
  • 1,828
-1

Now, in the year 2022 and if your system uses systemd, you may also create a systemd unit config and run the script from there, also listing the required capabilities with CapabilityBoundingSet= directive.

Student4K
  • 119
  • 2
  • This existed even in 2012, as this blog entry by the principal author of systemd proves. So your "answer" doesn't really provide anything other than commentary, to be honest. This was never about a service, despite the name of the capability perhaps insinuating it. Personally I find the distinction between "privileged ports" and "unprivileged ports" and the result capability to be rather dated. The only goal was to be able to have a script listen on one of the "privileged" ports for a brief period without running as superuser. – 0xC0000022L Sep 19 '22 at 08:38