How can I compile and run Fortran/C programs on a shared remote server without exposing my code to other root users?

Question

I have access to a big remote server via SSH and I'm a root user on that server. However, there are multiple other root users who also have access to this server. I want to run some Fortran/C programs on this server, but I'm concerned about keeping my code private.

Is there a way to execute my Fortran/C programs without revealing the source code to other users on the server? I'm looking for solutions that allow me to maintain confidentiality while still being able to run my programs

I have a method in mind for protecting my source code while compiling on the server, and I’d like your feedback on its effectiveness, potential risks, and any overlooked measures I should consider.

First, cross-compilation isn’t an option for my situation; I need to compile the source code directly on the server. My goal is to ensure that accessing my source code requires significant expertise, ideally making it take days or even months for an average user. The entire remote session, including compilation and execution, will take about 30 minutes. I’m willing to spend around 5 additional minutes to implement protective measures.

Before I begin, I want to take several precautions with my root access:

• Verify that my SSH connection is secure.
• Check for any suspicious processes or daemons running on the server.
• Confirm that secure boot has occurred.
• Disable all logging and console input/output to limit exposure.
• Verify the signatures of the compilers and libraries involved.

During the process, I plan to create a temporary folder in RAM, setting myself as the only owner. I’d like to know if it’s possible to receive alerts if someone attempts to access that folder. This will mitigate file system access risks from other root users. If someone is monitoring my activities undetected, I want to implement measures to make it more difficult for them.

For file transfers, I will use cryptographic encryption and a unique, hard-to-access password for decryption(@security_paranoid), piping the output directly to the compiler. After this, I want to run the compilation securely while minimizing risks, particularly regarding memory inspection (acknowledging that complete prevention is impossible). I assume that reverse engineering the object files and executable will take significant time, and I don't believe other root users are motivated enough to go through this process unless automated tools make it easy to reconstruct the source logic.

What Linux tools would you recommend to assist with these processes and precautions? Ideally, the only way to retrieve the program should be through hardware means rather than software.

Answer 1

Fundamentally, you can't. You can make it less convenient to read your source, but not in any way that amounts to more than inconvenience; you quite simply can't achieve this goal at all. An unrestricted root user owns the system, and can observe literally anything that any user on it can do (yes, including SSH traffic, console input, the working memory of the compiler, and so on). They could install drivers, modify binaries, debug processes, log keystrokes, network traffic, and SSH session keys, and more. If your source code ever touches a computer in plain text, it can be read by any root user on that computer if they're trying hard enough.

The only real option would be to take advantage of your root access to get in the first strike, in a sense. Reduce the privileges of everybody else, ensure the binaries are untampered-with and the others can't tamper with them, ensure the kernel is clean, and file permissions are as they should be, etc. Of course, everything you're interacting with could in theory be a simulation of the real system - maybe you SSHed into a container or VM and some adversary is watching everything you do right down to being able to inspect (and modify) register values if they want - unless you were the first person to access the server (which you can't prove you were) and took your first strike immediately (which I presume you didn't). Also, in addition to being basically futile, this would be a remarkably hostile action, and despite your assumption of hostility in your root-access peers, that doesn't seem to be the kind of suggestion you're looking for.

So - now that we've established impossibility - how far do you actually want to go to make this inconvenient? How much inconvenience to them is the inconvenience to you worth? How motivated do you expect them to be?

Your basic plan is fine if you neither expect them to be actively looking for your source code, nor logging all your SSH traffic already, and thus only care about not leaving it on the file system. (You could also achieve this by transferring the files normally and then overwriting and deleting them after compiling, or creating a temporary RAMdisk and putting the files there for compilation, but that creates a slightly wider window of vulnerability.)

With that said, unless this compilation task is enormously difficult and the only computers you have access to are complete potatoes by comparison to the server, cross-compilation seems much simpler and more secure (if all you care about is the source code) than attempting this sort of shenanigan. You could even do things like compiling the code only partway (e.g. to AST) locally, and then transferring the intermediate representation (which is certain easier to reverse engineer than an optimized binary, but not actual source code) to the server and completing compilation there; the compiler back-end is where all the platform-specific optimizations happen anyhow.

Or you could get a server that doesn't have adversaries-with-root-access on it. It's generally extremely unwise to do literally anything on a computer where there are adversaries with root privileges! There are many computers in the world that you could access instead, and most of them don't have this problem.

Answer 2

Compiling your code from the terminal directly into object (.o) files is a decent method, but the main problem I see with it is that while object files are harder to reverse engineer than source code, they can still be analysed through specific reverse engineering techniques.

So if other root user could manage this, they could inspect these files, even if they don’t have access to your original code.

But because you want to compile the program on the server, just as you suggested, encrypting the source code and then decrypting it with a password inside a bash script for compilation would work well.

Tools such as openssl can be used to encrypt your source code.