I have the same paranoia when it comes to my shell runcom at work. I have an update function when the shell opens that takes a superuser password and does a bun

I have the same paranoia when it comes to my shell runcom at work. I have an update function when the shell opens that takes a superuser password and does a bunch of work-related stuff. The first line of defense is unaliasing sudo and calling sudo -k at the end of the function, but someone could probably just replace these lines with a sudo() function that has the same behavior, same output, and just tees my password into /tmp where it can be accessed later. Then, I added one of the popular Linux malware checkers that sees if any system binaries or user-specified files have been modified and run that silently during the update script. By virtue of the malware checker being popular, I would guess anyone skilled enough to be remotely accessing my shell would know what that program does and run the commands to update its configuration so all their changes look normal. Adding a layer of protection, I have a script in another runcom that---on a local shell---just compares md5sum of the malware checker and the other runcom and echoes a line to check those files if the checksum doesn't match. Again, someone can look at all the hidden files in $HOME and see this md5sum check exists. I'm not verifying this file every day, and I don't memorize the hashes, so I wouldn't even be able to verify this file the way it is written. There's probably a good way to guard against 99% of unauthorized access (e.g. non-state-level) like chmod 0400 .shellrc and manually running the update commands with the prefix disabling aliases (and also not leaving these commands in the command history either). On the one hand, this is so much trouble. I have no evidence that nefarious access to my computer has ever occurred. On the other hand, would I have evidence that access has occurred if my system isn't hardened better? ----- In my fantasy world, I'd have a non-erasable/non-bypassible physical device + Linux module that MUST be part of the communication path before a shell can be accessed. This could be a dual-pole relay where one pole physically connects the incoming traffic while the other pole rings a loud bell. An alternative would be a receipt printer that prints the login time, user, IP, etc. and then allows access to the shell. A dedicated attacker could then just replace my keyboard or peer through my window with a telescope from a nearby building or tape a small webcam in the corner of my window where I wouldn't notice. Or send an email from a close-but-not-exact address of a colleague and call with a raspy, obviously sick voice imitating said colleague, saying "hey, I'm doing home office today because I'm sick, can you log into the server room with the link I sent you, I'm on the other line with a customer. He's pretty pissed!" Day's end, the company needs to hire a person/team to ensure security if it's so important. I will try to do my part to keep company secrets within the company, but I'm not building the entire castle to protect my little workshop. (The other advantage is that I genuinely don't believe our competitors would benefit from having our source code, and our significant customers aren't likely to purchase knockoff products. Much more important? Protecting our business and customer data.) ----- Unless we're building ENIAC ourselves with spools of wire and magnets, building our own keyboard or input device, manually typing in the source for the compiler... (Even then, if you haven't drawn the wire yourself, can you really trust it hasn't been tampered with somehow??) You have to accept some degree of trust in the hardware, firmware, software, and meatware that you employ while accepting some degree of risk. ----- One aspect of this repo that bothers me is the raw file, Compiler. This file plus the theme of this project? There's no way I'm cloning and compiling this. I realize I can load this Mach-O executable into Ghidra and figure out if it has a broader purpose than "proof of concept", but then I'm trusting that Ghidra doesn't telemeter my data directly to a server in Fort Meade... See how stressful this zero trust model can be??