Feature Request: Ability to Submit a File to Assemblyline, Retaining Results but Discarding the Sample

[ociappara]

Feature Request: Ability to Submit a File to Assemblyline, Retaining Results but Discarding the Sample

[cccs-sgaron]

Ok this seems to me like a better way to approach the solution. We could create an API that deletes the file strait from the filestore, no questions asked, without removing up the file record. Which means that the file will be gone but the analysis will remain. This way you can orchestrate your own logic around this using the other APIs to know when to perfom that cleanup. This could even be done via webhooks using the post-processing actions.

This method does not enforce some complicated logic to be built into AL and let you do what you need. We will ensure that the UI handles missing files correctly and the processing does not hang forever when trying to process a missing file which I'm sure is already that way.

Also we can lock the API with RBAC so you can control who would get access to it.

[cccs-sgaron]

These are the PRs related to this change:

• CybercentreCanada/assemblyline-base#1425
• CybercentreCanada/assemblyline-ui#768
• CybercentreCanada/assemblyline-ui-frontend#869

[cccs-sgaron]

What would you do will all extracted sub-files? Delete them as well?

[ociappara]

We have both use cases, but the parent file being deleted would be a good first step towards this. Maybe a configurable option to determine if the extracted files are stored?

[ociappara]

This feature request is becoming more prevalent and is increasingly being brought up by various individuals, do you think its something that could be implemented? No worries if not, would need to figure out how to retain results outside of AL.

[cccs-sgaron]

There is no particular issue to delete files but keep only the analysis result in principle. The only problem is to determine if you can delete the files or not.

Imagine two user submitting the same file, one asking the system to delete it and the other asking the system to keep it. What would you do then? I don't think a user decision to delete the files after analysis should force remove the file for other if they didnt ask the same thing. Which then mean the for each file you are trying to delete, you have to scan through the system for every submission that may reference this file in any way and check if the file was meant for deletion or not. And while you are computing this decision, another user may request the same scan but now the file can disapear while his scan is not completed.

[ociappara]

So use cases for this are arising from automations, one solution could be that this is not something users could control at all, but rather admins will have the ability to call an API to carry out this job. The idea here is to allow us to clean up files that carry risk, but keep the analysis results. If a file is being processed and an API call to clear our the file is made, one of two things can happen. 1/ either queue the deletion of the file upon finishing results, or 2/ return an invalid request back to the API caller and we can handle this use case by retrying at a later time. I think generally, this feature is meant for Admins and not users. Happy to discuss further.

[ociappara]

That would work perfectly. Thank you!