Re: socket-based activation has unmaintainable security?

2013-02-19 Thread Ian Jackson
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?

2013-02-07 Thread Philipp Kern
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?

2013-02-07 Thread Simon McVittie
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?

2013-02-07 Thread Florian Weimer
* 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?

2013-02-07 Thread Salvo Tomaselli
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?

2013-02-07 Thread Edward Allcutt

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?

2013-02-06 Thread Martin Wuertele
* 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?

2013-02-06 Thread Chow Loong Jin
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?

2013-02-06 Thread Russ Allbery
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?

2013-02-06 Thread Thomas Goirand
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?

2013-02-06 Thread Andrey Rahmatullin
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?

2013-02-06 Thread Jonathan Dowland
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?

2013-02-06 Thread 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 that a Linuxism?

-- 
Kind regards,
Loong Jin



signature.asc
Description: OpenPGP digital signature


Re: socket-based activation has unmaintainable security?

2013-02-06 Thread Serge Hallyn
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?

2013-02-06 Thread Andrey Rahmatullin
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-02-06 Thread Игорь Пашев
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?

2013-02-06 Thread Serge Hallyn
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?

2013-02-06 Thread Andrey Rahmatullin
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?

2013-02-06 Thread Russell Coker
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?

2013-02-05 Thread Thomas Hood
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?

2013-02-05 Thread Shawn
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