3 ms·

> and you get brownie points for having found that without passing it to the OS? You should probably reconsider your security model. Did you really just sugges

by atoav 2y ago

> and you get brownie points for having found that without passing it to the OS? You should probably reconsider your security model. Did you really just suggest passing arbitrary input to your OS filesystem to see if it fails? You can probably (hopefully?) figure out yourself why this is a bad idea. Ever heard of defense in depth? Sanitizing your inputs early and knowing why things failed is a good things. Having an additional redundant layer is not a bug, but a feature, especially if the underlaying layer has shown to be exploitable. Also consider that if you process user provided filenames you have to sanitize them anyways, unless you want them to give you filenames like /root/.ssh/authorized_keys

kazinator 2y ago
> Did you really just suggest passing arbitrary input to your OS filesystem to see if it fails? Yes? This is what I expect from programs as a user. Whatever input I give them that is intended for the OS, should be passed through to the OS verbatim. There may be some very specific exceptions to that, but that's the general principle. > You can probably (hopefully?) figure out yourself why this is a bad idea. I've not seen this after 42 years of coding, sorry. > Having an additional redundant layer is not a bug, It can easily turn into a bug where second-guessing the user's OS turns into some kind of hindrance where they are not able to do something they should be able to do. It's a waste of time coding it. It erodes consistency. One program in one language/runtime restricts things one way; another one has a slightly different idea. > Sanitizing your inputs early and knowing why things failed is a good things. You don't seem to have a fully developed intuition for when this concept applies. > unless you want them to give you filenames like /root/.ssh/authorized_keys I've never seen an application that actually has a list of banned filenames like /root/.ssh/authorized_keys and checks every user input against it. It's a complete nonstarter. If the user wants to tell a program to overwrite /root/.ssh/authorized_keys, the program should just do it. If the user is not root, that path should not be accessible. If the user is root, it may be allowed to overwrite it even if it has no write permissions. The system security model and configuration has decide that; it's not the application's business to second-guess that policy.

by atoav 2y ago

kazinator 2y ago

> Did you really just suggest passing arbitrary input to your OS filesystem to see if it fails? Yes? This is what I expect from programs as a user. Whatever input I give them that is intended for the OS, should be passed through to the OS verbatim. There may be some very specific exceptions to that, but that's the general principle. > You can probably (hopefully?) figure out yourself why this is a bad idea. I've not seen this after 42 years of coding, sorry. > Having an additional redundant layer is not a bug, It can easily turn into a bug where second-guessing the user's OS turns into some kind of hindrance where they are not able to do something they should be able to do. It's a waste of time coding it. It erodes consistency. One program in one language/runtime restricts things one way; another one has a slightly different idea. > Sanitizing your inputs early and knowing why things failed is a good things. You don't seem to have a fully developed intuition for when this concept applies. > unless you want them to give you filenames like /root/.ssh/authorized_keys I've never seen an application that actually has a list of banned filenames like /root/.ssh/authorized_keys and checks every user input against it. It's a complete nonstarter. If the user wants to tell a program to overwrite /root/.ssh/authorized_keys, the program should just do it. If the user is not root, that path should not be accessible. If the user is root, it may be allowed to overwrite it even if it has no write permissions. The system security model and configuration has decide that; it's not the application's business to second-guess that policy.