[Desktop-packages] [Bug 1936907] Re: [MIR] ADSys
$ ./change-override -c main -B adsys Override component to main adsys 0.8.2 in jammy: universe/admin -> main adsys 0.8.2 in jammy amd64: universe/admin/optional/100% -> main adsys 0.8.2 in jammy arm64: universe/admin/optional/100% -> main adsys 0.8.2 in jammy armhf: universe/admin/optional/100% -> main adsys 0.8.2 in jammy ppc64el: universe/admin/optional/100% -> main adsys 0.8.2 in jammy riscv64: universe/admin/optional/100% -> main adsys 0.8.2 in jammy s390x: universe/admin/optional/100% -> main Override [y|N]? y 7 publications overridden. ** Changed in: adsys (Ubuntu) Status: In Progress => Fix Released -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to adsys in Ubuntu. https://bugs.launchpad.net/bugs/1936907 Title: [MIR] ADSys Status in adsys package in Ubuntu: Fix Released Bug description: [Availability] Available on all archs, available starting hirsute. It will be backported to Focal once an FFe has been accepted. [Rationale] We are supporting GPO Active Directory support on ubuntu starting hirsute. This features allows for an administrator to configure their Active Directory server to deploy per-machine and per-user configurations, enforce rules and other domain policies. Right now, dconf keys, sudo administration rights and computer and user scripts are supported. This feature is built and use the krb5 tickets which are provided by SSSD. Basically: - SSSD is dealing with user and machine registration/authentification and enforce password policies - ADSys is handling GPO enforcement and support. The Ubuntu specific policies needs to be installed on the Active Directory server (they are contained in the daemon). [Security] The daemon is started is running as a root user to be able to enforce machine policies, like rebuilding dconf databases, setting profiles. User only interacts with the client side (both sides communicates over GRPC), which can be ran as any user. Polkit is used to restrain access to some part of the API. There is a PAM module to build on demand per-user policy once authenticated with SSSD. They are rejected if the authentication or not all affected policies could be downloaded. [Quality assurance] Joining a domain in the ubiquity desktop installer makes the machine joining the AD domain and install adsys functionality. The package will be seeded directly on the desktop ISO. An extensive testsuite (more than 1k) is included and available as autopkgtests for rdepends. The whole stack is tested (even the client/daemon interaction) and coverage is measured (including in the small python script). However, tests with a real Active Directory server can only be done manually as there is no setup available in the autopkgtests infrastructure. [Dependencies] Main dependencies are libsmbclient, python3 (an embeeded script allows, via samba, connecting to AD LDAP) and SSSD/KRB5. This is a Go package, and all dependencies are vendored, and versions are controlled via go.mod. We are using dependabot (from Github) to automatically get notified of any dependencies updates (and security issues), which opens a PR, rebuild and run all tests to report it there. We are thus able to quickly merge them. [Standards compliance] Standard debhelper packaging, including a systemd service. [Maintenance] The desktop team will maintain it. * we commit to test no-change-rebuilds triggered by a dependent library/compiler and to fix any issues found for the lifetime of the release (including ESM when included) * we will provide timely testing of no-change-rebuilds from the security team, fixing the rebuilt package as necessary * we commit to provide updates to the security team for any affected vendored code for the lifetime of the release (including ESM when included) * we will provide timely, high quality updates for the security team to sponsor to fix issues in the affected vendored code [Background information] ADSys is composed of: - a daemon, named adsysd, running as root. This one will shutdown after a period of inactivity without any active request. It is socket activated. - a client, named adsysctl (which is a symlink to adsysd and only differ behavior from its executable name), which is running as the user (or root on boot for machine update). This ones optionally wakes up adsysd, connect through an Unix socket with SO_PEERCRED to communicate current user running the process. We are using grpc to communicate between the client and service. Each client request is validated through polkit, matching user name and permissions. The daemon will reject any unauthorized client connections. Note that all actions are always performed from executing the client, even the scheduled one by a cron. The daemon contains a python embedded script that uses samba utilities to connect with GSSAPI to th
[Desktop-packages] [Bug 1936907] Re: [MIR] ADSys
Thanks Seth for the review and the overall positive comments! :) Some answers: 1. the potential race is fixed after our discussion and pending some reviews 2. the pam modulefixes are done and merged already (even if upstream don’t deallocate, let’s do it on our side) 3. on the conditions that can be added to adsys-boot.service to make it less likely to spam the journal every five seconds for ten hours when on an airplane? -> We can’t rely on network being up (maybe we never had the network, or the interface is on but not connected yet, or the interface is on, has no Internet, but local network is enough to reach AD). Depending on all those conditions, we can’t link it to the network, it may be too early or too late. Also, we support offline mode once we have a valid cache. Considering that this case only happen the first time you boot your machine (no local cache for offline usage) and don’t have access to AD, this doesn’t seem a big issue and rather something you want to be alerted on, what do you think? 4. on the doc and examples containing a socket in /tmp -> This is more a debug example to run adsysd as non root. The issue with putting real values is then, if you do that on a system where adsysd is running, you end up erroring out on the systemd existing socket and then, it’s a nightmare to recover on the systemd side (you need to reset the state of the .socket unit). This is why the example carefully avoid using the real system socket (in addition to require root to read it). -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to adsys in Ubuntu. https://bugs.launchpad.net/bugs/1936907 Title: [MIR] ADSys Status in adsys package in Ubuntu: In Progress Bug description: [Availability] Available on all archs, available starting hirsute. It will be backported to Focal once an FFe has been accepted. [Rationale] We are supporting GPO Active Directory support on ubuntu starting hirsute. This features allows for an administrator to configure their Active Directory server to deploy per-machine and per-user configurations, enforce rules and other domain policies. Right now, dconf keys, sudo administration rights and computer and user scripts are supported. This feature is built and use the krb5 tickets which are provided by SSSD. Basically: - SSSD is dealing with user and machine registration/authentification and enforce password policies - ADSys is handling GPO enforcement and support. The Ubuntu specific policies needs to be installed on the Active Directory server (they are contained in the daemon). [Security] The daemon is started is running as a root user to be able to enforce machine policies, like rebuilding dconf databases, setting profiles. User only interacts with the client side (both sides communicates over GRPC), which can be ran as any user. Polkit is used to restrain access to some part of the API. There is a PAM module to build on demand per-user policy once authenticated with SSSD. They are rejected if the authentication or not all affected policies could be downloaded. [Quality assurance] Joining a domain in the ubiquity desktop installer makes the machine joining the AD domain and install adsys functionality. The package will be seeded directly on the desktop ISO. An extensive testsuite (more than 1k) is included and available as autopkgtests for rdepends. The whole stack is tested (even the client/daemon interaction) and coverage is measured (including in the small python script). However, tests with a real Active Directory server can only be done manually as there is no setup available in the autopkgtests infrastructure. [Dependencies] Main dependencies are libsmbclient, python3 (an embeeded script allows, via samba, connecting to AD LDAP) and SSSD/KRB5. This is a Go package, and all dependencies are vendored, and versions are controlled via go.mod. We are using dependabot (from Github) to automatically get notified of any dependencies updates (and security issues), which opens a PR, rebuild and run all tests to report it there. We are thus able to quickly merge them. [Standards compliance] Standard debhelper packaging, including a systemd service. [Maintenance] The desktop team will maintain it. * we commit to test no-change-rebuilds triggered by a dependent library/compiler and to fix any issues found for the lifetime of the release (including ESM when included) * we will provide timely testing of no-change-rebuilds from the security team, fixing the rebuilt package as necessary * we commit to provide updates to the security team for any affected vendored code for the lifetime of the release (including ESM when included) * we will provide timely, high quality updates for the security team to sponsor to fix issues in the affected vendored code [Background information] ADSys is composed o
[Desktop-packages] [Bug 1936907] Re: [MIR] ADSys
I reviewed adsys 0.8 as checked into jammy. This shouldn't be
considered a full audit but rather a quick gauge of maintainability. As
usual with golang code, there's vastly more code in the package than we've
authored, and it's not feasible to review the entirety.
adsys allows network administrators to include Ubuntu systems in Windows
Group Policy ecosystem. There's easy support for a lot of individual
tunable elements, as well as generic support for running both machine and
user scripts on login, logout, etc.
- CVE History:
none :)
- Build-Depends?
Build-Depends: debhelper-compat (= 13),
dh-apport,
dh-golang,
golang-go (>= 2:1.16~),
libsmbclient-dev,
libdbus-1-dev,
python3,
python3-samba,
samba-dsdb-modules,
libpam0g-dev,
samba,
dbus,
- pre/post inst/rm scripts?
mostly added automatically by dh_ helpers; registers and unregisters pam
module, enables systemd units, purges and unmasks systemd units, etc.
- init scripts?
none
- systemd units?
sets up socket activation, sets up timers, refreshes policies, runs
machine scripts in machine units, runs user scripts in user units
- dbus services?
none
- setuid binaries?
none
- binaries in PATH?
adsysd, adsysctl
- sudo fragments?
/etc/sudoers.d/99-adsys-privilege-enforcement is under control of the
application:
"%admin ALL=(ALL) !ALL\n"
"%sudo ALL=(ALL:ALL) !ALL\n"
contentSudo += fmt.Sprintf("\"%s\" ALL=(ALL:ALL) ALL\n", e)
these are very powerful; I'd appreciate a second set of eyes here :)
- polkit files?
yes, seems reasonable
- udev rules?
none
- unit tests / autopkgtests?
yes, many tests, run during the build
- cron jobs?
none, systemd timer units used instead
- Build logs:
the shell completion files are dumped during build, it's a bit noisy,
but otherwise looks clean
- Processes spawned?
Yes -- pam module, copied from pam_exec.c
Yes -- adsys spawned from the user manager will run scripts, seems okay
- Memory management?
Most is golang, safe enough
pam module has some memory leaks; when reported to upstream pam_exec.c
folks, they appear to be leaning towards leaking even more memory :) so
probably fine.
- File IO?
Some issues, raised elsewhere.
- Logging?
pam module looked fine
- Environment variable usage?
NO_COLOR and KRB5CCNAME, seemed safe
- Use of privileged functions?
chown
- Use of cryptography / random number sources etc?
none
- Use of temp files?
none
- Use of networking?
grpc; to the extent I looked at it, it felt safe enough
- Use of WebKit?
none
- Use of PolicyKit?
yes, internal/authorizer/authorizer.go
looks up process start time by searching *backwards* through
/proc/pid/stat file for a ), then looking forward 19 fields. I didn't
double-check the math but it sure sounds promising.
- Any significant cppcheck results?
memory leaks in pam_adsys.c, upstream for inspiration pam_exec didn't seem
bothered
- Any significant Coverity results?
none
- Any significant shellcheck results?
none
- Any significant bandit results?
none
adsys is carefully written, well-documented, and didrocks and jibel were
very responsive to comments and feedback.
Security team ACK for promoting adsys to main.
I filed a few bugs along the way:
https://github.com/grpc/grpc-go/issues/5137
https://github.com/olekukonko/tablewriter/issues/199
And some miscellaneous notes I took:
Are there any conditions that can be added to adsys-boot.service to make
it less likely to spam the journal every five seconds for ten hours when on an
airplane?
https://bugs.launchpad.net/ubuntu/+source/adsys/+bug/1961459
pam_adsys.c update_policy() arggv leak in fork() failure
pam_adsys.c update_machine_policy() arggv leak in fork() failure
pam_adsys.c update_machine_policy() -- status != 0 looks like it ought to
work but I don't think that's how that API is supposed to be used
pam_adsys.c pam_sm_open_session() -- gethostname() indentation is funny
https://bugs.launchpad.net/ubuntu/+source/adsys/+bug/1961458
[redacted]
./internal/policies/scripts/scripts.go -- typo %qto
./conf.example/adsys.yaml
./doc/5.-The-adsys-daemon.md
Both these use /tmp/adsysd/ .. paths in configuration files -- is this
the recommended way to use adsys? It'd be nice if the configs were "real",
production-ready, defaults, etc.
** Bug watch added: github.com/grpc/grpc-go/issues #5137
https://github.com/grpc/grpc-go/issues/5137
** Bug watch added: github.com/olekukonko/tablewriter/issues #199
https://github.com/olekukonko/tablewriter/issues/199
** Changed in: adsys (Ubuntu)
Status: New => In Progress
** Changed in: adsys (Ubuntu)
Assignee: Ubuntu Security Team (ubuntu-security) => (unassigned)
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to adsys in Ubuntu.
https://bugs.launchpad
[Desktop-packages] [Bug 1936907] Re: [MIR] ADSys
** Description changed: [Availability] Available on all archs, available starting hirsute. It will be backported to Focal once an FFe has been accepted. [Rationale] We are supporting GPO Active Directory support on ubuntu starting hirsute. This features allows for an administrator to configure their Active Directory server to deploy per-machine and per-user configurations, enforce rules and other domain policies. - Right now, dconf keys are supported. + Right now, dconf keys, sudo administration rights and computer and user + scripts are supported. This feature is built and use the krb5 tickets which are provided by SSSD. Basically: - SSSD is dealing with user and machine registration/authentification and enforce password policies - ADSys is handling GPO enforcement and support. The Ubuntu specific policies needs to be installed on the Active Directory server (they are contained in the daemon). [Security] The daemon is started is running as a root user to be able to enforce machine policies, like rebuilding dconf databases, setting profiles. User only interacts with the client side (both sides communicates over GRPC), which can be ran as any user. Polkit is used to restrain access to some part of the API. There is a PAM module to build on demand per-user policy once authenticated with SSSD. They are rejected if the authentication or not all affected policies could be downloaded. [Quality assurance] Joining a domain in the ubiquity desktop installer makes the machine joining the AD domain and install adsys functionality. The package will be seeded directly on the desktop ISO. - An extensive testsuite (more than 700) is included and available as + An extensive testsuite (more than 1k) is included and available as autopkgtests for rdepends. The whole stack is tested (even the client/daemon interaction) and coverage is measured (including in the small python script). However, tests with a real Active Directory server can only be done manually as there is no setup available in the autopkgtests infrastructure. [Dependencies] Main dependencies are libsmbclient, python3 (an embeeded script allows, via samba, connecting to AD LDAP) and SSSD/KRB5. This is a Go package, and all dependencies are vendored, and versions are controlled via go.mod. We are using dependabot (from Github) to automatically get notified of any dependencies updates (and security issues), which opens a PR, rebuild and run all tests to report it there. We are thus able to quickly merge them. [Standards compliance] Standard debhelper packaging, including a systemd service. [Maintenance] The desktop team will maintain it. * we commit to test no-change-rebuilds triggered by a dependent library/compiler and to fix any issues found for the lifetime of the release (including ESM when included) * we will provide timely testing of no-change-rebuilds from the security team, fixing the rebuilt package as necessary * we commit to provide updates to the security team for any affected vendored code for the lifetime of the release (including ESM when included) * we will provide timely, high quality updates for the security team to sponsor to fix issues in the affected vendored code - [Background information] ADSys is composed of: - a daemon, named adsysd, running as root. This one will shutdown after a period of inactivity without any active request. It is socket activated. - a client, named adsysctl (which is a symlink to adsysd and only differ behavior from its executable name), which is running as the user (or root on boot for machine update). This ones optionally wakes up adsysd, connect through an Unix socket with SO_PEERCRED to communicate current user running the process. We are using grpc to communicate between the client and service. Each client request is validated through polkit, matching user name and permissions. The daemon will reject any unauthorized client connections. Note that all actions are always performed from executing the client, even the scheduled one by a cron. - The daemon contains a python embeeded script to reuse samba utilities to - connect with GSSAPI to the AD LDAP server and list available GPOs. GPOs - are then downloaded in a cache directory which isn’t accessible to + The daemon contains a python embedded script that uses samba utilities + to connect with GSSAPI to the AD LDAP server and list available GPOs. + GPOs are then downloaded in a cache directory which isn’t accessible to users. The daemon also contains all GPOs policies to install on the Active Directory side to reflect them in the UI. This could be accessed online or dumped directly via the command line tool. Finally, those are automatically refreshed for any supported LTSes and intermediate versions. The availability of features can be different cross-releas
[Desktop-packages] [Bug 1936907] Re: [MIR] ADSys
It seems this is important for the 20.04.4 point release, so while we try to prioritize all the cases in the queue for security review let us set this to Critical + 20.04.4 Milestone. ** Changed in: adsys (Ubuntu) Importance: Undecided => Critical ** Changed in: adsys (Ubuntu) Milestone: None => ubuntu-20.04.4 -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to adsys in Ubuntu. https://bugs.launchpad.net/bugs/1936907 Title: [MIR] ADSys Status in adsys package in Ubuntu: New Bug description: [Availability] Available on all archs, available starting hirsute. It will be backported to Focal once an FFe has been accepted. [Rationale] We are supporting GPO Active Directory support on ubuntu starting hirsute. This features allows for an administrator to configure their Active Directory server to deploy per-machine and per-user configurations, enforce rules and other domain policies. Right now, dconf keys are supported. This feature is built and use the krb5 tickets which are provided by SSSD. Basically: - SSSD is dealing with user and machine registration/authentification and enforce password policies - ADSys is handling GPO enforcement and support. The Ubuntu specific policies needs to be installed on the Active Directory server (they are contained in the daemon). [Security] The daemon is started is running as a root user to be able to enforce machine policies, like rebuilding dconf databases, setting profiles. User only interacts with the client side (both sides communicates over GRPC), which can be ran as any user. Polkit is used to restrain access to some part of the API. There is a PAM module to build on demand per-user policy once authenticated with SSSD. They are rejected if the authentication or not all affected policies could be downloaded. [Quality assurance] Joining a domain in the ubiquity desktop installer makes the machine joining the AD domain and install adsys functionality. The package will be seeded directly on the desktop ISO. An extensive testsuite (more than 700) is included and available as autopkgtests for rdepends. The whole stack is tested (even the client/daemon interaction) and coverage is measured (including in the small python script). However, tests with a real Active Directory server can only be done manually as there is no setup available in the autopkgtests infrastructure. [Dependencies] Main dependencies are libsmbclient, python3 (an embeeded script allows, via samba, connecting to AD LDAP) and SSSD/KRB5. This is a Go package, and all dependencies are vendored, and versions are controlled via go.mod. We are using dependabot (from Github) to automatically get notified of any dependencies updates (and security issues), which opens a PR, rebuild and run all tests to report it there. We are thus able to quickly merge them. [Standards compliance] Standard debhelper packaging, including a systemd service. [Maintenance] The desktop team will maintain it. * we commit to test no-change-rebuilds triggered by a dependent library/compiler and to fix any issues found for the lifetime of the release (including ESM when included) * we will provide timely testing of no-change-rebuilds from the security team, fixing the rebuilt package as necessary * we commit to provide updates to the security team for any affected vendored code for the lifetime of the release (including ESM when included) * we will provide timely, high quality updates for the security team to sponsor to fix issues in the affected vendored code [Background information] ADSys is composed of: - a daemon, named adsysd, running as root. This one will shutdown after a period of inactivity without any active request. It is socket activated. - a client, named adsysctl (which is a symlink to adsysd and only differ behavior from its executable name), which is running as the user (or root on boot for machine update). This ones optionally wakes up adsysd, connect through an Unix socket with SO_PEERCRED to communicate current user running the process. We are using grpc to communicate between the client and service. Each client request is validated through polkit, matching user name and permissions. The daemon will reject any unauthorized client connections. Note that all actions are always performed from executing the client, even the scheduled one by a cron. The daemon contains a python embeeded script to reuse samba utilities to connect with GSSAPI to the AD LDAP server and list available GPOs. GPOs are then downloaded in a cache directory which isn’t accessible to users. The daemon also contains all GPOs policies to install on the Active Directory side to reflect them in the UI. This could be accessed online or dumped directly via the command line tool. Finally, those are automatically refreshed for
[Desktop-packages] [Bug 1936907] Re: [MIR] ADSys
Thanks for working out the kinks, Didier! MIR team ACK -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to adsys in Ubuntu. https://bugs.launchpad.net/bugs/1936907 Title: [MIR] ADSys Status in adsys package in Ubuntu: New Bug description: [Availability] Available on all archs, available starting hirsute. It will be backported to Focal once an FFe has been accepted. [Rationale] We are supporting GPO Active Directory support on ubuntu starting hirsute. This features allows for an administrator to configure their Active Directory server to deploy per-machine and per-user configurations, enforce rules and other domain policies. Right now, dconf keys are supported. This feature is built and use the krb5 tickets which are provided by SSSD. Basically: - SSSD is dealing with user and machine registration/authentification and enforce password policies - ADSys is handling GPO enforcement and support. The Ubuntu specific policies needs to be installed on the Active Directory server (they are contained in the daemon). [Security] The daemon is started is running as a root user to be able to enforce machine policies, like rebuilding dconf databases, setting profiles. User only interacts with the client side (both sides communicates over GRPC), which can be ran as any user. Polkit is used to restrain access to some part of the API. There is a PAM module to build on demand per-user policy once authenticated with SSSD. They are rejected if the authentication or not all affected policies could be downloaded. [Quality assurance] Joining a domain in the ubiquity desktop installer makes the machine joining the AD domain and install adsys functionality. The package will be seeded directly on the desktop ISO. An extensive testsuite (more than 700) is included and available as autopkgtests for rdepends. The whole stack is tested (even the client/daemon interaction) and coverage is measured (including in the small python script). However, tests with a real Active Directory server can only be done manually as there is no setup available in the autopkgtests infrastructure. [Dependencies] Main dependencies are libsmbclient, python3 (an embeeded script allows, via samba, connecting to AD LDAP) and SSSD/KRB5. This is a Go package, and all dependencies are vendored, and versions are controlled via go.mod. We are using dependabot (from Github) to automatically get notified of any dependencies updates (and security issues), which opens a PR, rebuild and run all tests to report it there. We are thus able to quickly merge them. [Standards compliance] Standard debhelper packaging, including a systemd service. [Maintenance] The desktop team will maintain it. * we commit to test no-change-rebuilds triggered by a dependent library/compiler and to fix any issues found for the lifetime of the release (including ESM when included) * we will provide timely testing of no-change-rebuilds from the security team, fixing the rebuilt package as necessary * we commit to provide updates to the security team for any affected vendored code for the lifetime of the release (including ESM when included) * we will provide timely, high quality updates for the security team to sponsor to fix issues in the affected vendored code [Background information] ADSys is composed of: - a daemon, named adsysd, running as root. This one will shutdown after a period of inactivity without any active request. It is socket activated. - a client, named adsysctl (which is a symlink to adsysd and only differ behavior from its executable name), which is running as the user (or root on boot for machine update). This ones optionally wakes up adsysd, connect through an Unix socket with SO_PEERCRED to communicate current user running the process. We are using grpc to communicate between the client and service. Each client request is validated through polkit, matching user name and permissions. The daemon will reject any unauthorized client connections. Note that all actions are always performed from executing the client, even the scheduled one by a cron. The daemon contains a python embeeded script to reuse samba utilities to connect with GSSAPI to the AD LDAP server and list available GPOs. GPOs are then downloaded in a cache directory which isn’t accessible to users. The daemon also contains all GPOs policies to install on the Active Directory side to reflect them in the UI. This could be accessed online or dumped directly via the command line tool. Finally, those are automatically refreshed for any supported LTSes and intermediate versions. The availability of features can be different cross-release and is supported in the daemon. Many utilities for debugging, following daemon or per transaction logs, streamed via our GRPC protocol are available.
[Desktop-packages] [Bug 1936907] Re: [MIR] ADSys
Thanks for the review! All comments should now be addressed. Required TODOs: * Statement is now clearly made in description Recommended TODOs: * subscription is now done * autopkgtests: no sudo anymore and they pass with 0.7.1: https://autopkgtest.ubuntu.com/packages/adsys * 0.7.1 ships the NOTICE file from yaml dependency * 0.7.1 now specify -buildmode=pie adsys 0.7.1 is now in the release pocket. -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to adsys in Ubuntu. https://bugs.launchpad.net/bugs/1936907 Title: [MIR] ADSys Status in adsys package in Ubuntu: New Bug description: [Availability] Available on all archs, available starting hirsute. It will be backported to Focal once an FFe has been accepted. [Rationale] We are supporting GPO Active Directory support on ubuntu starting hirsute. This features allows for an administrator to configure their Active Directory server to deploy per-machine and per-user configurations, enforce rules and other domain policies. Right now, dconf keys are supported. This feature is built and use the krb5 tickets which are provided by SSSD. Basically: - SSSD is dealing with user and machine registration/authentification and enforce password policies - ADSys is handling GPO enforcement and support. The Ubuntu specific policies needs to be installed on the Active Directory server (they are contained in the daemon). [Security] The daemon is started is running as a root user to be able to enforce machine policies, like rebuilding dconf databases, setting profiles. User only interacts with the client side (both sides communicates over GRPC), which can be ran as any user. Polkit is used to restrain access to some part of the API. There is a PAM module to build on demand per-user policy once authenticated with SSSD. They are rejected if the authentication or not all affected policies could be downloaded. [Quality assurance] Joining a domain in the ubiquity desktop installer makes the machine joining the AD domain and install adsys functionality. The package will be seeded directly on the desktop ISO. An extensive testsuite (more than 700) is included and available as autopkgtests for rdepends. The whole stack is tested (even the client/daemon interaction) and coverage is measured (including in the small python script). However, tests with a real Active Directory server can only be done manually as there is no setup available in the autopkgtests infrastructure. [Dependencies] Main dependencies are libsmbclient, python3 (an embeeded script allows, via samba, connecting to AD LDAP) and SSSD/KRB5. This is a Go package, and all dependencies are vendored, and versions are controlled via go.mod. We are using dependabot (from Github) to automatically get notified of any dependencies updates (and security issues), which opens a PR, rebuild and run all tests to report it there. We are thus able to quickly merge them. [Standards compliance] Standard debhelper packaging, including a systemd service. [Maintenance] The desktop team will maintain it. * we commit to test no-change-rebuilds triggered by a dependent library/compiler and to fix any issues found for the lifetime of the release (including ESM when included) * we will provide timely testing of no-change-rebuilds from the security team, fixing the rebuilt package as necessary * we commit to provide updates to the security team for any affected vendored code for the lifetime of the release (including ESM when included) * we will provide timely, high quality updates for the security team to sponsor to fix issues in the affected vendored code [Background information] ADSys is composed of: - a daemon, named adsysd, running as root. This one will shutdown after a period of inactivity without any active request. It is socket activated. - a client, named adsysctl (which is a symlink to adsysd and only differ behavior from its executable name), which is running as the user (or root on boot for machine update). This ones optionally wakes up adsysd, connect through an Unix socket with SO_PEERCRED to communicate current user running the process. We are using grpc to communicate between the client and service. Each client request is validated through polkit, matching user name and permissions. The daemon will reject any unauthorized client connections. Note that all actions are always performed from executing the client, even the scheduled one by a cron. The daemon contains a python embeeded script to reuse samba utilities to connect with GSSAPI to the AD LDAP server and list available GPOs. GPOs are then downloaded in a cache directory which isn’t accessible to users. The daemon also contains all GPOs policies to install on the Active Directory side to reflect them in the UI. This could be accessed online or dumped
