Re: [PATCH]: Linux Transparent Proxy

tis 2003-03-11 klockan 12.16 skrev Gianni Tedesco:

> Yeah that is what the current check is but as I say this is pretty
> useless unless the capability system allows for dropping root privs
> while keeping CAP_NET_ADMIN. I'm not too familiar with the capability
> syscalls so I'll take a look. Either way CAP_NET_ADMIN is quite a lot of
> extra power, would prefer a little finer granularity :)

The granularity issue is a general problem of the capability sub system.
There only is 32 capabilities in the kernel..

Looking at the list of capabilities CAP_NET_RAW is probably more proper
for TPROXY. Gives capabilities similar to that of the function of TPROXY
(allows sending of spoofed packets, interception etc) without allowing
other reconfiguration of the networking subsystem.

The root privs issue is due to the lack of a sane method for giving
applications capabilities. The intention of the capability subsystem is
that capabilities is controlled in three manners

  a) Be given to the application by init or other master daemon. This
should typically be the case for system services requiring certain
capabilities such as a Squid TPROXY, or a webserver needing to bind to
ports < 1024.

  b) Be given to the application by root "signing" the binary in the
filesystem as trusted for the capability. This should typically be used
for applications users should run requiring special privileges. For
example /bin/ping which requires CAP_NET_RAW but has to be suid root
today..

  c) Root applications may drop any capabilities they do not need.

Of the three only the last is somewhat functioning in a stock Linux
system, but it is actually the other two methods which makes
capabilities interesting as a security tool as they provide means
whereby limited trust can be given to applications or services.

> Yeah, what I think is needed is an API that allows you to retrieve the
> original destination address without accepting the connection, then you
> can connect out and only accept the client connection if the server
> accepts. I don't see how you can get a sane way of doing this based on
> the standard sockets API.

This you should be able to do today by using QUEUE in combination with
TPROXY. Send the SYN packets via QUEUE to the application, which looks
into the packet and initiates a connection to the origin server. When
the origin server has accepted the connection the application instructs
QUEUE to accept the packet, and the client SYN handshake will continue
and when completed ending up as a socket sent to the application via
TPROXY..

I see no direct reason to modify TPROXY or the TCP kernel for this given
that QUEUE already exists.

Major warning: Working with half accepted connections also means you
must also deal with SYN flood protection manually which will not be an
easy task if you only have the SYN packet to look at... (the client will
regard the connection as ESTABLISHED if you answer with SYN+ACK).

-- 
Henrik Nordstrom <hno@squid-cache.org>
MARA Systems AB, Sweden