Hope this is the right section.
I'm the furthest thing imagine from a security specialist, but I'd like to be able to speak with at least a modicum of authority on the security consequences of rclone. If someone does a security audit, what will they need to know?
Thanks so much
Joe
Thank god man, because at the end of the day they cant do a damn thing to solve any issue.. if you ever wanna be a specialist be a backup and restore specialist like me or a IT Guru like Mr. Jojo @asdffdsa but not ever try to attempt being a security specialist. Good Lord.
Great day ahead man 
Daniel
I look at it from two primary perspectives: what can they do, and what does it expose?
So; rclone doesn't really let you do anything more than what you already can (e.g. using the OneDrive app). It uses the same APIs as any other software (eg OneDrive, google drive, sftp, S3 etc) with the same permissions as the user. It can't grant more access then you already have. So if your enterprise allows for local syncing of data to the endpoint then rclone doesn't do more. If your endpoint is properly protected (eg drive encryption, strong authentication, etc) then your data isn't exposed more than it was.
EXCEPT...
The credentials used on rclone can be copied. So if you allowed someone to access their corporate onedrive or sharepoint or google drive or dropbox from their corporate device (of course authentication is locked down so you can only get the initial config set up on that corporate device) the resulting rclone.conf file can be copied to an untrusted machine and now all the data that the user can see could be exfiltrated.
This opens you to insider attack (a rogue employee who wants to steal data, eg 'cos they're about to leave) or to malware stealing the config file.
What that risk is will depend on what data you handle and how sensitive it is and what it's worth.
The risk may be mitigated by having short lived access tokens and requiring the refresh token to only work from corporate devices (eg using Microsoft conditional access policies; dunno if google have the same).
It's common, in Enterprises, to disallow third party software like rclone from accessing SaaS resources (onedrive, etc).
rclone accessing internal resources (eg sftp to a local server) doesn't really change things internally; if an untrusted device gets the config file they shouldn't be able to see the server, anyway! That's why I focused on SaaS offerings as the bigger risk.
(Disclaimer: I used to work for the US's largest credit card processor; they had sensitive data on pretty much everyone in the US and large parts outside of it. We cared very much about keeping this data secure. Only limited 3rd party access was allowed to SaaS offerings; rclone was not an approved tool.)
Let me start by saying this is internet advice and a proper contact inside the enterprise with knowledge of the particular implementation and knowledge of the internal procedures and security policies needs to be involved. The ISSO/ IT Security Officer is the only one that can really provide an answer.
Now, based on my personal opinion, it really depends on your enterprise policies and the flow you are trying to cover with rclone and how it's implemented.
On top of my mind, proper file permissions for rclone.conf, log retention for file transfer validation, disaster recovery access etc. would be the bare minimum.
I would steer away from anything that can be accomplished by a tool included by the OS like ftp, sftp, scp, etc. Just use that one and avoid the questions on why you went with another tool.
Whatever architect is working on the implementation would need to involve the security liaison involved to get approval of using the application. Any vulnerability scanning would also need to be monitored, patch accordingly and assess if the vulnerability impacts your implementation and use case.
I would doubt you can get approval for crypt as enterprises usually prefer using off the shelf encryption solutions to minimize liability.
While I'm confident rclone would have no issues passing a general audit, I would not even think on using it for anything that might be considered PCI or SOX relevant as the external auditors can start asking too much documentation that might not exist.
But for a basic security audit, just proper permission to limit use of the binary and configuration file to the required UID and other security measures, proper documentation for change management on any release update or configuration should be enough.
Please note this would only cover the use of rclone, from a security audit it would also need to cover the remote you are using, how is that access controlled, password management, auditing of access of the data outside of rclone, etc. Which might be more work than actually the use of the application.
I mean, sure you can copy the config. But if you don't know the PW that's basically useless, no?
Even open source?
I don't think their job is to solve issues? I think their job is to prevent issues?
The password = and password2 = entries in the config file are the effective passwords. That's all you need to decrypt the remote files. You don't need to know the original password that generated those entries.
Especially opensource!
My father did 30 years in corp IT. I paid as little attention as I could, but my general impression was that the opposite was the case.
TMYK...
I think we might be referring to different things. I'm talking about the password it asks for before connecting to any remote if you configure it to ask for a password. Are you really saying it's stored in plaintext?
If the config file has been encrypted and if the password isn't stored somewhere (e.g. in a script for automation purposes) then it's safe.
If rclone is being used for automation purposes then it's less likely to be encrypted, or there's a wrapper script that holds the password so it can be used "hands off".
From a security perspective we can't force the config file to be encrypted (it's purely client side configuration) so we have to assume it isn't when evaluating it for enterprise use.
It'll depend on the industry and the sensitivity of the data. In banking and payments (where I spent the last 25 years) we care a lot, and we're getting stricter by the day.
For example, we don't even want developers going direct to sites like github or PyPi or maven or... Instead we mirror these sites internally and run automated code scanners and evaluation. If we find critical vulns or if the license isn't approved by legal or some other red flags (we saw one component pushing Russian propaganda; not what we want in a banking app!) then that component or version of a component gets blocked and can't be used by teams.
In this way we can try and prevent bad opensource from entering our applications, and we can track what is being used (so when a new vuln is found we know what apps are using that component and need remediating).
Similarly we don't like untrusted binaries being brought into our ecosystem because we don't know what it might do with our data.
Direct internet access is blocked; you have to go via proxies which can help to enforce these rules.
So, yeah; all use of opensource has to be done in a controlled monitored manner.
Yeah man but at least in my 27 year old career in this business i can tell you that i havent seen a Security specialist being sucessfull in either one of those scenarios.
Its just a humble opinion man , what can I say 
A storage specialist like ncw perhaps or a IT Guru like Mr. Jojo would be a better life-choice , that and in the long run getting married is also fun .
" we mirror these sites internally and run automated code scanners and evaluation."
Jesus fuck.
But even at that, why would you need an internal mirror? Why can't you just scan the remote?
Because we want a consistent available validated copy of the code on servers we own. So if the remote service had an outage our developers could still build; if the remote service was compromised we still have a good copy; if the remote service took down a package we still have a copy. And it means we can ensure only approved code is used ("v 1.2.3 has a critical vuln; we won't allow that to be used; v 1.2.4 is good, we'll let people use that").
Consider, for example, leftpad - How one programmer broke the internet by deleting a tiny piece of code
Yeah I vaguely remember this nonsense.
L'enfer, c'est les autres.
Not really, if I get a copy of a rclone.conf I can use rclone to read the remotes with no additional authentication. Maybe their SaaS has some IP range validation, but otherwise there's no extra protection, hence the importance of keeping the file safe with proper permissions. Even getting the client ID approved for SaaS usage would be an approval nightmare.
Even encryption might not save you if you able to have access to the job exposing the password. It also generates all the headaches on password requirements, rotation etc.
Trying to use any kind of software opensource or not in Enterprise is a headache, it's actually easier to go with a solution you can buy and get support from. Hence why rclone.com was born. It's not the problem with it being opensource, is they need somebody they can scream and blame when things go wrong and have them commit to fix and bring them back under an SLA.
Big enterprises sometimes even force closed source applications to commit on sharing the source code with them if they discontinue the product during their contract term. So they can take over the maintenance and keep using it.
Like @sweh mentions, anything related to finantial data brings even more headaches. They usually scan for vulnerabilities and pay for regular pen test efforts.
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.