• EN
Question

Is there a way to restrict access to python os module in FME Flow?

  • 18 April 2024
  • 6 replies
  • 50 views
krlem
Rank
Badge +3

As we all know, FME supports use of Python in workbenches, either via PythonCaller, scripted parameters, etc. The risk I see though is, that unexperienced user or malicious insider could potentially run Python code with access to Operating System commands (os.system for example) and create some damages (delete shared data folder contents, remove some files or corrupt Engine host, map external drives and copy data there, etc., you name it).

What are the best practices to restrict access to this type of Python modules? Is there any built-in functionality in FME Flow that could help to address this security concern?

6 replies

jkr_wrk
Rank
Userlevel 4
Badge +18

FME itself can also remove shared data folder contents, remove files etc.

Maybe you could restrict the rights of the user running FME to not be able to remove critical files/folders?

I guess you could PIP uninstall some modules but I think this will do more damage then you expect. For example installing the AutodeskDocs transformer will use Python to install some capabilities, and without for example the OS module it could fail to install.

You could talk to users using FME and explain using Python requires knowing Python and check .fmw files for existence of PythonCallers.

I think FME itself is capable of destroying a lot even without Python so the danger is between seat and screen.

 

 

@ReplaceString(@Value(Verpakking),"Frites","Patat",caseSensitive=False)
krlem
Rank
Badge +3

Right, that’s the point. It’s not about FME as such, but as I said it’s about “unexperienced user or malicious insider”. I just see a grey zone here - it’s OK to grant user access to Flow as Publisher, it’s not OK to allow OS level actions. I hope you see my point of view here.

liamfez
Rank
Userlevel 4
Badge +13

As far as best practices go, my opinion is that it would be best to work with and train an inexperienced user before granting them publisher access. For malicious activity, procedures could be set in place to review the workspaces being created and published to Flow along with their log files.

krlem
Rank
Badge +3

As far as best practices go, my opinion is that it would be best to work with and train an inexperienced user before granting them publisher access. For malicious activity, procedures could be set in place to review the workspaces being created and published to Flow along with their log files.

 

Fully agree, have it in place already. What’s more, ‘my’ users can publish to PreProd only and then automation pushes it to Prod after validation. But this is just a workaround. QC part also requires resources, especially when there are quite a few active users and/or multiple “top priority’ projects.

What about FME Flow itself? Is anyone aware of option to limit use of Python modules or perhaps whitelist some of them? 

jkr_wrk
Rank
Userlevel 4
Badge +18

You should restrict the user that runs FME Flow write access to folder that you are dangerous to change. For example the FileCopy writer can remove every folder if you move all folders and subfolders from C:\ to the VOID.

Again, it is not Python.OS module that is dangerous. And a lot of Transformers within FME use Python. So restricting Python.OS will result in for example writing to FileGeodatabase.

But if you want you could set FME Flow to a custom Python folder and remove the default Python folder that have the ArcPy module installed. And within the custom Python folder you could uninstall all modules you think are unsafe.

@ReplaceString(@Value(Verpakking),"Frites","Patat",caseSensitive=False)
virtualcitymatt
Rank
Userlevel 4
Badge +26

Not to mention the SystemCaller which can just run anything that the user running the Engine Service can run. 

I often use the os module in my work. Quite often it’s to just get environment variables, but if a customer blocked the os module then they wouldn’t be able to run quite a few of our workspaces. 

Another security concern (which I don’t think is an issue yet) is that with packages they will likely need to expose the web connections and database connections via python. As it is right now I don’t think it’s possible to use web connections or a database connection via python. This might change down the line, at that point extra care will need to be taken to protect credentials

Reply


Community Stats

28,790
Posts
109,755
Replies
36,614
Members
Terms & ConditionsCookie settings
A product of
Safe Software respectfully acknowledges that we live, learn and work on the traditional and unceded territories of the Kwantlen, Katzie, and Semiahmoo First Nations.