Unsecure: secret key is world-readable + service runs as root + no hardening

[tobiasBora]

Thanks for this package, unfortunately it is not secure since the secretKey option will be written in the public folder /nix, hence any user can read this file. Nix deals with secrets by providing options like secretKeyPath instead to provide a path (outside of the nix store) containing the secrets, and files can either be manually created or via tools like sops-nix.

[heihutu]

Thanks for the feedback. We look forward to the release of a new version that will support reading keys and secrets from files.

rustfs/rustfs#1814

[tobiasBora]

Cool, thanks. Just, note that this is not mandatory: you can define environment variables via a file as well using EnvironmentFile, this is for instance done by minio https://github.com/NixOS/nixpkgs/blob/e764fc9a405871f1f6ca3d1394fb422e0a0c3951/nixos/modules/services/web-servers/minio.nix#L130-L136

[tobiasBora]

Also, on top of my previous comment, in term of security (and its solution), I see more (important!) issues that you will certainly be asked to fix if you want to upstream it:

• for now the service runs as root (!?! really dangerous if minio gets corrupted !!): instead a proper rustfs user should be created, or, even better, a dynamic user via DynamicUser = true; to really put the user in a jail that removes everything but its internal state at the end using {State,Logs,Cache}Directory for persistent data as explained in https://0pointer.net/blog/dynamic-users-with-systemd.html (the main restriction of DynamicUser is that you can't really write anywhere but in /run/<package>, /var/lib/<package>, /var/cache/<package>, /var/log/<package>, /var/tmp, /tmp, /dev/shm as explained in the above link, see the section "What does this mean for you as a packager?" for additional hints on when DynamicUser is a good idea, it seems to be good enough for rustfs). Using DynamicUser, you can also get rid of the tmpfiles.rules lines. This idea is followed for instance by the Garage (minio-like service) as seen in https://github.com/NixOS/nixpkgs/blob/nixos-25.11/nixos/modules/services/web-servers/garage.nix
• I will also certainly be asked to provide more hardening for the service, for instance minio does a bunch of these in https://github.com/NixOS/nixpkgs/blob/e764fc9a405871f1f6ca3d1394fb422e0a0c3951/nixos/modules/services/web-servers/minio.nix#L138-L174 you should check what fits your need better. A good tool to check how "secure" your jail is is to run systemd-analyze security yourservice.service to list all properties that can be further restricted, and it gives you an overall exposure score based on how good you are.

Also, instead of writing EnvironmentFile as you do for now, you should rather use EnvironmentFile for user-defined secret environments (written by the user), and use instead Environment for non-secret environment variables, it also simplify the code as you don't need to create this file yourself (see e.g. https://github.com/NixOS/nixpkgs/blob/e764fc9a405871f1f6ca3d1394fb422e0a0c3951/nixos/modules/services/web-servers/minio.nix#L176C11-L180)

[houseme]

@tobiasBora The new version has been released. Can these optimizations be modified based on the new version? Thank you!

[tobiasBora]

What do you mean? These (strong) recommendations are always true irrespective of the software.

[houseme]

What do you mean? These (strong) recommendations are always true irrespective of the software.

Our new version supports assigning access_key and secret_key via files. Is this helpful for the security issue you mentioned? If not, we welcome you and community friends to improve and refine security-related issues. Thank you!

[tobiasBora]

Well if you want you can indeed use access_key and secret_key to fix this security issue and it might be a bit simpler and cleaner. But it was anyway already possible to fix it with previous versions using EnvironmentFile for secret data and Environment for public data.

[houseme]

Yes, if there were security hazards in the past, then we are now actively improving it, and we recommend that users upgrade to the new version to use it. Welcome community friends to optimize and improve the project!

[tobiasBora]

Good to know. Out of curiosity, what's the current status regarding security now? The AGENTS.md file suggests that some AI are working on this project, and that can be a bit worrying when it comes to security given that AI often writes insecure code, and this issue also shows that the project might still not follow good security practices. So curious to know: how was AI used in this project? I can see that "RustFS was ported from MinIO's Go code to Rust.", was it done via AI-stuff? What was done to avoid security issues?

I also do see that some independently written tests (ceph/s3-tests) are being used (good!) and that these tests also run security-tests. What's the current status, do you pass them all? Notably, I see in https://github.com/rustfs/rustfs/blob/a6090b98dc7511811ca4ba987d54160ad8235b65/scripts/s3-tests/run.sh#L171-L184 that you ignore whole sets of tests, like all tests starting with test_bucket_acl:

        EXCLUDED_TESTS=(
            "test_post_object"
            "test_bucket_list_objects_anonymous"
            "test_bucket_listv2_objects_anonymous"
            "test_bucket_concurrent_set_canned_acl"
            "test_bucket_acl"
            "test_object_acl"
            "test_access_bucket"
            "test_100_continue"
            "test_cors"
            "test_object_raw"
            "test_versioning"
            "test_versioned"
        )

Does it mean that e.g. all ACL-related tests are still not working properly (i.e. could lead to security issues)?