Opened 12 years ago

Closed 11 years ago

Last modified 11 years ago

#2189 closed Enhancement (invalid)

Securing T Daemon

Reported by: Elbandi Owned by:
Priority: Normal Milestone: None Set
Component: Daemon Version: 1.70
Severity: Normal Keywords:


If daemon runs on a server HW, someone want to make it more secure: "jail" the daemon into a dir. In linux, this is easy with chroot. Chroot need root privileges, so after chroot the daemon drop privileges.

But with chroot, there is a problem: the daemon cannot access to web files. (index.html, *.js, *.gif, etc). There are some solution for this:

  • copy the web files into the right place in chroot dir
  • the web files are served by the normal webserver (apache, lighttpd), the rpc calls are proxied to T (mod_proxy)

(the "chroot method" is based on profix chroot_uid)

Attachments (1)

chroot-daemon.patch (4.0 KB) - added by Elbandi 12 years ago.

Download all attachments as: .zip

Change History (6)

Changed 12 years ago by Elbandi

comment:1 Changed 12 years ago by charles

I kind of like this idea, but this feels like a solution in search of a problem -- nobody's asking for this, no other torrent apps have built-in support for this, and anyone wanting to run transmission-daemon in a chroot jail can use the chroot(8) wrapper.

comment:2 Changed 12 years ago by charles

  • Resolution set to invalid
  • Status changed from new to closed

comment:3 Changed 11 years ago by User294

  • Resolution invalid deleted
  • Status changed from closed to reopened

I found that you've closed my bug #3108 as duplicate so I would reopen this one, because:

1) Well, let's me ask for this, too :). Right now I'm using my own weird patch to do this. It's nice to see someone wrote a much better implementation in a patch, though I have learned a bit about syscalls as a result.

2) Using chroot wrapper is inconvenient because you have to put all required shared libs to chroot dir, because with wrapper first chroot() call done and only then shared lib dependencies are resolved. This makes things inconvenient, to say the least. What worse, usually you have to maintain security of these libs on your own (since package manager can't handle them in new place anymore). And you can get a number of strange/obscure issues and quirks if you're not a dependencies tracking guru. This raises bar so high that almost nobody would bother with a securing their Transmission installation. Which is a Bad Thing (tm). And after all, program inherently knows better when it has completed it's startup phase (which can require extra privileges/unrestricted access to filesystem) and when it's a good time to make things more secured, dropping unneeded privileges. For program it's a matter of roughly 3 syscalls. For admins that's a matter of huge headache.

3) This is a standard "good security practice" for a networked daemons. Virtually any decent networking daemon provides standard setuid+setgid+chroot options, be it httpd, ircd, ftpd, etc. I don't see reasons why torrent daemon should be anyhow worse when it comes to security stuff.

All these option are used to for example, use "privileged" ports in a secured manner and/or to limit harm when fatal flaw found in networked daemon which allows remote attacker to force daemon to do something harmful (for example, delete arbitrary directory) or to run it's own code. When chroot is in effect and non-root UID and GID used, hacker could generally only harm his "sandbox" rather than whole machine, potentially affecting other services.

comment:4 Changed 11 years ago by charles

  • Resolution set to invalid
  • Status changed from reopened to closed

I appreciate your thoughts on this, but stand by my original comment. Two users in 17 months, plus various portability questions, does not seem worthwhile.

comment:5 Changed 11 years ago by User294

Portability? Uhm, is it a joke? Or I missed something? As far as I can understand, daemon have to issue certain POSIX syscalls anyway? And setuid, setgid and chroot syscalls are available for ages as part of POSIX standard. I don't see how this could harm portability in a bad ways (is this anyhow worse than daemonization or syslog?). As for low popularity - ok, you're right. Most of users care very little about their security. Sad, but true.

Note: See TracTickets for help on using tickets.