On Wed, Feb 07, 2007 at 05:39:07PM +0100, Jack Bauer wrote: > I'm a student in computer science and for my master thesis i have to > modify the kernel TCP stack in a way that it allows to perform a > transparent user authentification during the TCP 3-way-handshake (with > the help of a modified firewall which tracks the 3-way-handshake). Sounds like SSL and/or IP-sec. > As you might imagine I have to alter the syn,synack and ack packets > and fill it with authentification information of the user who > initiated the new TCP connection. These information are stored in > config files on the client/user host (for example a config file which > contains the location of the users certificate). On the firewall host > I also need file access from within a netfilter kernel module and have > to perform other time consuming tasks (for example reading the root > certificate and check the users cert in the syn packet). > > As these tasks are typical userspace tasks I want to write a daemon > which does all the file access and certificate work when the kernel > requests it and which than sends the information back to the kernel. > > What opportunities do I have to implement a fast Kernel <-> Userspace > Daemon communication? > > My first tought was to create a /proc or /dev entry and register file > operation functions for these entries. Don't abuse /proc for that, just create a device entry. > But the first problem I see is > that the daemon has to read the /proc or /dev file in an endless loop > so that the daemon recognizes (in a fast way) when the kernel pushes > request commands to the /proc or /dev file. Userspace will block until the kernel has data available. Or it won't block when you read in non-blocking mode, but in that case you whould have to use select() or poll() to figure out if there's more data. > The second problem is that > the kernel has to wait for the answer of the daemon before it can > continue and putting the requested information in the syn packet for > example. And what happens if the request method (which got called in > the tcp stack) blocks until the daemon response was read in? I think > the kernel would hang, wouldn't it? But that will happen regardless of the method used to get user credentials. I'm not sure if you can call out to userspace during the 3-way handshake, aks on the netdev mailing list. > The second tought was to use AF_NETLINK which should solve the first > problem but as the NETLINK readmsg() method also blocks until it > recieved data I don't know if the kernel would also hang. > > Do you have any suggestions how to solve this situation? Ask on the netdev mailing list (netdev@xxxxxxxxxxxxxxx), that's where the networking guru's live. Erik -- They're all fools. Don't worry. Darwin may be slow, but he'll eventually get them. -- Matthew Lammers in alt.sysadmin.recovery
Attachment:
signature.asc
Description: Digital signature
