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 <[EMAIL PROTECTED]> MARA Systems AB, Sweden
