I reviewed libteam version 1.26-1 as checked into bionic. This shouldn't
be considered a full security audit but rather a quick gauge of
maintainability.
No CVEs for libteam in our UCT database.
libteam provides a userspace version of various methods of bonding NICs
together that's more flexible than the kernelspace implementations.
- Build-Depends: debhelper, dh-autoreconf, libdaemon-dev, libdbus-1-dev,
libjansson-dev, libnl-3-dev, libnl-cli-3-dev, libnl-genl-3-dev,
libnl-route-3-dev, pkg-config
- Daemon manages interfaces, listens on dbus and zmq
- Daemonization code looks complicated, pidfile handling is baffling, but
nothing that looks insecure.
- No pre/post inst/rm scripts
- No initscripts
- No dbus services
- No setuid files
- bond2team, teamd, teamctl, and teamnl binaries in /usr/bin
- No sudo fragments
- No udev rules
- No test suite
- No cronjobs
- Clean build logs
- No subprocesses spawned
- Memory management looked clean
- Only real 'file' handling is the pidfile, and that's iffy
- Logging looked clean
- two uses of environment variables, TEAM_LOG and TEAMDCTL_LOG, looked
clean
- privileged operations looked clean
- No cryptography
- Extensive networking operations
- No privileged portions of code
- No temp files
- No WebKit
- No javascript
- No policykit
- Clean cppcheck
Congratulations to the libteam authors, this feels like a large
improvement over the previous review review I performed. I found one
issue with the Debian packaging that I don't understand, one small bug
in teamd_usock_sock_open(), and I still hate the pidfile handling. (If
it works I can understand why no one wants to touch it. I just have
trouble believing it works.)
- lintian warning malformed-deb-archive newer compressed control.tar.xz
- teamd_usock_sock_open() forgot to check the return value from
listen(2)
pidfile handling is baffling -- does it work?
- teamd_context_init() sets the global variable to point to a pointer to
the pidfile name (NULL at start)
- a function pointer named daemon_pid_file_proc is created to alias
teamd_pid_file_proc()
- teamd_set_default_pid_file() generates a dynamically allocated name
- when teamd_pid_file_proc() is called via the function pointer variable,
it just returns the global variable that is probably NULL at this point
- None of this looks security relevant but it sure is surprisingly gross.
Security team ACK for promoting libteam to main.
Thanks
** Changed in: libteam (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 libteam in Ubuntu.
https://bugs.launchpad.net/bugs/1392012
Title:
[MIR] libteam
Status in libteam package in Ubuntu:
New
Bug description:
Availability:
The package is available in universe, built on all architectures.
Rationale:
The package is a new (Build-)Depends for network-manager, for network device
teaming (aka user-space bonding) support.
Security:
Could not find any related security advisories.
Quality assurance:
The package is well-maintained in Debian and expected to not require
extensive effort to maintain in Ubuntu.
UI standards:
Not applicable.
Dependencies:
All build and binary dependencies are in main.
Standards compliance:
The package meets requirements.
Maintenance:
The package meets requirements.
Background information:
libteam is a library for communicating with the netlink kernel layer in order
to create bonded interfaces.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/libteam/+bug/1392012/+subscriptions
--
Mailing list: https://launchpad.net/~desktop-packages
Post to : desktop-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~desktop-packages
More help : https://help.launchpad.net/ListHelp
