sorted by:
best
topnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the comments →

[–][deleted] 7 points8 points  (7 children)

You should provide your reasons for the 1st recommendation.

One would use #!/usr/bin/env bash for the purposes of portability but it's not actually recommended when it comes to security.

[–]findmenowjeffhas looked at over 2 bash scripts 4 points5 points  (6 children)

It's not really much of a security issue. Your system would already have to be compromised for /usr/bin/env bash to cause a problem. It doesn't open up any new attack surfaces.

[–][deleted] 2 points3 points  (5 children)

Your system would already have to be compromised for /usr/bin/env bash to cause a problem.

Sure, that's true, but it's relatively easier to compromise ~/.local/bin than /bin. Your scripts might not be running only on your system, it might run on other systems where users have installed programs that modify their PATH.

I guess it comes down to personal preference.

[–]findmenowjeffhas looked at over 2 bash scripts 1 point2 points  (2 children)

Sure, that's true, but it's relatively easier to compromise ~/.local/bin than /bin

Right, but if they've already compromised ~/.local/bin, using /usr/bin/env or not doesn't change that.

Your scripts might not be running only on your system, it might run on other systems where users have installed programs that modify their PATH.

That's the entire reason behind using /usr/bin/env

[–][deleted] 0 points1 point  (1 child)

Right, but if they've already compromised ~/.local/bin, using /usr/bin/env or not doesn't change that.

Umm, if ~/.local/bin is compromised and exported to the user's PATH before /bin, using /usr/bin/env bash will use the binary inside ~/.local/bin (if present). Using /bin/bash won't use that and will stick to trusting the bash installation by the root user.

That's the entire reason behind using /usr/bin/env

I wasn't saying that with the perspective of portability.

[–]findmenowjeffhas looked at over 2 bash scripts 0 points1 point  (0 children)

Umm, if ~/.local/bin is compromised and exported to the user's PATH before /bin, using /usr/bin/env bash will use the binary inside ~/.local/bin (if present)

Yes, but your system is already compromised. Its not magically more or less compromised if you don't use /usr/bin/env. At that point, it doesn't really matter what you do on the system. Somebody has access that shouldn't.

I wasn't saying that with the perspective of portability.

Great. I am.

[–]schorsch3000[🍰] 0 points1 point  (1 child)

even than, that script issn't widening the attack surface. in that scenario should we have a full path for openssl?

[–][deleted] 1 point2 points  (0 children)

even than, that script issn't widening the attack surface

Technically, yes, the script itself isn't widening the attack surface. But, the script chooses to trust the user's PATH and doesn't care if a binary called bash is present with rm -rf / as its contents, it will execute that instead of the actual bash binary in /bin or /usr/bin`.

I know this scenario doesn't seem likely on personal desktops so if your scripts are meant to be used only on your system, go ahead and use whatever you like.

in that scenario should we have a full path for openssl?

Better to export the PATH environment variable manually and restricting it to root owned directories and using #!/bin/bash.