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 Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1392012
Title:
[MIR] libteam
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/libteam/+bug/1392012/+subscriptions
--
ubuntu-bugs mailing list
[email protected]
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
