15-CURRENT

[SirDice]

noexec won't actually prevent anything from being executed. You can still execute those files, just not directly.

sh /tmp/myexploit.sh works, even if /tmp is mounted noexec

 

[covacat]

noexec won't actually prevent anything from being executed. You can still execute those files, just not directly.

sh /tmp/myexploit.sh works, even if /tmp is mounted noexec

it will prevent custom binaries so your exploit should work with shell, perl, python whatever

 

[Deleted member 82802]

sh /tmp/myexploit.sh works

And it will work if +x is not set on the file, so I still don't understand what difference would not setting +x on /tmp make.

 

[cracauer@]

Lack of discipline about /tmp/ file placement is one of the top security issues I observe.

Always make a directory in there (and if it already exist, make sure it is yours). Operate in your directory.

 

[ShelLuser]

noexec won't actually prevent anything from being executed. You can still execute those files, just not directly.

sh /tmp/myexploit.sh works, even if /tmp is mounted noexec

True, but nevertheless this can still be an invaluable risk prevention. On my system I always set up /tmp and /var/tmp with noexec (ZFS) and it has saved my servers many times from "professional PHP developers" which scripts allowed 3rd parties to inject scripts (and programs) into /tmp while attempting to execute them.

Script kiddies use scripts, which usually don't operate beyond the simple "save & execute" mentality.

(edit)

Lack of discipline about /tmp/ file placement is one of the top security issues I observe.

Always make a directory in there (and if it already exist, make sure it is yours). Operate in your directory.

Agreed. One of the main reasons I started "hacking" the standard PostgreSQL settings; I don't even want any 'random' or casual sockets in there either.