I reviewed azure-proxy-agent 1.0.30-0ubuntu2 as checked into questing. This
shouldn't be considered a full audit but rather a quick gauge of
maintainability.
azure-proxy-agent is a project that enhances the security of virtual
machines by leveraging eBPF. This allows hardening against common attacks.
- CVE History
- None
- The project is relatively new.
- osv-scanner detected 32 vulnerabilities in the vendored dependencies.
However, these appear to be false positives, as the vulnerable
dependencies are either not used during building or have updated
versions. These detections are based off of Cargo.lock files inside
each vendored dependency, which list outdated versions and
dependencies that aren't required for the building of the package.
- Build-Depends
- Normal build depends.
- Some of the vendored dependencies are rather large (larger than the
package itself). This makes it more difficult to maintain, as a
vulnerability in a dependency would mean updating all the packages
where it is vendored.
- pre/post inst/rm scripts
- postinst and prerm scripts to set-up/remove a systemd service. They
seem normal.
- init scripts
- None
- systemd units
- The systemd service seems to be protected adequately, utilizing
proper sandboxing measures such as ProtectSystem, RestrictSUIDSGID,
RestrictHostname, among other configurations. The service seems to
use allowlisting extensively, which is great.
- The capabilities seem to be using CapabilityBoundingSet= with '~'
exclusively, meaning that the options listed there are a denylist
instead of the normal allowlist. The capabilities seem to be denying
some file operations.
- One of the capabilities appears to be listed incorrectly, being
listed as SETFCAP instead of CAP_SETFCAP. As this is a denylist,
this capability is effectively allowed instead due to the wrong
spelling.
- Seems to allow certain IPs, which are localhost, Microsoft owned, and
a 169.254. link local address.
- dbus services
- None
- setuid binaries
- None
- binaries in PATH
- /usr/sbin/azure-proxy-agent
- sudo fragments
- None
- polkit files
- None
- udev rules
- None
- unit tests / autopkgtests
- Appears to run a basic unit test suite as part of cargo.
- cron jobs
- None
- Build logs
- Seems normal.
- Processes spawned
- The process management seems to be fine. The service seems to spawn a
setup tool to manage the instalation of the service. For Windows, the
spawned processes are not using absolute paths, but this is for
Windows environment. For Linux specifically, it seems fine.
- Memory management
- The application does use unsafe rust, but all usages of unsafe seem to
happen in windows-specific files and not Linux.
- File IO
- The file IO seems decent. Some usages of `.unwrap()` which seem fine
for the functions that it is used in, as the functions shouldn't fail,
although care has to go into making sure `.unwrap()` is not misused
without proper error management.
- There is one specific instance in the `json_write_to_file` function
in `misc_helpers.rs` which seems problematic. Due to the usage of `?`
to propagate errors, the funcion may fail to clean-up the temporary
file that was created. As the application is designed to be ran in
an isolated environment without local access this shouldn't be too
big of an issue, but it should be noted due to the issue of having
predictable file names and the issue of temporary files not being
cleaned up after an unexpected error could cause information exposure
to other local users.
- Logging
- Loggins looks fine.
- Environment variable usage
- None, apart from test files and windows-specific lines of code.
- Use of privileged functions
- There seem to be some chown calls that set permissions of folders as
root only for the "ACL" functions. These seem to be in place to
disallow key access to non-privileged users. There don't seem to be any
issues here.
- Use of cryptography / random number sources etc
- None, excluding vendored crates.
- Use of temp files
- The usage of other temp files seems decent, apart from the
aforementioned information in the File IO section. Some of the temp
files seem to have predictable names which can be an issue for attacks
with local access, which could be something to keep in mind.
- Use of networking
- The application seems to use `hyper` for sending network requests. Some
usage seems to follow a coded URL string, for example
`"http://{}:{}{}/{}/key-attestation"`. As mentioned previously in the
systemd section, 3 IP addresses seem to be allowed, which are
localhost, 168.63.129.16 which is an address owned by Microsoft, and
169.254.169.254 which is a link local address used by Azure for IMDS,
where "communication between the VM and IMDS never leaves the host".
- Overall, it makes sense for this application to use networking
services. The application also seems to implement a proxy server, and
the implementation allows the creation of a TCP stream and sending
HTTP requests over it as a public function. This implementation uses
eBPF to route requests to the proxy and then allow/deny requests before
routing the allowed requests back to the endpoints. No issues were
encountered on that front.
- The application also implements authorization rules for requests,
allowing or disallowing requests based on configuration. This seems to
be tied in with the three allowed IP addresses by systemd.
- Use of WebKit
- None.
- Use of PolicyKit
- None.
- Any significant Coverity results
- Coverity does not support rust yet.
- Any significant shellcheck results
- None
- Any significant Semgrep results
- None
Overall the project seems to be clean and maintainable. The upstream
project seems to adress most issues in a timely fashion, has no PRs open
currently, and also has a SECURITY.md file for reporting vulnerabilities.
When issues were identified upstream, the maintainers proceeded to be
professional in fixing these issues and also implemented some suggestions.
The vendoring of Rust dependencies can become a chore with security
maintenance as each vendored dependency would need to be patched
independently if a vulnerability were to be encountered. It is important
to keep these dependencies updated and monitor for any issues in that
regard.
Security team ACK for promoting azure-proxy-agent to main.
** Changed in: azure-proxy-agent (Ubuntu)
Assignee: Hlib Korzhynskyy (hlibk) => (unassigned)
** Changed in: azure-proxy-agent (Ubuntu)
Status: New => In Progress
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/2112359
Title:
[MIR] azure-proxy-agent
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/azure-proxy-agent/+bug/2112359/+subscriptions
--
ubuntu-bugs mailing list
[email protected]
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
