world-writable (777/666) files in /tmp/

[catharsis71]

the presence of mode 777 and 666 directories and files in /tmp/ is causing my server to fail CIS auditing

Data in world-writable files can be modified by any user on the system. In almost all circumstances, files can be configured using a combination of user and group permissions to support whatever legitimate access is needed without the risk caused by world-writable files.

auditing reported 4 directories mode 777 and 12 files mode 666

     1724      4 drwxrwxrwx   3 asf      asf          4096 Apr 28 17:03 ./.dotnet
     1732      4 drwxrwxrwx   3 asf      asf          4096 Apr 28 17:03 ./.dotnet/shm
     1749      4 drwxrwxrwx   2 asf      asf          4096 Apr 28 17:03 ./.dotnet/shm/global
     1838      4 -rw-rw-rw-   1 asf      asf          4096 Apr 28 17:03 ./.dotnet/shm/global/ArchiSteamFarm-SingleInstance-7F2......
     1922      4 drwxrwxrwx   2 asf      asf          4096 Apr 28 17:03 ./ASF
     2062      0 -rwxrwxrwx   1 asf      asf             0 Apr 28 17:03 ./ASF/ArchiSteamFarm-RateLimitingSemaphore
     2137      0 -rwxrwxrwx   1 asf      asf             0 Apr 28 17:03 ./ASF/ArchiSteamFarm-ArchiWebHandler-SteamCommunityURL
     2110      0 -rwxrwxrwx   1 asf      asf             0 Apr 28 17:03 ./ASF/ArchiSteamFarm-ArchiWebHandler-SteamCheckoutURL
     1979      0 -rwxrwxrwx   1 asf      asf             0 Apr 28 17:03 ./ASF/ArchiSteamFarm-InventorySemaphore
     1946      0 -rwxrwxrwx   1 asf      asf             0 Apr 28 17:03 ./ASF/ArchiSteamFarm-ConfirmationsSemaphore
     8249      0 -rwxrwxrwx   1 asf      asf             0 Apr 28 17:03 ./ASF/ArchiSteamFarm-ArchiWebHandler-WebAPI
     2148      0 -rwxrwxrwx   1 asf      asf             0 Apr 28 17:03 ./ASF/ArchiSteamFarm-ArchiWebHandler-SteamHelpURL
     2151      0 -rwxrwxrwx   1 asf      asf             0 Apr 28 17:03 ./ASF/ArchiSteamFarm-ArchiWebHandler-SteamStoreURL
     2009      0 -rwxrwxrwx   1 asf      asf             0 Apr 28 17:03 ./ASF/ArchiSteamFarm-LoginRateLimitingSemaphore
     1955      0 -rwxrwxrwx   1 asf      asf             0 Apr 28 17:03 ./ASF/ArchiSteamFarm-GiftsSemaphore
     2050      0 -rwxrwxrwx   1 asf      asf             0 Apr 28 17:03 ./ASF/ArchiSteamFarm-LoginSemaphore

changing these to 770/660 while the program is running doesn't appear to impair the function of the program but the files are recreated whenever the program is restarted

please consider using 770/660 for these

[nolddor]

Hi @catharsis71 tell us about your set up, how do you installed ASF in your system?

[catharsis71]

I'm on Ubuntu 22.04 & I just downloaded and unpacked the ASF-linux-x64.zip some time last year, launching via systemd service; automatic updates are on so it updates and restarts as needed.

I've tested with the systemd PrivateTmp option both on and off. With the option off, the directories .dotnet and ASF are created directly under /tmp/, while with the option on, they are created inside a subdirectory (i.e. /tmp/systemd-private-c5f3e46ce3f74cae9d00b8a6d7c7f000-asf.service-5aMOMn/tmp/) but in both cases they come up when scanning for world-writable files

[JustArchi]

What you're explaining above is expected and normal behaviour.

ASF includes support for cross-process synchronization, as explained in https://github.com/JustArchiNET/ArchiSteamFarm/wiki/Management#multiple-instances

As part of that support, ASF explicitly requires world-writable files for synchronization, since only this way other ASF instances are capable of actually informing the main process that synchronization is needed, i.e. ASF can't do some rate-limited action right away. Therefore, this is not a mistake, but intended behaviour, and alternatives to it (such as using shared memory instead) are far more troublesome and risk even bigger security issues, even if not reported by your favourite auditing tool.

The only solution I see here is adding new ASF setting that would opt out of cross-process synchronization, changing the underlying cross-process semaphores into local counterparts. That's possible and it'd allow the temporary directory to not be created and have no world-writable files in it, however, that'd also mean that you're losing cross-process synchronization and you intentionally run a single ASF instance across your whole machine.

The more problematic part is actually single-instance mutex, those are under .dotnet folder you also found, and allow ASF to detect attempt of running another instance of the process for the same config directory. This one is very useful mechanism, from what I see also backed by very similar files-based concept, and this is not something I want to opt out of, which means that even if I considered implementing above, I'd need to resign from this too if I wanted to completely remove temporary files usage.

PrivateTmp will not solve this problem, as the files will be created as before, you'll only cause the two above mechanisms to not work properly.

I'm not sure if I want to make this configurable. On one hand, it'd be great to have a mechanism like that in ASF, since the temp files are not mandatory for operation if user knows what they're doing (not running more than 1 instance, especially for the same directory). On other hand, as a project maintainer I don't care about some "CIS auditing" tool finding those files, since they're world-writable intentionally, and world-writable temporary files fill purpose of exactly what we're doing here, so it's not a "mistake" or some other "problem" that third-party tool detects. So yes, "In almost all circumstances", this is the other circumstance.

As a side note, the files created under /tmp/ASF are not needed to be 777, 666 is sufficient, so I changed that, but this doesn't solve your problem of those files being other-writable.

What do you need that CIS auditing for?