I hoped to get your opinion or a recommendation, so i just drafted potential conclusions here. I will not be able to validate and quantify the risk of a manipulated script. So I’m rather thinking about reducing the risk as far as I’m able to from a pure operator perspective.
- You’re placing all your hopes for survival of decentralized ecosystem on to centralised IOG github accounts, and flagging not-so-rocket-science bash scripts as github-accounts-could-be-sacrificed. You cant debate if that’s your basis of thought process since your outcome is pre-decided. I cannot and do no want to make you believe something else. A sacrificed script could update your hosts entries, but a binary compiled with similar web source wouldnt.
- You’re adding option docker to the mix which is even less secure as chroot kernel is shared with host (even if using IOG version), and by your assumptions, point b and c of conclusion are almost similar.
- Your thread started by talking about block validations , then focused on scripts - then assume 50% nodes are sacrificed - and not one member reads the code + this 50% excludes IOG and exchanges, github accounts of selective members are hacked…OR those with 4 years of reputation suddenly go rogue (but at same time, not apply to the trusted bias).
So no - I am not really gonna be able to really provide any further answers as bias is prebuilt and I feel like having been stuck by lightening 5 times a day, yes - that’s possible 
A post was split to a new topic: Improvement suggestions for guild operators scripts
I’m sorry if this all seems to be just random switches between different topics.
For me it is a sequence of things that would allow a successful 51% attack.
Central managed Script > used in a majurity of nodes (not by number but by stake) > manipulates the source of a node or alter the source for installing the next update to, e.g. compromising the block validation logic
The chance for this to happen is propably extremely low if all code which goes into the tools comes from or is reviewed by trusted members. And the effort of one to run such an attack would be very high and any attempt would propably be detected.
Still what @tomdx recommends sounds very valid to me.
Besides of that I think monitoring unwanted configuration (System and Cardano Config) changes sounds important to me just as a precaution.
1 Like
Hi Zwirny,
I understand all your concerns and I appreciated you took some time to ask the community what are their thoughts about it, and since I am part of the community, besides being a professional Cyber Security consultant, I feel I can share my view on the topics you raised.
First of all you stated the bitcoin has been proven secure, in that regards I would like you to look at the following link that exposed some bitcoin public vulnerabilities.(Common Vulnerabilities and Exposures - Bitcoin Wiki)
IT Security is composed by several layers all with their own Life Cycle Management:
- Human Layer
- Perimeter Layer
- Network Layer
- Endpoint Layer
- Application Layer
- Data Layer
- Mission Critical Assets
All those layers needs to be taken into account when you build and/or own a piece of IT software/infrastructure. Taking into consideration only a portion of it will expose your operation, since a chain is strong as is his weakest link.
Most people who don’t have a clear vision on the overall orchestration of all this parts often fall in a paranoid state due the confusion and the anxiety they feel.
About CNCLI, this is just a tool (a great tool for my point of view as well as gLiveView) but it is just a tool. History teaches as that a tool is as good as the person that is using it.
- Awareness is a very key component in security environment, thinking to use a tool advertised as safe does not imply that the tool will be used in a safe way. Every software, including BTC, has limitations from different point of view, is how you use it that makes the difference.
I know many security devices (also hardware like a lock) and software (including Encase used for forensic Investigations in legal court) that had or have all vulnerabilities. Nothing will make you safe, but at the same time a risk mitigation strategy will help you be safer.
About IOHK, I see them as a single of point of failure if they were the only one developing and debugging the Cardano software. Fortunately for them there is a good part of the community that helps them to debug the software they are releasing (and the Guild Operators have a big part of it).
I would like NOT have a centralized and closed code source like other company (aka Microsoft or Adobe) have… historically the products coming from those companies are the most prune to vulnerabilities, therefore NOT safer to use compared to other products which are Open Source. Thanks god opensource exist. 
Of course perfection does not exist and improvements are always possible, thats why is key to be aware of the limitations and plan a good risk mitigation strategy by orchestrating the tools you use in a very thoughtful way, depending on he context you are using it.
In a truly decentralized technology, like Cardano aims, I envision the community take ownership of the code as well as the overall security layers composing the ecosystem. Having them as a single point of truth is a rookie mistake from my professional point of view.
IOHK has done a great job for some aspects but at same time we are suffering from the lack of clarity and implementation of key parameters like k and a0 which are making the overall SPOs community weak and divided, by allowing SPO (like the one owning 1PCT) to exploit the network and delegators at their advantage.
While we as community have failed to raise the right amount of awareness to the delegators who are delegating to those nasty SPOs which are not really interested on the health of the network.
All that said, being paranoid is not security wise. Security is the overall orchestration of risk mitigation, and I guess we as community are doing our best. Unfortunately many actors in our community, many having public channels on YT, are only concentrated on the commercial side rather to the educational one.
What @tomdx made is nice and thoughtful but also his docker project is prune to vulnerabilities.
For instance I would suggest him to implement “–security-opt=no-new-privileges” in the run command of the docker image to reduce the attack surface (in this case lateral movements).
Once again the Guild Operators made a good effort to help docker users to be more aware and tighten up the docker security with this small linked section.
I hope I shared my thoughts in constructive way and maybe answered to some of your questions so you can help us sharing the knowledge.
5 Likes
@Redoracle Thanks for the above. You can track progress on “–security-opt=no-new-privileges” with #39. It will probably not make it into the 1.26.0-rev1 release, but is schedules for the next.
1 Like
my 2c here: the issue isn’t the code itself, which can be scrutinized by anyone, including IOHK devs, as it’s open source. the weakest link is the crates that can sneak some bad code. this happened with npm in the past, might just happen with crates.io / Rust. the attack surface is huge because there are 200+ dependencies at the moment.
about npm incident targeting Bitcoin / Bitcoin Cash electron npm Blog Archive: Details about the event-stream incident
2 Likes
Thanks for your really detailed opinion. Totally agree that awarness and thinkful usage of tools as well as precation and mitigation strategies for all layers are the key parts.
1 Like
Fair point. Not sure what could be a mitigation strategy for this? From an operator perspective for me still the intrusion detection is the main strategy to identify if some of the configurations is changed. Nor sure if a npm package would be able to do so? Besiders of that watching outgoing connections or limiting them to only known parties would be the the second possibility. Is this something you would consider as valid precautions, or is it already rather being paranoic?
Intrusion detection system (IDS) is not made for checking files changes, there are file integrity monitoring tools (like Tripwire) for that purpose. Also consider Intrusion prevention systems (IPS) to be considered for an overall security orchestration. Of course dependencies are to be considered when you build or use 3rd party software, that’s why there are version freeze techniques in order to avoid dynamic uncontrolled change on production env. While in test env you make sure the overall software is safe before rolling it out in production (publicly accessible)
usually, you need to check for the sha256 sum of the generated binary. but it needs a to be a deterministic / reproducible build so everyone gets the same result, always. if they don’t match, you can consider something has been tampered.
implementing every bit of code without dependencies is possible but not realistic, even less for a community project with one person behind it. primary goal would to reduce the number of dependencies (taking out really small crates or plugging specific bits of code), so it can be checked more easily than you would going through a tree dependency of thousands of subdependencies, the 200 is actually the immediate dependencies of the project, you’d need to see the full tree.
even bitcoin core has it’s dependencies, as big as it is, although tightly-controlled ones bitcoin/dependencies.md at master · bitcoin/bitcoin · GitHub
partly true, partly untrue.
Ye swe need to educate delegators more, and operating pultiple pools doesnt mean they dont care for network health. its just not as important as filling the bags. I have more issues with exchanges holding large amount as i have with early adopters that operate succesfully.
although i also prefer more decentralised stake accumulation.
If this is commonly agreed that this IS A CONCERN we should not take “ppl will do it any way” as an acceptable answer. It is in our hands to create a common culture of security, request any “common library” to set transparent governance and checks/balances, and to protect what IOHK has trusted in our hands.