unix

• Mon, 22 Jul 2013

  Daemonizing while dropping privileges

  Posted: Mon, 22 Jul 2013

  We talked about chroot jails the last time daemonization came up. This time we’re talking about privileges and what it means to drop them.

  

  All users are equal, but some users are more equal than others. If something can be done, root can do it, and some actions can only be done by root. Root is the only user that can bind to any port under 1024 on a unix or linux host. Apache, or Nginx, or AOLServer can only bind to port 80 and 443 for the sake of serving web pages if the processes start as the root user.

  Running a webserver as root is fine until someone finds a remote exploit in the ancient version of Apache that serves your site because patching is lame and it hurts your uptime. At that point a remote exploit will take over the root owned web server process and have practically unlimited access to the system.

  That’s why dropping privileges is a thing we can do. A process can start with root privileges, do just the things that require root privileges, then immediately give up those privileges and switch to an unprivileged account. Now a remote exploiter will only have control of a process running as an unprivileged account, and they’ll need to put time into finding a root escalation attack rather than jumping right in to pilfering data from the system.

  One note: users can belong to as many groups as the system administrator sees fit. Run the groups command right now to see what groups you belong to::

  $ groups
  tim adm audio video libvirtd admin
  

  A process that starts life as a root owned process and drops privileges may not make it through to the other side in all of those groups. For instance, processes daemonized with the Python-LUST toolkit will only belong to the group explicitly specified in the daemon configuration file. If your process uses resources belonging to multiple groups in development, you may find that it stops working when deployed to production and daemonized as a process that drops privileges during start up.

  And just for the record, there’s no excuse for not patching.

  Daemonizing while dropping privileges
  • programming
  • unix
• Tue, 09 Jul 2013

  Daemonizing with chroot jails

  Posted: Tue, 09 Jul 2013

  Diffenbach runs in two modes: debug mode, where it stays attached to the current session and terminal, and daemon mode, where it detaches and runs silently in the background. Now it does, at least.

  Until a week ago it only ever ran in debug mode in a tmux session. That’s pretty lame. The daemonization with Python-LUST was “done” in that hand wavy sense that some developers use. I had written the code, but I hadn’t tested it and worked out all of the kinks. Julython came to the rescue, and the Python-LUST integration started working five commits later.

  Python-LUST defaults to dropping processes into a chroot jail. This restricts the running process to a tiny slice of the entire file system defined in the process’s configuration file, and it limits several attack vectors including path traversal and exploitation of local binaries.

  File descriptors that are opened before the chroot call are carried into the chroot environment. Any files or commands that are needed at any time during the execution of the program must either be opened before the chroot call or be available within the limited chroot environment.

  This includes log files, python modules, output directories, and external commands called through the os.system interface, and anything that isn’t opened ahead of time or available within the chroot will result in a thrown exception.

  I decided to forgo the chroot capabilities of the Python-LUST library for two reasons:

  1. Diffenbach makes explicit use of external binaries that require additional shared libraries. The footprint of the chroot environment gets big enough to negate many of the benefits of running within a chroot environment. I could compile a static binary of gphoto2 if I really wanted to run Diffenbach in a chroot environment.

  2. Diffenbach is the only custom daemon running on its server, and it doesn’t run arbitrary code or commands fed to it via remote interfaces. That significantly lowers the threat level.

  I also learned a bit about how dropping privileges works, but I’ll save that for my next post. Subscribe if you’re interested in learning more.

  Daemonizing with chroot jails
  • programming
  • unix