3 ms·
Because arbitrary "Thou Shalts" do not prevent security holes. Make a restriction, and hackers will find the cracks around it. The only way to stop them is to f
by peterwwillis 7y ago
Because arbitrary "Thou Shalts" do not prevent security holes. Make a restriction, and hackers will find the cracks around it. The only way to stop them is to fill the cracks, and the only way to find the cracks is to look for them. Now, certainly if there was an exec() replacement that was more secure, you should use that; but banning exec() entirely is doing more harm to functionality than good to security.
Particularly, the exec() bug here is one of misunderstanding the security guarantees of interfaces; particularly, that there are none. Not validating inputs is the single most universally known security practice, and yet it wasn't done here. On top of that, not using typed objects further increases potential for attacks. This was just shit security design. exec() had about as much to do with the bug as your brakes have to do with you locking up your wheels when traveling too fast in rain/snow/ice. (that you should have been going slower, not that the brakes are defective)
- ainar-g 7y agoI haven't proposed to ban exec entirely. I've proposed to ban exec uses that just sends data into a shell.
- loeg 7y agoWhen a user runs 'sh -c "foo"' on the command line, how do you think that is executed? Taking a step back, Unix's programming model is heavily influenced by the design requirements of interactive bourne shell. It's hard to outlaw shell-like things without breaking shells.