https://bugs.documentfoundation.org/show_bug.cgi?id=164225
Stephan Bergmann <[email protected]> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |RESOLVED Assignee|[email protected] |[email protected] |desktop.org | Resolution|--- |FIXED --- Comment #5 from Stephan Bergmann <[email protected]> --- (In reply to [email protected] from comment #0) > ## Recommendations > * Do not allow the installation directory to be chosen at install time > * Manually set ACLs for the installation directory > * If the installing user manually chooses an installation directory, warn > them that this may affect the security of the system that the Ivanti > software is loaded onto. When looking how best to address this issue, none of the above items looked particularly promising: * People will likely still want to decide where to put installations (esp. if they have multiple ones). * For a user doing an installation to a place other than `C:\Program Files`, where they have all the necessary privileges, it would look odd for the installation process to remove those privileges (esp. since, in that case, a MAR update would not need admin privileges via the update_service.exe in the first place). * Even adding some warning to the manual msi installation tab page turned out to be a somewhat non-trivial option, as the content of that page has to be laid out to the pixel (in instsetoo_native/inc_openoffice/windows/msi_languages/Control.ulf), with no spare place for such a warning. My next thought was to only install LO's update_service.exe as a Windows service (i.e., grant its execution admin privileges) when it will actually be needed during MAR updates (i.e., when modifying the files in the install location requires admin privileges). My hope was that one could somehow use Windows' GetNamedSecurityInfo, GetExplicitEntriesFromAcl, et al to determine upfront during LO installation whether modifying the files in the install location will require admin privileges later during a MAR update. But I failed that, so what I did, at least for now, in my actual commit (cf. comment 4) is to conservatively base that decision on whether the install location is underneath FOLDERID_ProgramFiles (i.e., `C:\Program Files`). There, the service will be needed during MAR update (so it is installed), but the install directory will not be writable by plain users (so this issue should not be exploitable). When installing to other places, the service would likely not be needed during MAR update (so it is not installed, and this issue should be moot in that case). Conservatively, the worst that can happen is that a MAR update could need the service after all but it is not installed. Better approaches welcome. Updated the release notes at <https://wiki.documentfoundation.org/index.php?title=ReleaseNotes/25.8&oldid=777267> "MAR service restrictions". -- You are receiving this mail because: You are the assignee for the bug.
