3 ms·

How is it hopelessly elitist to call out insecure code as being INSECURE!!! My whole point is the same as yours fix it at the source. You seem to think hacking

by rob_c 4y ago

How is it hopelessly elitist to call out insecure code as being INSECURE!!! My whole point is the same as yours fix it at the source. You seem to think hacking off the hands of some coders is safer (I may agree). But why not try to EDUCATE THEM?!? Education costs 1000s of dollars at most rather than your hypothetical billion dollar APPLICATION LEVEL hack. Why are you so elitist to assume people can't cope with these concepts? My whole point is that they need to be tought they're running on a Unix server rather than an 1998 SD card. The rest of your complaining is either you don't understand this or are trying to excuse bad or insecure practice as acceptable. If this is your case. RUN THE CODE IN AN ENVIRONMENT WHERE THIS CAN'T HAPPEN. Seriously there are filesystems and options for this. Calling for these features to be removed from extX, ZFS or other shows you don't understand storage technologies well enough.

com2kid 4y ago
> How is it hopelessly elitist to call out insecure code as being INSECURE!!! If a lot of code, written by a lot of different engineers, all ends up being insecure, it is worth asking, why is code dealing with this particular domain so often insecure? > But why not try to EDUCATE THEM?!? You can do that, and of course we should, but here is the thing about security: The good guys have to write secure code every time, or else the attackers guys win. Eternal vigilance is inhumanly hard to maintain. A better solution is to write higher level APIs or API wrappers that don't have these flaws. > Why are you so elitist to assume people can't cope with these concepts? Sure they can, but how many concepts can people cope with at once? Humans have a limit for how much they can juggle in their head. A huge part of software engineering is picking what abstraction layer to operate at. If I am writing code that deals with tons of string parsing and manipulation, I'd be a fool to write it in C or C++. Now I've done that when I needed the performance, but managing a massive number of strings in native code is easily 5x the work compared to using a GC language that also automatically tracks string length. C is the wrong abstraction there. And indeed an obscene number of security holes have historically centered around string processing in C. That is because on top of managing all the business logic (which may be obscenely complicated by itself!) engineers now have to do so in a language that is really bad at dealing with strings and they have to do a lot of mental work to ensure the code is correct. If I am manually flipping bits in hardware, well, JS can do it (I have seen it!) but honestly, that shouldn't be anyone's language of choice for directly interfacing with hardware. (Doing that in C, really fun!) > Calling for these features to be removed from extX, ZFS or other shows you don't understand storage technologies well enough. I am not saying that. I am saying that the original POSIX APIs make writing secure code around symlinks hard, and I am saying that solely based on the fact that a bunch of security holes around POSIX APIs and symlinks exist! This isn't some shocking statement. The original POSIX APIs make a lot of things hard.
- rob_c 4y ago
  People being educated for a specialist job, I wonder how they will cope. Well we hire in enough others for less serious problems, sure why not hire less than competent people to slap a fixed badge on the side of it. If you want this level of abstraction it should be built into the framework or language you're using. I'm not saying go away and rewrite chrome in C you'd be chasing segfaults for 5 years. If you want to hire people who don't care again. Run this in an environment where this doesn't matter. If you're ultra paranoid insist in a layer to compensate for people's failings. Again there is nothing wrong with the tried and tested API that can't be fixed with a modicum of effort. Calling it broken or insisting it change to fit problems caused by people so far removed they don't know what architecture they're working code for is not a reason to change the POSIX system. It's a reason to fix your abstraction.
  - com2kid 4y ago
    I think we're arguing the same thing. Write an abstraction on top of the hard to use API for the majority to use, and people who need to use the low level API directly can learn to do so.
    - rob_c 4y ago
      Strange how we end up here after calling me elitist... Please remember this for next time you interact with someone.
      - com2kid 4y ago
        You started off by insulting people who write code that has security holes. I started off by saying the solution is to make APIs that make writing security holes harder. You characterized people who write code with security holes as "stupid/lazy", that is elitism. About ~10 years ago, a lot of databases used to ship with no PW on by default. This lead to a lot of information disclosures as people new to the cloud based world setup a DB and all of a sudden it was world readable with no authentication needed. When this happened, a bunch of experienced DBAs started saying the problem was mass incompetence on the part of these "young developers who think they know how to be a DBA." Their proposed solution was for companies to start hiring "real DBAs". The actual solution was to have databases not allow exposure over a public IP unless a password is set, which is now the default on the vast majority of databases, and when it isn't, there are giant warning banners that flash everywhere alerting developers to the giant security hole they are about to deploy. I'm not saying elitism is always bad. Those DBAs who understand exactly how query optimizers work and exactly how databases store everything under the hood are needed, just as the developers who know the detailed ins and outs and proper usage of low level operating system APIs are needed. But if a lot of otherwise capable developers keep making the same mistake using some tool or API or cloud service, instead of trying to assign blame to individuals for being stupid or lazy, we as an industry should instead ask ourselves why so many people are having the exact same problem. I'm elitist about plenty of things, and it took me time to realize that just because I know the "best" or "correct" way for something to be done, doesn't mean that everyone else needs to do that thing in the "best" way. Anything in this world meant for usage by a large number of people, a product, API, flat packed furniture, setting up a printer, needs to cater to the needs of the job that people want to get done. Saying people are "doing it wrong", well, at best that approach gets companies put out of business (see: Everyone selling smartphones who wasn't Apple/Google), and at worst the harm can be magnified many fold.

by rob_c 4y ago

com2kid 4y ago

> How is it hopelessly elitist to call out insecure code as being INSECURE!!! If a lot of code, written by a lot of different engineers, all ends up being insecure, it is worth asking, why is code dealing with this particular domain so often insecure? > But why not try to EDUCATE THEM?!? You can do that, and of course we should, but here is the thing about security: The good guys have to write secure code every time, or else the attackers guys win. Eternal vigilance is inhumanly hard to maintain. A better solution is to write higher level APIs or API wrappers that don't have these flaws. > Why are you so elitist to assume people can't cope with these concepts? Sure they can, but how many concepts can people cope with at once? Humans have a limit for how much they can juggle in their head. A huge part of software engineering is picking what abstraction layer to operate at. If I am writing code that deals with tons of string parsing and manipulation, I'd be a fool to write it in C or C++. Now I've done that when I needed the performance, but managing a massive number of strings in native code is easily 5x the work compared to using a GC language that also automatically tracks string length. C is the wrong abstraction there. And indeed an obscene number of security holes have historically centered around string processing in C. That is because on top of managing all the business logic (which may be obscenely complicated by itself!) engineers now have to do so in a language that is really bad at dealing with strings and they have to do a lot of mental work to ensure the code is correct. If I am manually flipping bits in hardware, well, JS can do it (I have seen it!) but honestly, that shouldn't be anyone's language of choice for directly interfacing with hardware. (Doing that in C, really fun!) > Calling for these features to be removed from extX, ZFS or other shows you don't understand storage technologies well enough. I am not saying that. I am saying that the original POSIX APIs make writing secure code around symlinks hard, and I am saying that solely based on the fact that a bunch of security holes around POSIX APIs and symlinks exist! This isn't some shocking statement. The original POSIX APIs make a lot of things hard.

rob_c 4y ago
People being educated for a specialist job, I wonder how they will cope. Well we hire in enough others for less serious problems, sure why not hire less than competent people to slap a fixed badge on the side of it. If you want this level of abstraction it should be built into the framework or language you're using. I'm not saying go away and rewrite chrome in C you'd be chasing segfaults for 5 years. If you want to hire people who don't care again. Run this in an environment where this doesn't matter. If you're ultra paranoid insist in a layer to compensate for people's failings. Again there is nothing wrong with the tried and tested API that can't be fixed with a modicum of effort. Calling it broken or insisting it change to fit problems caused by people so far removed they don't know what architecture they're working code for is not a reason to change the POSIX system. It's a reason to fix your abstraction.
- com2kid 4y ago
  I think we're arguing the same thing. Write an abstraction on top of the hard to use API for the majority to use, and people who need to use the low level API directly can learn to do so.
  - rob_c 4y ago
    Strange how we end up here after calling me elitist... Please remember this for next time you interact with someone.
    - com2kid 4y ago
      You started off by insulting people who write code that has security holes. I started off by saying the solution is to make APIs that make writing security holes harder. You characterized people who write code with security holes as "stupid/lazy", that is elitism. About ~10 years ago, a lot of databases used to ship with no PW on by default. This lead to a lot of information disclosures as people new to the cloud based world setup a DB and all of a sudden it was world readable with no authentication needed. When this happened, a bunch of experienced DBAs started saying the problem was mass incompetence on the part of these "young developers who think they know how to be a DBA." Their proposed solution was for companies to start hiring "real DBAs". The actual solution was to have databases not allow exposure over a public IP unless a password is set, which is now the default on the vast majority of databases, and when it isn't, there are giant warning banners that flash everywhere alerting developers to the giant security hole they are about to deploy. I'm not saying elitism is always bad. Those DBAs who understand exactly how query optimizers work and exactly how databases store everything under the hood are needed, just as the developers who know the detailed ins and outs and proper usage of low level operating system APIs are needed. But if a lot of otherwise capable developers keep making the same mistake using some tool or API or cloud service, instead of trying to assign blame to individuals for being stupid or lazy, we as an industry should instead ask ourselves why so many people are having the exact same problem. I'm elitist about plenty of things, and it took me time to realize that just because I know the "best" or "correct" way for something to be done, doesn't mean that everyone else needs to do that thing in the "best" way. Anything in this world meant for usage by a large number of people, a product, API, flat packed furniture, setting up a printer, needs to cater to the needs of the job that people want to get done. Saying people are "doing it wrong", well, at best that approach gets companies put out of business (see: Everyone selling smartphones who wasn't Apple/Google), and at worst the harm can be magnified many fold.