Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Win32 file security check API needed #409

Open
g-bougard opened this issue Nov 22, 2017 · 2 comments
Open

Win32 file security check API needed #409

g-bougard opened this issue Nov 22, 2017 · 2 comments

Comments

@g-bougard
Copy link
Contributor

g-bougard commented Nov 22, 2017

As demonstrated by #404 PR, related to #403 issue, we need to provide an API to permit contributor to check the security level of script we may want to run. This is easy on Unix platform but we need to request specific system API on platform like Win32.

I searched a little on available Win32 modules. Win32::Checks seems really old and seems not available on CPAN and Win32::FileSecurity seems a better choice. But, IMHO, this last module provides mostly not needed APIs and also provides API to change file security. So I'm against to include this module in the Win32 installer. Then I'll see to mimic the Win32::FileSecurity::Get() API using Win32API module like was done in FusionInventory::Agent::Tools::Win32 module for API like FileTimeToSystemTime() or getAgentMemorySize() methods.

That said, a question for concerned people, what if we resurrect runCommand feature from Collect task is we fix the constraint: only secured script could be run-able ?

@g-bougard g-bougard added this to the 2.4 milestone Nov 22, 2017
@g-bougard g-bougard self-assigned this Nov 22, 2017
@guillomovitch
Copy link
Contributor

I"m not sure that the fact than a script is owned by root user gives any hint about its security level, for whatever it means. So, I'd rather talk of legitimate scripts instead of secured scripts.

As long as it is not default agent behaviour to execute arbitrary scripts, meaning there should be some local or central (ie, in GLPI) explicit configuration option to set, and than you can perform some minimal sanity check on file permission, either on the scripts themselves, or on their directory, that's OK for me.

@g-bougard
Copy link
Contributor Author

I agree we should better use the more meaningful legitimate term.
I propose to provide a runLegitimateScript() API to propose a best practice for contributors.
It should even by default not run any script and just log a warning. And new agent option like trust-legitimate-script would then permit to run such script we estimate legitimate (I hope this is not a too frenglish sentence).

In later releases we should enhance this part proposing admins to enable the option on server-side and even permitting them to register really legitimate script signatures. We should than also collect server-side any legitimate script run attempt and propose a process to check them so there signature can be enabled easily. Eventually any admins authorized to enable a script signature should be able to ask agent to upload the script after a not authorized run attempt.

This could also be a Deploy task security enhancement as actually admins can run a custom script during deployment, but nothing guarantee them the script has not been altered before it is really run.

@g-bougard g-bougard modified the milestones: 2.4, 2.4.1 Dec 22, 2017
@g-bougard g-bougard modified the milestones: 2.4.1, 2.4.2 Jun 29, 2018
@g-bougard g-bougard removed this from the 2.4.2 milestone Oct 2, 2018
@g-bougard g-bougard removed their assignment May 31, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants