Isolated bot instances

[JTinkers]

Feature request

IPC user accounts and bot/access isolation

Purpose

What I understand by 'isolation of bot instances' is: allowing different people access different bots through IPC (preferably only the ones they've created, so they can't just trade the entire inventory of bots of other users).

The purpose of this is simple - sharing the bot with friends (because sharing is caring), without them worrying that you can get onto their steam accounts or that other users can mess with their inventory.

Solution

• an implementation of user accounts for IPC.
• restriction of the list of bots to their bots only.
• automatic password encryption (so the VPS owner can't simply check the .json file)

Why currently available solutions are not sufficient?

There isn't a solution put in place. Right now if you share with friends - they have to trust that you won't look into their bot files to check the password out and they have to trust eachother that neither of them will setup the other bots to transfer the entire inventory to their bot.

Does your suggestion fall into ASF scope?

Definitely. It doesn't modify the core functionality - I would assume that you'd have to perhaps add 'UserId' field to the bots and restrict how frontend fetches them based on that. Plus you'd have to allow log-in by checking passwords of users rather than IPCPassword.

Is your suggestion abiding to Steam guidelines?

ASF abides the steam guidelines and ToS and this doesn't modify the core of it - it only changes how bot is accessed.

Additional info

None.

[Rudokhvist]

Without discussing the rest of suggestion,

automatic password encryption (so the VPS owner can't simply check the .json file)

This is pretty much impossible. In ASF can decrypt password - VPS owner can too, and vice versa, if VPS owner can't - ASF also can't. Only possible scenario where VPS owner can't easily decrypt it - is users providing their passwords (or encryption keys) upon ASF start, and ASF keeping it in memory, and not writing it to disk. Of course, that would not be convenient for users, but that's the only (more or less) safe way.

[JTinkers]

@Ryzhehvost Perhaps users could upload their steam keys or whatever the file storing their session is called?

I do understand how reduntant encrypting passwords with user key would be, considering VPS owner can get the key too - so perhaps utilizing steamauth would do more good.

[Abrynos]

A user named sansuiban already requested this feature on the discord server which resulted in a lengthy discussion between Archi and myself on how to (if ever) implement this. One thing I would like to quote here is the sentence

SteamOwnerID always has full access to ASF instance

This means that even if this was implemented, the user with configured SteamOwnerID could still just send a command like transfer ASF VPSOwner and it would be a totally valid use case.

ASF in its core is not inteded as a multi-user program. If you want to achieve this either your friends run ASF on their own PC (ASF does not HAVE to be online 24/7 tbh) [assuming they don't have a VPS of their own] or you start several instances of ASF, increase the limiter delays on all instances and configure IPC to use another port on each instance. This way all bots (yours and your friends) are hosted on your VPS and everyone only has access to their own accounts.

[Rudokhvist]

This way all bots (yours and your friends) are hosted on your VPS and everyone only has access to their own accounts.

Actually, even in this case VPS owner can get access to all your bots. You have to fully trust VPS owner, because he always will have possibility to get control over your bots. Even if you make super-protected ASF that asks your credentials on every start - it won't help, because VPS owner can just replace it with his own vulnerable version, and say "VPS got restarted, enter password again" and that's it.

[JTinkers]

@Ryzhehvost Well, that's true. I was more worried about other users messing with other bots rather than the owner. Obviously owner has unlimited power here.

[Abrynos]

Ryzhehvost is right of course. I made my suggestion under the assumption you only want to prohibit direct access.

[JTinkers]

Ryzhehvost is right of course. I made my suggestion under the assumption you only want to prohibit direct access.

So would this suggestion still fly, if it was only about other users (and not the owner) having reduced access? Doesn't matter if password is visible to him or not - because I think that would be helpful anyways.

[JustArchi]

Anybody with direct access to the server has full control over the process and every bot taking part in it, by definition, because the same guy also has access to memory of the process, which means that even if you follow @Ryzhehvost tip above and enter keys upon login, ASF would still need to keep them in memory for access, and there is no guarantee that the owner of the server won't just dump entire memory used by ASF and extract passwords from it, even if you do not save them anywhere. This is invalid suggestion on its own, because there is no known to me method of achieving that, and not just with ASF, but any other piece of software. You can't magically hide memory of the process from root.

And if you by any chance assume that owner of the server does not have root access and he can't gain it through any possible means (including kernel exploits), then you can as well prohibit him from reading ASF config directory by chmoding it 700 and he won't read passwords inside either, assuming he's running under different user and he has no access to ASF user as well. Moreover, Linux already guarantees in this case that he won't be able to read memory of processes not run by him as well, which would provide 100% guaranteed security, if done properly.

---

As of the rest of the issue, I still point out that the already-existing, possible and intended use case is to run multiple ASF instances on the same machine, each with different bots. This guarantees process-wide isolation and isn't prone to e.g. bugs in the code that would improperly filter off the request or responses. At the same time this is also a valid enhancement, because ASF is already capable of dealing with permissions, it's only a matter of enhancing the existing logic to provide different SteamID when executing with IPC.

However, I'm not so sure if this is the right way. Maybe the proper enhancement is to implement OS-wide semaphores for ASF, which would allow ASF instances to synchronize with each other, allowing stuff like LoginLimiterDelay to work across all of them. Then there would be not a single reason to avoid running multiple ASF instances and it'd improve also other use cases of running multiple instances.

There are a lot of ways to achieve your goal, but the most correct one in my opinion is to go with proper UNIX philosophy of user-isolation, which for 3 planned users would create 3 different OS users, start one ASF instance per each, and maintain the minimum amount of cross-process cooperation, in particular to ASF limiters with semaphores (which could also be further enhanced to take outgoing IP address in mind).

[JustArchi]

Another important argument adding another reason for going with multiple ASF instances are different global ASF settings, such as the fact that 1 out of 3 users would prefer going with UpdateChannel: 2, but the rest would want to keep stable releases. Same for other matters like statistics, farming periods and all other ASF.json contents. It's definitely out of the scope of ASF to provide user-wide ASF.json configs, and running multiple instances would make it as easy as it gets.

And other stuff as well: custom plugins, NLog.config, it's basically only advantages at this point, so much that it's getting really hard to convince me that any other way should be taken under consideration at all.

[Rudokhvist]

There are a lot of ways to achieve your goal, but the most correct one in my opinion is to go with proper UNIX philosophy of user-isolation, which for 3 planned users would create 3 different OS users, start one ASF instance per each

This seems better security-wise (since it's different processes), but what about memory and CPU resources? Wouldn't it bring too much overhead, to run multiple instances of ASF instead of just one?

[JustArchi]

.NET Core is trying its best to minimize the overhead. It already reuses mapped memory and structures of the runtime of different processes using the same runtime, so in the best case, the resources used would be only those that ASF directly allocates.

Sure, you could argue that running 3 IPC interfaces under 3 different ports is for sure going to take more than 1, but how much exactly? To the best of my knowledge, we're talking about maybe a dozen of MB here, ASF on my server uses 19.27 MB of its own memory right now, and I didn't restart it for weeks. Yes, process uses more, but process also has all those structures which will be shared as I mentioned above.

[JTinkers]

There's issue with the UNIX philosophy approach - my friends and most people don't have a tech background and wouldn't know how to connect via SSH, let alone set the bot up.

[JustArchi]

That's not a problem, you can prepare it for them, give them WinSCP or any other SFTP access and just tell to upload files in proper locations. There is nothing that one ASF instance would achieve that several would not, you can even prepare everything for them, launch IPC on 1234 and tell them to configure ASF via web interface.

[Rudokhvist]

There's issue with the UNIX philosophy approach - my friends and most people don't have a tech background and wouldn't know how to connect via SSH, let alone set the bot up.

That's not an issue. You can setup asf without bots but with IPC enabled, and the rest your friends can setup via ASF-ui. They don't even need file access for that.

[JTinkers]

Oh, yeah. And I could even use different ports for IPC.

[JustArchi]

Not could, but you'd have to. You can't bind multiple ASF instances to the same port. And for multiple ASF instances, it'd be best if they all had custom ports, to not give user the impression that the one under :1242 is the correct one.

[JTinkers]

I meant - if I gave them FTP access or for that matter uploaded their bot settings, they don't really need IPC.

edit: but yeah, then the suggestion about adding user accounts to IPC is obsolete.

[JustArchi]

Closed in favour of https://github.com/JustArchiNET/ArchiSteamFarm/issues/1798