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
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
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
* 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
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
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).
* 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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
21 matches
Mail list logo
