UAC just kicked me in the ass.

[SunnyD]

I just got done writing a 3 page document on why our application won't run UAC-enabled after thinking I had fixed most of the problems with a simple manifest addition.

The problem?

The fact that the application itself runs as a system service, an end user application and an end user administrator application. Yeah, one app, three modes. They all have to talk to each other, with certain interactions etc.

The end result after I really stopped to think about it, security. We have no way of knowing what kind of security methodology an end user/client is going to run. Is the general populace going to strictly run limited accounts? Are they going to have local admin? What rights are their user accounts going to have?

So... what was a couple months ago a pat on the back for making it apparently Vista-friendly... this last week turned into a nightmare after all of the apparent "fixes" had been rejected (notably because a manifest doesn't fix it if end user functionality requires administrator rights to accomplish and doesn't have the permissions to do so).

The real crux of the problem - this application was designed 20 years ago before the registry, services and UAC were even thought of. At least I hope this means some job security for me.

 

[DaveSimmons]

If the service is always running with admin rights, does the user process need any?

Even if they are running a limited account, it's normal to have your installer / setup program require admin rights for the installation process, to get your service installed properly.

(But yes, UAC is not my friend.)

 

[SunnyD]

Originally posted by: DaveSimmons
If the service is always running with admin rights, does the user process need any?

Even if they are running a limited account, it's normal to have your installer / setup program require admin rights for the installation process, to get your service installed properly.

(But yes, UAC is not my friend.)

The problem is that the end user is supposed to, for example: be able to start and stop the service. Without an account with rights to do so, as well as elevating from the limited account - this isn't possible.

There is several other bits of functionality left over from 20 years of bolt-ons and such which complicate the matter of who needs what privileges. Basically, the whole app needs to be redesigned from the ground up, but it can't be (or rather won't be) at this point do to legacy issues and time constraints.

 

[VinylxScratches]

Bundle it with Windows XP and Microsoft Virtual PC 2007 😛

 

[Ken g6]

Well, if "stop the service" is defined as "stop everything but a small stub listening for a start command", it shouldn't be that bad. Sure, as many users as the stub allows to send a start/stop command could do so. It might be most efficient to implement the command over TCP, but you could only accept connections from localhost; or you could pass stuff around by temp files or something. In any case, it wouldn't be any more insecure than what you're trying to do now.

 

[SunnyD]

Originally posted by: Ken g6
Well, if "stop the service" is defined as "stop everything but a small stub listening for a start command", it shouldn't be that bad. Sure, as many users as the stub allows to send a start/stop command could do so. It might be most efficient to implement the command over TCP, but you could only accept connections from localhost; or you could pass stuff around by temp files or something. In any case, it wouldn't be any more insecure than what you're trying to do now.

Yeah, I've investigated several similar approaches. The issue was that we were supposed to release a few days ago, and I was looking for a quick fix around the legacy code/design. Unfortunately, there is no quick fix... it requires reengineering a good bit of the way the app interacts with the "world".

 

[Venix]

You can modify the service's DACL with QueryServiceObjectSecurity/SetServiceObjectSecurity to give Users SERVICE_START and SERVICE_STOP privileges.

Another option is to register it as a COM server, which will cause it to be started whenever someone calls CoCreateInstance for your COM object.

 

[SunnyD]

Originally posted by: Venix
You can modify the service's DACL with QueryServiceObjectSecurity/SetServiceObjectSecurity to give Users SERVICE_START and SERVICE_STOP privileges.

Another option is to register it as a COM server, which will cause it to be started whenever someone calls CoCreateInstance for your COM object.

Yeah, I was the former path. The problem there is we can't be "certain" of what the end users' administrative configurations are going to be (odds are they'll use the User group, but for whatever reason, they might not). The alternative is a management account, but then we have to assign a static password to the account and that becomes a security risk.

As far as COM goes, management wants to avoid it. And, this really is a server style service, has to run all the time (unless someone wants it turned off for some odd reason).

 

[TheKub]

Originally posted by: SunnyD
We have no way of knowing what kind of security methodology an end user/client is going to run. Is the general populace going to strictly run limited accounts? Are they going to have local admin? What rights are their user accounts going to have?

I would always shoot for limited accounts only. IT depts hate it when dept "x" just purchased program "y" with out consulting them only to find that it was programed with out security in mind and needs local admin to function correctly. Now that entire department runs with local admin\lower security and be comes a PITA forever.

IMHO.

I am not a developer.

 

[wwswimming]

i've been working with Vista a little more.

i really don't mind the UAC if it makes it harder to install virus-spyware crap on
my machine. that's what it's for, isn't it ?

 

[SunnyD]

Originally posted by: TheKub

Originally posted by: SunnyD
We have no way of knowing what kind of security methodology an end user/client is going to run. Is the general populace going to strictly run limited accounts? Are they going to have local admin? What rights are their user accounts going to have?

I would always shoot for limited accounts only. IT depts hate it when dept "x" just purchased program "y" with out consulting them only to find that it was programed with out security in mind and needs local admin to function correctly. Now that entire department runs with local admin\lower security and be comes a PITA forever.

IMHO.

I am not a developer.

I would tend to agree... IF we were designing a package from the ground up. Unfortunately I have to work with code that is deployed to many customers around the world across dozens of different software packages and legacy versions. Once you start adding the layers of paint, it gets ugly. We're already changing some things on customers mid-stride, but they're functional changes in the application... NOT procedural changes in their methods of administration.

Originally posted by: wwswimming
i've been working with Vista a little more.

i really don't mind the UAC if it makes it harder to install virus-spyware crap on
my machine. that's what it's for, isn't it ?

I agree - UAC works fine - provided the application and security measures are designed with it in mind. This software wasn't designed with UAC in mind, hence the "back to the drawing board" approach, with handcuffs.