Valdis.Kletnieksat_private: > On Thu, 09 Aug 2001 15:30:52 CDT, Jesse Pollard <pollardat_private> said: > > Ummm... telnet is a bad example (see below). And unless you're only > trying to address one *very* small part of a total picture here, you're > not really buying much - a large chunk of exploits (for example, CGI > script hacks) attack after your code would have been done with it. > > I'm not clear - is the intent here "build a sandboxed tcpwrapper"? > If so, what do you do about things like Apache or Sendmail that do their > own listen() but use libwrap.a for some front-ending? another problem :-) And yes - it is a sandboxed tcpwrapper with the following difference: The tcpwrappers do not examine the contents of the message, they only check the source/destination of the connection. This wrapper actually read/writes data to/from the user. The interpreted data is then forwarded to the helper application. As such, it is more of a "taint" analyser that is assumed to have a certain amount of bugs in it. > > The experiment is to completely isolate the network connection from being > > able to do anything if it gets compromized. Any attempt to perform > > disallowed system calls would terminate the process. > > This of course only protects the connection before authentication. You're > still wide open to session hijacking/packet insertion hacks AFTER the > authentication is finished, unless you use some crypto to secure the > connection first. If the attacker can sniff the connection anywhere along > the way (you aren't using 802.11 anyplace, are you? ;), he can watch the > telnet start, get a handle on the seq numbers in use, DDOS some router > along the way, and inject some packets. By the time the user realizes > that it's not just a router hiccup, the damage is done... > > Of course, that makes your authentication helper more complicated, as > it has to set up a crypto tunnel - which leaves you holding the bag on > how to hand off a already-in-progress encrypted session. ;) > > No, I'm not saying it's a DUMB idea - I'm just wondering if some other > better approach is called for. The Linux box I'm on right now doesn't > have any inetd-managed listen()s active.... Its more of a proof of concept, for handling initial I&A and authorization. It was a simple first step for telnet, since there is almost no other processing involved. The larger project is to have the TCP/IP layer interface to encryption/decryption via IPSec. New connections (also labeled) would be recieved with/without user identity labling. If no user identity is included (such as an SSL connection to a web server), then the unidentified connection would be intercepted by a handler to perform an I&A cycle. The handoff to an authenticator could be done through the TCP layer into the LSM, and passed to a specific authenticator. That authenticator would then make a challenge connection (still thinking on this one) back to the remote host, including an IPSec identifier to enter an authentication cycle. (Hopefully this is all invisible to the remote user - the IPSec identifier would have to be generated by the remote security module for inclusion in the header during the first connection). Using a "authentication" handshake (mediated by the "sandboxed" handlers) both systems could agree on a selected authentication method - certificates, or kerberos, or ... After successfully identifing and authorizing the remote user the local security module would be able to pass the connection to the designated server - in this case a web server. It would also be possible for the cycle to generate an IPSec user identity+session key that is shared by both hosts for future connections. As long as the IPSec layer ensures the confidentiality of the host-host context, this would speed up the next connection by passing the session key along with the already setup identifier. This gives the web server multiple methods of determining the remote user: a CGI (or the server itself) could use the identity to select returned data, used for accounting, able to set the servers UID to the authorized user ???? still thinking... how would that be passed to a slave server... ah - the socket ownership could be set to the identity of the remote user (UID of the user on the local host) while processing the socket (This assumes it would be possible to force the server process to switch UIDs, working directories?, and protection masks, ... performed by the security module of course) In a larger view, the whole thing would also be able to control whether the user is allowed to communicate and with which remote hosts. If the user is not allowed network connections no problem. If the user is allowed some hosts, but not others, the invisible handshaking removes the need for user applications to perform I&A functions. Simple socket programming is all that would be necessary - if the two hosts require encrypted sessions, then the co-operating OSs will set them up behind the scenes. If it can't be setup, then the connection should be denied, and the server would never be bothered. Even UDP traffic could be handled - though expensive for one packet; the cached handshake result (exchanged session ids, encryption keys) would speed up following packets. This is NOT a completed design, or even outline. more of a "desired result" to simplify programming real applications, and to avoid having to keep updating authentication methods for multiple applications. Any kerberos update, requires a minimum of updating: ktelnet/ktelnetd, ftp/ftpd, krsh/krshd ssh/sshd (if kerberized) plus any other applications that use kerberos. It also simplifies developement (should it use SSL, kerberos, GSSAPI, or...) by elimining the need for it to be included. Consider the potential update reqirement if a SSL library is updated - DNS, sendmail, LDAP, web browsers, web servers, .. any application that uses the SSL library would have to be checked (assuming you can update them - propriatary browsers can't be updated unless they happen to use a shared library.. and what if the API has to be changed...) The system can/should handle that behind the scenes. Then ALL applications (even those written by people who don't like to use security) will use what the site policy deems necessary. It also eliminates a LOT of duplicate development. The telnet example also gives a test method for a connection from an uncooperative system, one without IPSec and/or a security module. Hope the maniac raving is not too distracting... I'm going through a Kerberos update now... ------------------------------------------------------------------------- Jesse I Pollard, II Email: pollardat_private Any opinions expressed are solely my own. _______________________________________________ linux-security-module mailing list linux-security-moduleat_private http://mail.wirex.com/mailman/listinfo/linux-security-module
This archive was generated by hypermail 2b30 : Thu Aug 09 2001 - 15:00:10 PDT