allow process or user to listen on priviledged ports?

allow process or user to listen on priviledged ports?

[Sven Köhler]

Hi,

don't blame me for asking such a question in the LKML, but i already 
asked it in other linux-newsgroups. i haven't got any real answer yet.

my problem is, that i want an application to listen on a priviledged 
port (e.g. port 80) and to run as a "normal" unpriviledged user (e.g. 
wwwrun). Well - how? The application is not a C/C++-application, so i 
cannot ask the author (myself) to implement a mechanism to switch the 
userid (e.g. like apache does it).

So is there any machanism to bind that permission (to listen on a 
priviledged tcp-port) to a specific user or a specific process?

The application is written in Java. Of course Java could implement 
userid-switching, but the linux could also have an ACL for that. So 
please don't answer with "go and ask Sun for that feature". I already 
considered that.

Thx
   Sven

Re: allow process or user to listen on priviledged ports?

[Michael Buesch]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Wednesday 24 December 2003 17:43, Sven Köhler wrote:
> Hi,

Hi Sven,

> So is there any machanism to bind that permission (to listen on a
> priviledged tcp-port) to a specific user or a specific process?

I think (AFAIK) either grsec or selinux (or both) have the
ability to make the kernel accepting binds to those
privileged ports as normal user.

>
> Thx
>    Sven

- -- 
Regards Michael Buesch  [ http://www.tuxsoft.de.vu ]

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)

iD8DBQE/6caxFGK1OIvVOP4RAupiAJ0SewsaODhJK8uQmmeQwEV8tGxp4QCfW4Fd
epUXG6pd5lERWvEIC+Ok7W0=
=7G/F
-----END PGP SIGNATURE-----

Re: allow process or user to listen on priviledged ports?

[Olaf Dietsche]

Sven Köhler <skoehler@upb.de> writes:

> my problem is, that i want an application to listen on a priviledged
> port (e.g. port 80) and to run as a "normal" unpriviledged user
>
> So is there any machanism to bind that permission (to listen on a
> priviledged tcp-port) to a specific user or a specific process?

Of course, there is :-)
<http://www.olafdietsche.de/linux/accessfs/>

Regards, Olaf.

Re: allow process or user to listen on priviledged ports?

[Adam Sampson]

Sven Köhler <skoehler@upb.de> writes:

> So is there any machanism to bind that permission (to listen on a
> priviledged tcp-port) to a specific user or a specific process?

Even if you can't find a way to do this, you can cheat: use an
iptables DNAT rule to translate connections to the desired port into
connections to a non-privileged port upon which your daemon is
actually listening. Something like:

iptables -t nat -A PREROUTING -p tcp --dport 80 -j DNAT --to 1.2.3.4:8080

-- 
Adam Sampson <azz@us-lot.org>                        <http://offog.org/>

Re: allow process or user to listen on priviledged ports?

[Thomas Zehetbauer]

[-- Attachment #1: Type: text/plain, Size: 364 bytes --]

I used this approach for some time but unfortunately IPv6 has only
inherited the privileged ports problem but not the iptables solution.

Regards
Tom

-- 
  T h o m a s   Z e h e t b a u e r   ( TZ251 )
  PGP encrypted mail preferred - KeyID 96FFCB89
       mail pgp-key-request@hostmaster.org

If there is a god, you are an authorized representative.

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 481 bytes --]

Re: allow process or user to listen on priviledged ports?

[Eric]

On Wednesday 24 December 2003 03:34 pm, Adam Sampson wrote:
> Sven Köhler <skoehler@upb.de> writes:
> > So is there any machanism to bind that permission (to listen on a
> > priviledged tcp-port) to a specific user or a specific process?
>
> Even if you can't find a way to do this, you can cheat: use an
> iptables DNAT rule to translate connections to the desired port into
> connections to a non-privileged port upon which your daemon is
> actually listening. Something like:
>
> iptables -t nat -A PREROUTING -p tcp --dport 80 -j DNAT --to 1.2.3.4:8080
 Not to be too picky, but I think the redirect target is better suited for 
this. I haven't seen the source, but I assume it will be more efficient 
because it knows the destination is the local machine. 
iptables -t nat -A PREROUTING -p tcp --dport 80 -j REDIRECT --to-ports 22
-------------------------
Eric Bambach
Eric at cisu dot net
-------------------------

Re: allow process or user to listen on priviledged ports?

[Nick Craig-Wood]

On Wed, Dec 24, 2003 at 05:43:09PM +0100, Sven K?hler wrote:
> my problem is, that i want an application to listen on a priviledged 
> port (e.g. port 80) and to run as a "normal" unpriviledged user

I would give your application this capability (from #include "linux/capability.h")

  /* Allows binding to TCP/UDP sockets below 1024 */
  /* Allows binding to ATM VCIs below 32 */

  #define CAP_NET_BIND_SERVICE 10

You do this with a setuid wrapper which drops all capabilities but
that one and then runs your application.

One day there will be a way of doing this in the filing system, so
instead of doing a chmod u+s you do a chmod +CAP_NET_BIND_SERVICE or
something!  Until then use a setuid wrapper....

Here is a FAQ

  http://ftp.kernel.org/pub/linux/libs/security/linux-privs/kernel-2.4/capfaq-0.2.txt

Actually the FAQ mentions sucap which seems to be a fairly standard
program (its in Debian anyway!).  You could use this too...

-- 
Nick Craig-Wood
ncw1@axis.demon.co.uk

Re: allow process or user to listen on priviledged ports?

[Sven Köhler]

> I would give your application this capability (from #include "linux/capability.h")
> 
>   /* Allows binding to TCP/UDP sockets below 1024 */
>   /* Allows binding to ATM VCIs below 32 */
> 
>   #define CAP_NET_BIND_SERVICE 10
> 
> You do this with a setuid wrapper which drops all capabilities but
> that one and then runs your application.

Thx for the answer! That's exactly what i search for.

I will try to write such a program. It seems that sucap keeps all 
capabilities and drops none. Depending on the other capabilities, that 
could be a bad idea.

Thx
   Sven

Re: allow process or user to listen on priviledged ports?

[Sven Köhler]

>> I would give your application this capability (from #include 
>> "linux/capability.h")
>>
>>   /* Allows binding to TCP/UDP sockets below 1024 */
>>   /* Allows binding to ATM VCIs below 32 */
>>
>>   #define CAP_NET_BIND_SERVICE 10
>>
>> You do this with a setuid wrapper which drops all capabilities but
>> that one and then runs your application.
> 
> Thx for the answer! That's exactly what i search for.

Unfortunatly my gladness didn't last long. The FAQ at
http://ftp.kernel.org/pub/linux/libs/security/linux-privs/kernel-2.4/capfaq-0.2.txt 
states that CAP_SETPCAP is disabled, but it doesn't say why it is 
disapled. That capability is needed by sucap to work.

So why is CAP_SETPCAP disabled by default?