I reviewed cgmanager version 0.20-0ubuntu3 as checked into trusty. This
should not be considered a full security audit but rather a quick gauge of
maintainability.
cgmanager provides a userspace manager for cgroups; the Linux kernel
provides cgroups as a resource management interface and access control
mechanism but does not provide any mechanism for nesting cgroup users.
cgmanager provides both a proxy and a controller, allowing nested users
to request cgroup limits within the extents of their own limits. The
interface for nested users is via dbus.
- Build-Depends: autotools-dev, debhelper, dh-autoreconf, hardening-wrapper,
help2man, libdbus-1-dev, libnih-dbus-dev, libnih-dev, libtool,
nih-dbus-tool, pkg-config
- No cryptography
- Only AF_UNIX, dbus, networking
- Provides DBus services on /sys/fs/cgroup/cgmanager/sock
- Runs as root
- Uses libnih to daemonize, assumed correct
- pre- and post- scripts automatically generated
- init scripts start cgmanager or cgproxy
- No dbus system-services files
- No setuid executables
- Installs cgmanager and cgproxy daemons into /sbin/
- No sudo fragments
- No udev rules
- Runtime tests are provided in cgmanager-tests package, can't be run
during build but should be easy to autopkgtest with them
- No cron jobs
- Clean build logs
- No subprocesses are spawned
- Memory management is careful, nih routines used
- File operations are usually synthetic kernel files, restricted scope
- Logging operations are careful
- No use of environment variables
- Privileged operations work on cgroup kernel files, looked careful
- No cryptography
- AF_UNIX and DBus networking used, looked careful
- All code runs as root
- No temporary files used
- No webkit
- No javascript
- Clean cppcheck
- No PolicyKit
- get_pid_scm_complete() char *output is not marked nih_local, this looks
like a memory leak.
The cgmanager code is very defensive. Error returns are checked and
thoughtful error messages are provided for nearly every exceptional event.
The code is highly repetitive, so it would be possible for a potential
problem to be duplicated many times throughout the codebase; if we need
to perform maintenance tasks in the future we'll need to be careful to
look for other occurrences of the hypothesized fault. (This is common to
many programs that use Dbus, so it's not unexpected.)
Security team ACK for promoting cgmanager to main. I suggest not
promoting cgmanager-tests -- there is extensive use of sudo in dozens
of test scripts and I didn't inspect any of them for safety.
I reviewed cgmanager version 0.20-0ubuntu3 as checked into trusty. This
should not be considered a full security audit but rather a quick gauge of
maintainability.
cgmanager provides a userspace manager for cgroups; the Linux kernel
provides cgroups as a resource management interface and access control
mechanism but does not provide any mechanism for nesting cgroup users.
cgmanager provides both a proxy and a controller, allowing nested users
to request cgroup limits within the extents of their own limits. The
interface for nested users is via dbus.
- Build-Depends: autotools-dev, debhelper, dh-autoreconf, hardening-wrapper, cgroup/ cgmanager/ sock
help2man, libdbus-1-dev, libnih-dbus-dev, libnih-dev, libtool,
nih-dbus-tool, pkg-config
- No cryptography
- Only AF_UNIX, dbus, networking
- Provides DBus services on /sys/fs/
- Runs as root
- Uses libnih to daemonize, assumed correct
- pre- and post- scripts automatically generated
- init scripts start cgmanager or cgproxy
- No dbus system-services files
- No setuid executables
- Installs cgmanager and cgproxy daemons into /sbin/
- No sudo fragments
- No udev rules
- Runtime tests are provided in cgmanager-tests package, can't be run
during build but should be easy to autopkgtest with them
- No cron jobs
- Clean build logs
- No subprocesses are spawned
- Memory management is careful, nih routines used
- File operations are usually synthetic kernel files, restricted scope
- Logging operations are careful
- No use of environment variables
- Privileged operations work on cgroup kernel files, looked careful
- No cryptography
- AF_UNIX and DBus networking used, looked careful
- All code runs as root
- No temporary files used
- No webkit
- No javascript
- Clean cppcheck
- No PolicyKit
More than usual lintian complaints: does-not- call-updaterc. d-for-init. d-script etc/init.d/cgproxy script- not-marked- as-conffile etc/init.d/cgproxy script- not-included- in-package etc/init.d/cgproxy has-useless- whatis- entry usr/share/ man/man8/ cgmanager. 8.gz has-useless- whatis- entry usr/share/ man/man8/ cgproxy. 8.gz
E: cgmanager: postrm-
W: cgmanager: init.d-
E: cgmanager: init.d-
W: cgmanager: manpage-
W: cgmanager: manpage-
N: 3 tags overridden (2 errors, 1 warning)
A few other small things that I noticed:
- Some failure cases don't have logging: children( ) snprintf() hierarchy( ) snprintf()
setup_base_path() !base_path
set_clone_
set_use_
- do_move_pid_main() fprintf() error message slightly incorrect
- get_pid_ scm_complete( ) char *output is not marked nih_local, this looks
like a memory leak.
The cgmanager code is very defensive. Error returns are checked and
thoughtful error messages are provided for nearly every exceptional event.
The code is highly repetitive, so it would be possible for a potential
problem to be duplicated many times throughout the codebase; if we need
to perform maintenance tasks in the future we'll need to be careful to
look for other occurrences of the hypothesized fault. (This is common to
many programs that use Dbus, so it's not unexpected.)
Security team ACK for promoting cgmanager to main. I suggest not
promoting cgmanager-tests -- there is extensive use of sudo in dozens
of test scripts and I didn't inspect any of them for safety.
Thanks