Hi! I have a client with the "ALL_APPLICATION_PACK...
# windows
Hi! I have a client with the "ALL_APPLICATION_PACKAGES" issue on Windows Server 2019. @Stefano Bonicatti fixed it in 5.0.1 https://github.com/osquery/osquery/issues/7165. My client is using 4.9.0, so the fix is not present. However, before telling them to upgrade, I want to test it in a VM, but I can't reproduce it.
Copy code
On a Windows Server 2019 everything seems to work, but on another instance the install succeeds but the upgrade fails to set the ACLs.
I'm not sure what is the specific difference between the instances of the same Windows Server version that seem to not have any problem, versus the one that do, but all the issues are around ACLs.
I think I'm facing the same thing with windows instances. Any tips on that?
The following pictures show how the folder Program files and osquery have the ALL_APPLICATION_PACKAGES group. However, the Osquery installer checks osquery/osqueryd and osquery/osqueryd/osqueryd.exe that do not have that group. So the installation finishes ok, and Osquery starts after it. This is the 3rd windows server 2019 machine on which I tested it, and I couldn't reproduce it so far.
The "_*unsafe*_" flag will work around the problem. But I understood it is used to prevent switching binaries after installation. Are there other considerations?
But are we talking about an issue with deploying osquery through chocolatey or something else? Because the
flag would come into play after deployment, while the issue was around setting the correct ACLs when installing through chocolatey.
Sorry, Stefano. We use the MSI file to install Osquery. I understand this specific bug is related to the installation process using chocolatey. I think this is the bug: https://github.com/osquery/osquery/issues/5965 But there is not much information about it.
Thank you for the explanation about
, I didn't realize
Yeah that issue still needs to be fully triaged. I mean, it's clear that osquery doesn't recognize those additional ACLs as safe (
), this "normally" works because the MSI removes those from the internal
folder and executable. On my Windows 10 I only have them in the
folder directly inside
C:\Program Files
. Then there are other things on top of this. When triaging https://github.com/osquery/osquery/issues/7165 (so now this is partially related), we stumbled upon a known bug in the WinAPIs with converting some SIDs, and
trigger that bug, which makes difficult via PowerShell to correctly refer to those ACLs and remove them from the folder. In fact this was fixed by fully clearing the ACLs and then reapplying them without the unwanted ones.
@Daniel Bretón Suárez so just to clarify, is the customer installing osquery with the MSI too and having an issue with
been left behind in
C:\Program Files\osquery\osqueryd
C:\Program Files\osquery\osqueryd.exe
and osquery subsequently fails to start? If yes than this is a new problem, because as far as we knew the MSI seemed to not have this issue, but I might recall incorrectly what we've tried.
Although at the same time, I would make sure that there's no group policy under Computer Configuration -> Policies -> Windows Settings -> Security Settings -> File System which may be forcing them back. I don't have a Windows Server available right now to test.
The client is using 4.9.0, so it doesn't have your fix on it. We provide a powershell script that, at some point, launches the following command:
Start-Process .\osquery-4.9.0.msi -ArgumentList "/quiet" -Wait
I couldn't reproduce it on a fresh Windows Server 2019 with the same build number (version 1809 build 17763.379). So at least, it doesn't seem to be a common issue. I will ask them about their group policy, because I don't know. Thank you for your help.
@Daniel Bretón Suárez The fix though is only in the Chocolatey install, the MSI is not using that powershell script that the PR changes.
Which means that a newer version of osquery won't fix the issue for your customer