lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Date:	Wed, 7 Feb 2007 17:34:20 +0100
From:	"Jack Bauer" <mlsubscriber@...il.com>
To:	linux-kernel@...r.kernel.org
Subject: [QUESTION] Kernelspace <-> Userspace communication during tcp stack code execution

Hi,

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

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

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?

regards,
Jack
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ