Re: [PATCH]: Linux Transparent Proxy

On Tue, 2003-03-11 at 13:08, Henrik Nordstrom wrote:
> 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.

I was kinda hoping for something like:

        if ( geteuid() == 0 ) {
                cap_keep_mask(CAP_NET_RAW);
                setuid(nonroot);
        }

That way the service (with minimal kludgery) can keep what it needs and
drop the rest, this has the advantage of being easy, nearly all programs
which require some super-user power do this kind of thing but they don't
get to keep the privs, they can just keep fds and other per-process data
structures.

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

Sounds racy. If you get a SYN for svr1 and start connecting, by the time
the connect succeeds you could have got a RST and a new SYN to svr2,
when you come back to accept you will accept the wrong connection. Even
if you watch for RSTs there is always a window for a race condition
between connecting to the server and calling the accept as the RST can
be received *inside* the accept() system call and of course the earliest
time you can know is right after you already accepted the wrong
connection.

I am convinced that the only 100% solution has to be done in kernel
space. That is not to say you can't get a good 99% solution with
existing interfaces.

> 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).

Well theoretically it is possible (just not with that interface). You
just send a SYN to the server when you get one from a client and send
the SYN-ACK back to the client only when you have it from the server.
The end server needs syncookies available of course, where as with the
current code it doesn't.

In fact for one of our clients just putting squid in front of their
servers and enabling syncookies allowed them to operate through a
synflood attack which until then had crippled their windows servers.
This is a great advantage to the current model :)

-- 
// Gianni Tedesco (gianni at scaramanga dot co dot uk)
lynx --source www.scaramanga.co.uk/gianni-at-ecsc.asc | gpg --import
8646BE7D: 6D9F 2287 870E A2C9 8F60 3A3C 91B5 7669 8646 BE7D