We have no security checks in GROMACS (4). Thus it is very likely that any malicious input files could easily execute code (1). I suspect we don't have the resources to make all input file reading secure (2). Unless we make input file reading secure, we should document for users the situation. So that users are aware that when they download input files (3), they need to trust input files to the same level as they require for executable files (such as shell scripts or binaries). The install-guide might be a good place to put a warning.
1) Any malicious code would run with with the same permissions as GROMACS. There are likely multiple possible attack methods. But simple buffer overflows with executable payload is the most likeliest.
2) It might be possible to make a subset of input file reading secure (e.g. just TPR reading)
3) If the generate input files themselves there is no issue. But if files are downloaded (e.g. for benchmarking, tutorial or parts for system setup) those need to be trusted.
4) We have no runtime tools (e.g. fuzzing) and we disable checks in e.g. msvc and clang-tidy.
Fix gcc-8 warnings about strings
A bunch of slightly risky string handling is now safer or simpler.
#4 Updated by Szilárd Páll over 2 years ago
Perhaps a better place to note than in CR where I mentioned it before: a practical security-related information that could be useful to admins as well as Linux distro security audits is a description of what the different GROMACS tools are expected to, what kind of behavior do the exhibit that can be relevant to security (or possibly also matching job to hardware_ needs.
For instance a brief description of how the various tools consume/use system resources (ports, pipes, files created/operated on, cores/hw threads used, pinning, etc.) may be beneficial.
#6 Updated by Szilárd Páll over 2 years ago
To be honest, I do not know of examples of what needs/is useful to be mentioned.
Perhaps it'd be best to draft something general and ask for feedback from i) some HPC admins ii) some Linux maintainers (we've been in contact with at least the Debian maintainer)?