LabVIEW app runs with elevated permissions based on Company Name

[free_alias]

I just finished "solving" a problem our team recently experienced. I know what I need to change to manipulate the outcome but I'm curious why.

Our company has a LabVIEW 2020 developed application that basically accesses and edits files in a network folder and then distributes those updated files to various test equipment. This all worked great until IT started making security updates. What I learned was that the users on our team without admin rights had no problems, but the few of us with admin rights lost the ability to use the app because some IT policy would not allow an app running from an admin user's account to access the network files.

We have a similar app used easily distribute selected files that is developed within the same project. This app has no problems and also access files in the same locations. I learned that the difference was the other app shows as running with elevated privileges from the task manager, but this one did not. I looked through the code of the problematic vi to see if there might be anything that would elevate it, but didn't see anything that looked like it should do that. The vi would also run with no problems from the project. It was only the compiled executable. I compared vi properties and the build specifications and found nothing that was different that should cause the problem. Then I duplicated the build specification from the working app and changed it to build the vi for the problematic app. That worked! The app ran un-elevated and worked like it should. Then I began updating the other specific info (names, versions, descriptions, etc.) and tried another build and that started having problems again. I then started with another fresh duplicate of the working build specification and started changing one thing at a time until I came up with the Company Name field on the version information section. The working app was developed before our company changed ownership. The other app must have been developed later and whoever made it updated the info to match the new name. If the original company name is used in the version information, the resulting executable runs without elevation. If that is changed, the resulting executable runs elevated.

Can anyone explain why this is? Is there any way to fix this without having to keep the old company name in the build specs? Oddly enough, when the executable runs with elevated privileges, it does not trigger any UAC credential requirements. As such, no workarounds to run as invoker will work.

[GerdW · Accepted solution]

Hi alias,

---

@free_alias wrote:

Can anyone explain why this is?

---

Did you talk about that with your IT department? Maybe they implemented some rules…

[wiebe@CARYA]

Maybe there's a certificate linked to the company's name or something like that ("Always trust applications from...")...? I'd definitely look at Windows certificate store, but I'd be scared if I found the answer there. Unless the executables (the good one) was actually build with a certificate. I'm no security expert, but I'd think the company name shouldn't be a security credential.

[free_alias · Accepted solution]

I did a little more testing and it is most definitely some kind of rule where any app with the current company name runs elevated. I was assuming that it was something to do with the original company name making it work, but I tried adding a made-up name in the company name and even clearing out that field. Each time the apps ran like they were supposed to.

I do appreciate everyone's feedback.

[wiebe@CARYA]

I'm confused now.

Any app with the company name runs elevated.

But changing it and the apps work?

So the apps that don't run elevated work, and the problem with apps that have the current company name is that they have elevated rights?

It seems like a really bad idea to automatically give applications elevated rights based on something that's changed so easily.

[free_alias]

Yes it is all a bit confusing. It appears that apps with the current company name run elevated, however they do not trigger any UAC credentials. There is also some other rule in place that does not allow apps running with elevated rights under admin users' accounts to access network resources, so this is why the apps running elevated broke things for myself and a couple of other people.

I agree that automatically giving applications elevated rights based on something like this seems like a bad idea. IT is in the process of increasing security so that may get fixed at some point as well. They already closed our previous loophole which was to run the app from a command prompt that was running as admin.

[rolfk]

The fact that elevated apps can't access network resources is standard Windows security in any domain controlled setup. I believe it can be disabled under policies but never worked with that.