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 th
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).
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 p
* 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 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-activa
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 Thu, 7 Feb 2013, Thomas Goirand 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 t
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)
> > > N
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
> > > (
2013/2/6 Chow Loong Jin :
> 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 th
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-xa
Quoting Jonathan Dowland (j...@debian.org):
> On 6 Feb 2013, at 17:37, Andrey Rahmatullin 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
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,
L
On 6 Feb 2013, at 17:37, Andrey Rahmatullin 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
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 sec
On 02/06/2013 05:03 PM, Chow Loong Jin wrote:
> On 06/02/2013 16:27, Martin Wuertele wrote:
>> * Shawn [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)
Chow Loong Jin 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 unprivile
On 06/02/2013 16:27, Martin Wuertele wrote:
> * Shawn [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
* Shawn [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 UNSUBSCR
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
20 matches
Mail list logo
