[SOLVED] Self-service targeting on Linux

[Robocop]

Hello everyone,

Infrastructure description:
Debian 12 server
joined to AD (via Winbind)
tis-waptserver 2.6.1.17705-092e11fc-amd64
WAPT server and WAPT repository

Client 1 Debian 13
outside AD (local account)
tis-waptagent 2.6.1.17705-092e11fc-amd64
tis-waptagent-gui 2.6.1.17705-092e11fc-amd64

Client 2 Debian 13
joined to AD (via Winbind)
tis-waptagent 2.6.1.17705-092e11fc-amd64
tis-waptagent-gui 2.6.1.17705-092e11fc-amd64

In the private repository I have I have four Linux applications, as well as a "self-service" package in which two of these applications are deployed via the "user" group (a local group present on "Client1" which contains my local user).
This self-service package is only applied to "Client1".
In the "self-service" GUI of "Client1", I can see the two applications deployed via the self-service package, and only those two.
However, on "Client2", although neither the self-service package nor any of the applications are deployed via the console, the "self-service" GUI sees all four applications present in the repository. Is this normal?

Both clients have the certificate that signed the four packages.

[sfonteneau]

However, on "Client 2", although neither the self-service nor any of the applications are deployed via the console, the "self-service" GUI sees the 4 applications present on the repository, is this normal?

Is the user a member of root, sudo, or wheel?

Simon

[Robocop]

Yes, it is.

[sfonteneau]

https://www.wapt.fr/fr/doc/wapt-create- ... es-package

To enable package filtering for local administrators, set the following parameter in the WAPT configuration: waptservice_admin_filter = True.

This ensures that local administrators only see packages they are explicitly authorized to install.


However, an admin is an admin; technically, they can change the waptservice_admin_filter parameter themselves. Therefore, this is purely for display purposes and not for security.

[Robocop]

Perfect, thank you.
Out of curiosity, is the behavior the same on Windows? Will a user who is a member of BUILTIN\Administrators see all the packages?

So, the only way to prevent a package (for example, one subject to a license) from running on an admin's machine would be to use a dedicated certificate?

[sfonteneau]

Out of curiosity, is the behavior the same on Windows? Will a user who is a member of BUILTIN\Administrators see all the packages?

Yes

So the only solution to prevent the execution of a package (for example, one subject to a license) on an admin's machine would be to use a dedicated certificate?

No, that's not a solution either, since it won't prevent the admin from downloading the package and launching a manual installation themselves (since they are an admin). An admin is an admin

So the best thing to do is to encrypt sensitive data:

https://www.wapt.fr/fr/doc/wapt-create- ... se-feature

With this system, even the admin of a workstation cannot retrieve the encrypted data if the packet is not destined for that machine.