Win32UI.exe Application Manifest Not Applied

[mstarks01]

Starting with Vista, applications need to have either an internal or external XML application manifest for applications that require administrator access. This elevates the application using UAC. os_win32ui.c has some code which seems to attempt to identify if the user is an administrator, and there is a .manifest file in that same directory, but it doesn't work.

[awiddersheim]

I've seen this as well and know how to fix it but am waiting for the 2.8 release before I start to consider taking on any major changes.

[mstarks01]

@awiddersheim Thanks and much appreciated.

[awiddersheim]

Right now I'm basically thinking of not only applying this manifest to the UI but to many if not all of the OSSEC executables that get installed. I'd also like to consolidate a lot of the Windows code/definitions into single includes like defs.h for example. Right now things on the windows side is a bit all over the place and there is a lot of code duplication for no real reason.

I would also like to move a lot of installation stuff surrounding services/permissions into NSIS instead of having it written in C. The ground work has been started in the upcoming 2.8 release but a lot more can be moved which will reduce a lot of C code and hopefully make things a bit easier to change for everyone since NSIS is a bit easier to work with IMO.

[awiddersheim]

Also, just to put this down in public, the manifest does get added to the win32ui.exe. It just isn't doing so in a way to Windows is seeing it/using it. I think changing the ID that gets to 1 should fix the issue.

https://github.com/ossec/ossec-hids/blob/master/src/win32/ui/os_win32ui.h#L103

I thought I read somewhere on some Windows documentation page that it is required to be 1 to work so I'm not sure why 201 was used but I'm having a hard time finding that documentation right now.

[mstarks01]

There's very little reason for standard users to be messing with ossec. An unprivileged attacker would benefit from seeing even ossec.conf, so I agree that most everything should require privilege escalation.

[awiddersheim]

Agreed. The ossec.conf should no longer become world readable when edited by the win32ui.exe after the work in #89 but using a manifest is the proper way to do things in Windows which is what prompted me to start looking at the manifest and it's failure to be applied in the first place.

[mstarks01]

I don't want to diverge the intent of this thread, but if you have the inclination you may want to look at the feasibility of running ossec-agent.exe under Local Service or Network Service rather than Local System (I tried it and it doesn't work). The network part should not need widespread access to the system that Local System provides. Syscheck and rootcheck does need this access and perhaps it is inheriting the rights from ossec-agent.exe, but a more privilege separated model similar to what exists on the 'nix side it desirable.

[jrossi]

No need to wait master is moving forward and stable will pull in changes/bug fixes as needed.

[awiddersheim]

Just a bit busy at the moment. Didn't mean to imply that I was waiting for 2.8 but rather after 2.8 is probably the timeframe at which I'll be able to start tackling things again.

[jrossi]

No problem ;)

On Apr 23, 2014, at 8:48 AM, "awiddersheim" [email protected] wrote:

Just a bit busy at the moment. Didn't mean to imply that I was waiting for 2.8 but rather after 2.8 is probably the timeframe at which I'll be able to start tackling things again.

—
Reply to this email directly or view it on GitHub.