91–100 of 104 posts
Earlier quoted context omitted.
cool! happy to hear that. if you have any ideas or comments about Kubescape, we would love to hear them
If you could check for container signing and providence on all materials and make sure that only a single registry is being used (ex only `internal.company.com:443`) and make sure it's not possible to schedule pods with unsigned/untrusted containers that would be awesome.
I feel like installing a security tool by curling a random script off the internet and piping it into `/bin/bash` is a bit contradictory. Surely there's a better way to install this?
I feel like installing a security tool by curling a random script off the internet and piping it into `/bin/bash` is a bit contradictory. Surely there's a better way to install this?
Well, this is for users who do not want to work hard:) If you wish, you can clone the project and build, other option- you can download the file from the release url. It should be pretty simple to understand from the install.sh script. Good luck :)
I feel like installing a security tool by curling a random script off the internet and piping it into `/bin/bash` is a bit contradictory. Surely there's a better way to install this?
Kubernetes is way too overengineered. It should be as simple as docker compose. and Kubernetes also added StatefulSets for things like database, but all kubernetes gurus don't recommend to use it in Cloud, but use databases provided by the cloud providers :facepalm because, well, it's too complicated...
Earlier quoted context omitted.
If you're smart enough to realize that there might be something to worry about, you should be smart enough to be able to figure out how to divide the command into three parts instead of one (download the script, inspect the contents and then run the same inspected [local] script). Every time a project with curl | sh is featured on HN this comes up. At this point we might as well write a bot that scrapes submitted pag…
> If you're smart enough to realize that there might be something to worry about, you should be smart enough to be able to figure out how to This is gatekeeping 101. Some people are just starting out in security/software engineering and things like this might not be obvious to them. It's good that you have suggested what to do but there are different ways to "suggest" things.
What? How?
> Some people are just starting out in security/software engineering and things like this might not be obvious to them
That's fair enough. But I wished these beginners then didn't make claims like "security tools cannot be installed like this, it's insecure", and we would all be better off.
Either you know what you're talking about and you share your knowledge. Or, you listen and ask questions in order to eventually know what you're talking about.
Earlier quoted context omitted.
> If you're smart enough to realize that there might be something to worry about, you should be smart enough to be able to figure out how to This is gatekeeping 101. Some people are just starting out in security/software engineering and things like this might not be obvious to them. It's good that you have suggested what to do but there are different ways to "suggest" things.
> This is gatekeeping 101 What? How? > Some people are just starting out in security/software engineering and things like this might not be obvious to them That's fair enough. But I wished these beginners then didn't make claims like "security tools cannot be installed like this, it's insecure", and we would all be better off. Either you know what you're talking about and you share your knowledge. Or, you listen and…
> What? How? In many hobby communities, whenever new people ask questions, which are obvious to the more experienced people, some more experienced people become hostile/use more hostile language/say things like "you should know this wtf" etc. A fairly recent example I saw on Reddit of what I mean https://www.reddit.com/r/AdeptusMechanicus/comments/h7s5gw/g...
> That's fair enough. But I wished these beginners then didn't make claims like "security tools cannot be installed like this, it's insecure", and we would all be better off.
I understand where you are coming from but this is an eternal struggle with any profession.
> Either you know what you're talking about and you share your knowledge. Or, you listen and ask questions in order to eventually know what you're talking about.
Yes and no, this is Dunning-Kruger effect quite often https://en.wikipedia.org/wiki/Dunning%E2%80%93Kruger_effect https://imgur.com/r/psychology/jbo2gy5
Earlier quoted context omitted.
Yes, it's exactly like that, but not in the way you think. One side is a small-but-vocal minority making silly arguments. "how to detect direct piping to bash in order to serve malware"? An attacker who tries to serve different things to different people will easily be caught, and a simple diff will highlight their exploit. A much more robust attack strategy is to serve the same malware to everyone but obfuscate it.…
> An attacker who tries to serve different things to different people will easily be caught Can be detected, and will be detected are quite different. I don't know of any scanning projects even attempting to detect such things.
Creating a subtle, plausibly-accidental bug and then exploiting it is much safer.
Earlier quoted context omitted.
Yes, it's exactly like that, but not in the way you think. One side is a small-but-vocal minority making silly arguments. "how to detect direct piping to bash in order to serve malware"? An attacker who tries to serve different things to different people will easily be caught, and a simple diff will highlight their exploit. A much more robust attack strategy is to serve the same malware to everyone but obfuscate it.…
The problem is, doing this for a specific project you really trust is not a problem. But what you’re actually teaching inexperienced programmers, that this is true in the general case. Would you run a one liner like this if I sent it to you and it was hosted on GitHub? The very intelligent people at Docker used to have this pattern at get.docker.io. They changed it. And to obfuscate the attack, I think typo squatting…
If anything, I think package managers create a false sense of security, especially ones that allow anyone to publish packages and declare dependencies on anything else. Installing an npm package -- even one from someone you trust -- could very easily transitively install something malicious. Debian packages are arguably better in that not just anyone can push packages to Debian's main package repo, but there's still a very real danger of a hidden backdoor. But I think a lot of people just assume installing from a package manager is not dangerous.
> The very intelligent people at Docker used to have this pattern at get.docker.io. They changed it.
Probably not for security reasons, though. There's a separate, very legitimate argument for distro packages, which is that they implicitly promise to play nicely with your distro's conventions and install themselves in a clean, manageable way. How to update or uninstall a distro package is well-defined. None of this is actually guaranteed, of course -- a package can do whatever it wants in an install hook. But assuming you trust the developer isn't malicious, then you can get some comfort knowing the package is unlikely to screw up your system.
curl|bash provides no such promise, even implicitly. Who the hell knows what it might decide to do. Maybe it has one of those `rm -rf $SOME_VAR_THAT_MIGHT_NOT_BE_DEFINED/*` bugs like Steam did at one point.
Sandstorm is careful to avoid messing up anything, installing itself to a self-contained directory, and providing an uninstall script. But the user doesn't really know that in advance.
The reason to use curl|bash in spite of this is because distro packaging is a lot of work (there are a lot of distros!) and may not be the best use of time for a small project. Docker is definitely big enough to do it, though.
So yeah, there's definitely a cleanliness argument. But the security argument is bogus.
Earlier quoted context omitted.
The problem is, doing this for a specific project you really trust is not a problem. But what you’re actually teaching inexperienced programmers, that this is true in the general case. Would you run a one liner like this if I sent it to you and it was hosted on GitHub? The very intelligent people at Docker used to have this pattern at get.docker.io. They changed it. And to obfuscate the attack, I think typo squatting…
I really don't think anyone is being taught anything misleading here. curl|bash makes very clear that it's running arbitrary code as you, and I think almost everyone who invokes it does in fact understand that. If anything, I think package managers create a false sense of security, especially ones that allow anyone to publish packages and declare dependencies on anything else. Installing an npm package -- even one fr…
It's still downloading and executing a script, just two steps instead of piping the output straight into bash.
You can't even inspect the code you run when you do curl|bash and the server is able to detect this distinction and hide code when you do a curl and then run bash.
https://www.idontplaydarts.com/2016/04/detecting-curl-pipe-b...
Your argument is: "we do it and we use GitHub, you can trust us and can trust GitHub, you don't need to verify the code you run."
And devs learn: "Trust me, you don't need to verify the code you run."