Comment 5 for bug 1252374

Revision history for this message
Seth Arnold (seth-arnold) wrote :

I reviewed beanstalkd version 1.9-1 as checked into trusty. This should
not be considered a full security audit but rather a quick gauge of
maintainability.

- Beanstalk provides a simple, unauthenticated, work queue mechanism;
  producers add jobs to the queue, consumers remove jobs from the queue.
  The protocol is plain-ascii with application-agnostic data formats
  inspired by memcached's simple protocol.
- Build-depends libtool, net-tools, dh-systemd
- Depends adduser, netbase
- No cryptography
- Extensive networking
- No library dependencies
- Does not daemonize, relies upon start-stop-daemon or systemd
- Pre/post inst/rm scripts clean up after adding new user, adding
  initscript
- Initscript starts and stops the daemon, manages pid file, etc
- No dbus
- No setuid
- Provides /usr/sbin/beanstalkd executable
- No sudo
- No udev
- No cron
- Clean build logs
- Moderate test suite run at build time

- No process spawning outside test suite
- Memory management is clean, allocations are checked for errors
- A on-disk journal is maintained that can recover from unexpected
  restarts
- Logging functions looked safe
- Environment variable handling was mostly related to systemd, looked safe
- Privilege dropping forgot to clear supplementary groups, however the
  functionality isn't used in Debian and derived systems
- No cryptography
- Network input is carefully parsed
- No temporary file handling outside test suite
- No WebKit
- No PolicyKit

The code is high-quality; much of it is beautiful.

I found three very slight issues while reading the code:

- Doesn't drop supplementary groups
- listen(2) is called on the server socket twice
- A check for truncated tube names doesn't function
  https://github.com/kr/beanstalkd/issues/224

The privilege dropping code is not the usual use of beanstalkd in Debian
and derived distributions. Calling listen(2) twice on a socket is likely a
no-op on all major platforms.

When filing the issue for incorrectly determining if a tube name was
truncated, I did see several other issues were filed with inconsistencies
surrounding tube names around 190 characters and longer; an application
author would be wise to limit tube names to something shorter. I did not
see any security-relevant issues with long names.

One potential downside to beanstalkd is the complete lack of
authentication and authorization. This does somewhat limit the
applications where beanstalkd could be applied.

Security team ACK for promoting beanstalkd to main.

Thanks