VLA creates world-writable files under /tmp/veeam

[ned]

We have a security issue with VLA creating world-writable (cache) files under the /tmp/veeam directory. The /tmp/veeam directory is also created wide-open (777), but I've changed the directory permissions to lock it down. Our security team is scanning servers and reporting on these files. I lock the files down. The permissions get reset (back to world-writable) with the next backup.

How are other users dealing with this security issue?

When will this issue be resolved?

Case #04431941
Security Issue - world writable dirs and files in /tmp/veeam
VBR 10A, VLA 4.0.1.2365
RHEL 7-8, Azure

Thanks, Ned

[HannesK]

Hello,
can you maybe tell us a little bit more about your configuration? Because I cannot confirm your observations. I get 755 permissions on /tmp/veeam

Are you running "managed by server" jobs? File based backup or snapshot based backup?

How are other users dealing with this security issue?

can you maybe explain the security issue? /tmp/ is writeable for everyone per default as far as I remember... so I don't get the point when a subfolder is writeable for everyone.

Would a different path help you?

Best regards,
Hannes

[ned]

Managed by VBR 10A.

The /tmp/veeam directory ("veeam") is created 777 by the installer and the (VLA cache) files under /tmp/veeam are created (by backups) world-writable. Veeam support has webex'ed several times and confirmed this.

Our security team is scanning the servers daily and reporting these issues to the project team. I was forced to remove VLA from all our Azure VMs and now have to use Microsoft's native Azure Backup service.

I'm trying to understand how other users are dealing with this issue and when Veeam development will address this. Veeam support is supposed to create a change request, but stated "no promises."

See the case for notes and attachments showing the dir/file listings.

Case #04431941
Security Issue - world writable dirs and files in /tmp/veeam
VBR 10A, VLA 4.0.1.2365
RHEL 7-8, Azure

[PTide]

Hi @ned,

That's already fixed in VBR v11. You can check that if you grab the most recent BETA2 build (contact your sales rep. in order to obtain the build)

Thanks!

[HannesK]

I'm trying to understand how other users are dealing with this issue

and I'm trying to understand why 777 on /tmp is no problem, but 777 on /tmp/veeam is a problem I assume that some customers would ignore it in the same way like I do.

Ok, when I re-install the agent, then I also see 777.

I also agree, that 777 is no good practice and it's good to see, that we fixed it in V11. I just would like to understand the background of that security issue.

[ned]

Our security team/policy does not allow world-writable dirs/files. They scan the servers. It's that simple. I did not even know about it until they reported the issue to our project team. I had to remove VLA from our servers.

Just curious how other customers/users are dealing with the issue.