Re: socket-based activation has unmaintainable security?
Russ Allbery writes (Re: socket-based activation has unmaintainable security?): For INN, quite some time ago, I wrote a setuid helper program that did nothing but bind the port for its parent process. I know there are a few other implementations of the same idea (I think Ian Jackson has a generic one that's packaged in Debian). Yes, it's called authbind and it does seem to be that at least some people use it as I occasionally get bug reports. It's not completely trivial, since you have to use two different techniques depending on whether the OS uses BSD-style sockets or STREAMS-style sockets (in BSD-style sockets you can bind in the child and the parent sees the results, but with STREAMS-style sockets you pass the file descriptor back to the parent), Seriously ? Wow. authbind doesn't support that nonsense semantic which you say STREAMS-based systems have. Ian. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20771.42913.768249.687...@chiark.greenend.org.uk
Re: socket-based activation has unmaintainable security?
On Thu, Feb 07, 2013 at 10:28:28AM +1100, Russell Coker wrote: Such capabilities allow the process to bind to all low ports, which usually isn't what you desire. If you want to permit a daemon to bind to exactly one reserved port and no others then it seems that the options are systemd (if the daemon supports socket based activation) and SE Linux. (x)inetd, no? Kind regards Philipp Kern signature.asc Description: Digital signature
Re: socket-based activation has unmaintainable security?
On 07/02/13 09:39, Philipp Kern wrote: If you want to permit a daemon to bind to exactly one reserved port and no others then it seems that the options are systemd (if the daemon supports socket based activation) and SE Linux. (x)inetd, no? For completeness: the systemd socket-activation protocol does not strictly require systemd as your pid 1 (it's basically just a generalization of the inetd protocol to allow for more than one socket to be passed simultaneously, and leave stdout/stderr available for logging/warnings from the daemon). Any inetd could gain support for systemd-compatible socket-activation, in principle. The reference implementation of socket activation in libsystemd-daemon is #ifdef'd out when not on Linux, but it's hardly rocket science: $LISTEN_PID is the decimal process ID for which the sockets are intended (so that its child processes will ignore $LISTEN_FDS even if it's not removed from the environment), $LISTEN_FDS is a decimal integer, and fds 3 up to 3+$LISTEN_FDS-1 are the sockets to listen on. Regards, S -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/5113a237.5050...@debian.org
Re: socket-based activation has unmaintainable security?
* Thomas Goirand: Which would be the wrong way of doing things / wrong reason for using root as running user, since you can set the CAP_NET_BIND_SERVICE capability... (man capabilities ...) This allows to bind to all lower ports, which in some cases is equivalent to root privileges. A more fine-grained mechanism is needed. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87r4kscmls@mid.deneb.enyo.de
Re: socket-based activation has unmaintainable security?
On Thursday 07 February 2013 10.39.59 Philipp Kern wrote: On Thu, Feb 07, 2013 at 10:28:28AM +1100, Russell Coker wrote: Such capabilities allow the process to bind to all low ports, which usually isn't what you desire. If you want to permit a daemon to bind to exactly one reserved port and no others then it seems that the options are systemd (if the daemon supports socket based activation) and SE Linux. (x)inetd, no? Yes but the xinetd process keeps the socket open, then on new connection forks and gives the service the fd of the new connection, retaining the fd for the listener part. Which means that on every connection it has to fork (and that's extremely slow). -- Salvo Tomaselli signature.asc Description: This is a digitally signed message part.
Re: socket-based activation has unmaintainable security?
On Thu, 7 Feb 2013, Salvo Tomaselli wrote: Yes but the xinetd process keeps the socket open, then on new connection forks and gives the service the fd of the new connection, retaining the fd for the listener part. Which means that on every connection it has to fork (and that's extremely slow). Only true for nowait entries. wait entries will pass the listening socket to the process which then accepts connections itself. -- Edward Allcutt -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/alpine.deb.2.02.1302071512200.20...@pandora.retrosnub.co.uk
Re: socket-based activation has unmaintainable security?
* Shawn shawnland...@gmail.com [2013-02-05 18:43]: socket-activation in systemd _helps_ security in that you can give an unprivlidged process a listening port under 1024. (using a privileged configuration file) Privileged vs. unprivileged port is not really a secuitry improvement. Yours Martin -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130206082757.gc24...@anguilla.debian.or.at
Re: socket-based activation has unmaintainable security?
On 06/02/2013 16:27, Martin Wuertele wrote: * Shawn shawnland...@gmail.com [2013-02-05 18:43]: socket-activation in systemd _helps_ security in that you can give an unprivlidged process a listening port under 1024. (using a privileged configuration file) Privileged vs. unprivileged port is not really a secuitry improvement. I think he's referring to allowing processes which require listening to a port under 1024 to run without superuser privileges. I believe our implementation on Debian (e.g. Apache) is to have the process start as root, start listening, and then setuid to an unprivileged user. -- Kind regards, Loong Jin signature.asc Description: OpenPGP digital signature
Re: socket-based activation has unmaintainable security?
Chow Loong Jin hyper...@debian.org writes: I think he's referring to allowing processes which require listening to a port under 1024 to run without superuser privileges. I believe our implementation on Debian (e.g. Apache) is to have the process start as root, start listening, and then setuid to an unprivileged user. For INN, quite some time ago, I wrote a setuid helper program that did nothing but bind the port for its parent process. I know there are a few other implementations of the same idea (I think Ian Jackson has a generic one that's packaged in Debian). I've always been surprised that more long-running daemons that for one reason or another need to set up their own listening ports don't use that technique. I think it's more secure than starting the whole complex daemon as root and then dropping privileges. It's not completely trivial, since you have to use two different techniques depending on whether the OS uses BSD-style sockets or STREAMS-style sockets (in BSD-style sockets you can bind in the child and the parent sees the results, but with STREAMS-style sockets you pass the file descriptor back to the parent), but it was only 219 lines of C (without comments) for the helper program and another 30 or so for the library to call it, and most of the helper program size is argument parsing and verification. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87halpdbwb@windlord.stanford.edu
Re: socket-based activation has unmaintainable security?
On 02/06/2013 05:03 PM, Chow Loong Jin wrote: On 06/02/2013 16:27, Martin Wuertele wrote: * Shawn shawnland...@gmail.com [2013-02-05 18:43]: socket-activation in systemd _helps_ security in that you can give an unprivlidged process a listening port under 1024. (using a privileged configuration file) Privileged vs. unprivileged port is not really a secuitry improvement. I think he's referring to allowing processes which require listening to a port under 1024 to run without superuser privileges. I believe our implementation on Debian (e.g. Apache) is to have the process start as root, start listening, and then setuid to an unprivileged user. Which would be the wrong way of doing things / wrong reason for using root as running user, since you can set the CAP_NET_BIND_SERVICE capability... (man capabilities ...) Thomas P.S: I know this since the nice talk from Luciano last summer at debconf! :) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/51129451.3070...@debian.org
Re: socket-based activation has unmaintainable security?
On Thu, Feb 07, 2013 at 01:35:13AM +0800, Thomas Goirand wrote: socket-activation in systemd _helps_ security in that you can give an unprivlidged process a listening port under 1024. (using a privileged configuration file) Privileged vs. unprivileged port is not really a secuitry improvement. I think he's referring to allowing processes which require listening to a port under 1024 to run without superuser privileges. I believe our implementation on Debian (e.g. Apache) is to have the process start as root, start listening, and then setuid to an unprivileged user. Which would be the wrong way of doing things / wrong reason for using root as running user, since you can set the CAP_NET_BIND_SERVICE capability... (man capabilities ...) Do we finally have mechanisms to start processes without root but with elevated capabilities? -- WBR, wRAR signature.asc Description: Digital signature
Re: socket-based activation has unmaintainable security?
On 6 Feb 2013, at 17:37, Andrey Rahmatullin w...@wrar.name wrote: Do we finally have mechanisms to start processes without root but with elevated capabilities? We also need fallback for non Capability-capable supported kernels (wow that's an awkward sentence) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/a2ec83dc-57b2-474b-b56b-5d0225a0c...@debian.org
Re: socket-based activation has unmaintainable security?
On 07/02/2013 01:35, Thomas Goirand wrote: Which would be the wrong way of doing things / wrong reason for using root as running user, since you can set the CAP_NET_BIND_SERVICE capability... (man capabilities ...) Yeah, I figured as much, but isn't that a Linuxism? -- Kind regards, Loong Jin signature.asc Description: OpenPGP digital signature
Re: socket-based activation has unmaintainable security?
Quoting Jonathan Dowland (j...@debian.org): On 6 Feb 2013, at 17:37, Andrey Rahmatullin w...@wrar.name wrote: Do we finally have mechanisms to start processes without root but with elevated capabilities? We also need fallback for non Capability-capable supported kernels (wow that's an awkward sentence) Not to mention non-xattr-backed filesystems. Every time I've been in a discussion like this, that ends up being the reason not to pursue it. -serge -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130206183028.GB19018@sergelap
Re: socket-based activation has unmaintainable security?
On Wed, Feb 06, 2013 at 12:30:28PM -0600, Serge Hallyn wrote: Do we finally have mechanisms to start processes without root but with elevated capabilities? We also need fallback for non Capability-capable supported kernels (wow that's an awkward sentence) Not to mention non-xattr-backed filesystems. xattrs is only one of possible mechanisms but as we don't have it either, its shortcomings are probably not worth mentioning. -- WBR, wRAR signature.asc Description: Digital signature
Re: socket-based activation has unmaintainable security?
2013/2/6 Chow Loong Jin hyper...@debian.org: On 07/02/2013 01:35, Thomas Goirand wrote: Which would be the wrong way of doing things / wrong reason for using root as running user, since you can set the CAP_NET_BIND_SERVICE capability... (man capabilities ...) Yeah, I figured as much, but isn't that a Linuxism? illumos (OpenSolaris) kernel has privileges [1] So some services (can't remember which) are not started as root at all. [1] http://illumos.org/man/5/privileges -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/call-q8y0ui+tv7fzsyjyuo1vsyydd2xaehvmhywu4oy6tov...@mail.gmail.com
Re: socket-based activation has unmaintainable security?
Quoting Andrey Rahmatullin (w...@wrar.name): On Wed, Feb 06, 2013 at 12:30:28PM -0600, Serge Hallyn wrote: Do we finally have mechanisms to start processes without root but with elevated capabilities? We also need fallback for non Capability-capable supported kernels (wow that's an awkward sentence) Not to mention non-xattr-backed filesystems. xattrs is only one of possible mechanisms but as we don't have it either, its shortcomings are probably not worth mentioning. For posix capabilities attached to files xattrs are currently the only means. That's what I assumed this was referring to. -serge -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130206212009.GA18337@sergelap
Re: socket-based activation has unmaintainable security?
On Wed, Feb 06, 2013 at 03:20:09PM -0600, Serge Hallyn wrote: Do we finally have mechanisms to start processes without root but with elevated capabilities? We also need fallback for non Capability-capable supported kernels (wow that's an awkward sentence) Not to mention non-xattr-backed filesystems. xattrs is only one of possible mechanisms but as we don't have it either, its shortcomings are probably not worth mentioning. For posix capabilities attached to files xattrs are currently the only means. That's what I assumed this was referring to. I suppose there can be other theoretical means to do that with a privileged helper (and /sbin/init is privileged, for example). -- WBR, wRAR signature.asc Description: Digital signature
Re: socket-based activation has unmaintainable security?
On Thu, 7 Feb 2013, Thomas Goirand z...@debian.org wrote: I think he's referring to allowing processes which require listening to a port under 1024 to run without superuser privileges. I believe our implementation on Debian (e.g. Apache) is to have the process start as root, start listening, and then setuid to an unprivileged user. Which would be the wrong way of doing things / wrong reason for using root as running user, since you can set the CAP_NET_BIND_SERVICE capability... (man capabilities ...) Such capabilities allow the process to bind to all low ports, which usually isn't what you desire. If you want to permit a daemon to bind to exactly one reserved port and no others then it seems that the options are systemd (if the daemon supports socket based activation) and SE Linux. -- My Main Blog http://etbe.coker.com.au/ My Documents Bloghttp://doc.coker.com.au/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201302071028.28586.russ...@coker.com.au
socket-based activation has unmaintainable security?
One of the most interesting statements in the recent udev discussion was Steve Langasek's claim that socket-based activation has fundamentally unmaintainable security. A couple people have asked for clarification and I would also like to know what problem Steve was referring to. Can someone please give me the golden clue? -- Thomas Hood -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/5110dcec.4010...@gmail.com
Re: socket-based activation has unmaintainable security?
socket-activation in systemd _helps_ security in that you can give an unprivlidged process a listening port under 1024. (using a privileged configuration file) -Shawn Landden