FW: [PATCH net-2.6.25] Add packet filtering based on process'ssecurity context.

FW: [PATCH net-2.6.25] Add packet filtering based on process'ssecurity context.

[Tetsuo Handa]

I'm forwarding these mails since netfilter-devel's address has changed.

http://marc.info/?l=linux-netdev&m=119573856328335&w=2

------- Forwarded Message
 From: James Morris <jmorris@namei.org>
 To: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
 Cc: Herbert Xu <herbert@gondor.apana.org.au>, netdev@vger.kernel.org,"David S. Miller" <davem@davemloft.net>,linux-security-module@vger.kernel.org,Patrick McHardy <kaber@trash.net>, netfilter-devel@lists.netfilter.org,Stephen Smalley <sds@tycho.nsa.gov>
 Subject: Re: [PATCH net-2.6.25] Add packet filtering based on process'ssecurity context.
 Date: Fri, 23 Nov 2007 10:29:46 +1100 (EST)

On Thu, 22 Nov 2007, Tetsuo Handa wrote:

> This patch allows LSM modules filter incoming connections/datagrams
> based on the process's security context who is attempting to pick up.
> 
> There are already hooks to filter incoming connections/datagrams
> based on the socket's security context, but these hooks are not
> applicable when one wants to do TCP Wrapper-like filtering
> (e.g. App1 is permitted to accept TCP connections from 192.168.0.0/16).

This functionality looks like it could be useful in that we currently have 
no direct security mapping from incoming packet to user process, but only 
to the receiving socket, as you mention.  For SELinux, it may help us 
simplify/clarify policy.

It's also been long-desired for netfilter/iptables, to allow ipt_owner to 
work cleanly for incoming packets.

So, this probably needs to be implemented in a way which works for both LSM 
and netfilter.  There have been several discussions on the issue from the 
netfilter side, although I don't know what the latest status of that is 
(I've expanded the cc list to hopefully get some more feedback).

 From memory, one approach under discussion was to add netfilter hooks to 
the transport layer, which could be invoked correctly by each type of 
protocol when the target process is selected.

If this is done for netfilter, then an LSM hook is probably not needed at 
all, as security modules can utilize netfilter hooks directly.

> Precautions: This approach has a side effect which unlikely occurs.
> 
> If a socket is shared by multiple processes with differnt policy,
> the process who should be able to accept this connection
> will not be able to accept this connection
> because socket_post_accept() aborts this connection.
> But if socket_post_accept() doesn't abort this connection,
> the process who must not be able to accept this connection
> will repeat accept() forever, which is a worse side effect.
> 
> Similarly, if a socket is shared by multiple processes with differnt policy,
> the process who should be able to pick up this datagram
> will not be able to pick up this datagram
> because socket_post_recv_datagram() discards this datagram.
> But if socket_post_recv_datagram() doesn't discard this datagram,
> the process who must not be able to pick up this datagram
> will repeat recvmsg() forever, which is a worse side effect.
> 
> So, don't give different permissions between processes who share one socket.
> Otherwise, some connections/datagrams cannot be delivered to intended process.

These semantics changes are concerning, and lead me to wonder if there are 
any more.  Needs more review by networking folk.



- James
-- 
James Morris
<jmorris@namei.org>


------- End of Forwarded Message

------- Forwarded Message
 From: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
 To: jmorris@namei.org
 Cc: herbert@gondor.apana.org.au, netdev@vger.kernel.org, davem@davemloft.net,linux-security-module@vger.kernel.org, kaber@trash.net,netfilter-devel@lists.netfilter.org, sds@tycho.nsa.gov
 Subject: Re: [PATCH net-2.6.25] Add packet filtering based on process'ssecurity context.
 Date: Sat, 24 Nov 2007 11:14:50 +0900

Hello.

James Morris wrote:
> From memory, one approach under discussion was to add netfilter hooks to 
> the transport layer, which could be invoked correctly by each type of 
> protocol when the target process is selected.
> 
> If this is done for netfilter, then an LSM hook is probably not needed at 
> all, as security modules can utilize netfilter hooks directly.

Patrick McHardy says (at http://marc.info/?l=linux-netdev&m=118495005800410&w=2 )
"Even with socket filters netfilter doesn't know the final receipient
 process, that is not known until it calls recvmsg and the data is read,
 which is too late for netfilter."



> > Precautions: This approach has a side effect which unlikely occurs.
> > 
> > If a socket is shared by multiple processes with different policy,
> > the process who should be able to accept this connection
> > will not be able to accept this connection
> > because socket_post_accept() aborts this connection.
> > But if socket_post_accept() doesn't abort this connection,
> > the process who must not be able to accept this connection
> > will repeat accept() forever, which is a worse side effect.
I think this change is needed regardless of whether to use connection filtering or not.
Currently, SELinux doesn't use socket_post_accept().

|  * @socket_post_accept:
|  *	This hook allows a security module to copy security
|  *	information into the newly created socket's inode.

But if one wants to *copy* security information to accept()ed socket,
the location after fd_install() is too late to copy
because the userland process can access accept()ed socket's fd
whose security information is not copied yet.

Also, if one wants to *assign* security information to accept()ed socket,
it might attend memory allocation which can fail.
So, use of void for socket_post_accept() deprives a security module of a chance to
abort this connection if the security module failed to *assign* security information.

Regards.

-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


------- End of Forwarded Message

Re: [PATCH net-2.6.25] Add packet filtering based on process'ssecurity context.

[Tetsuo Handa]

Hello.

Thank you for feedback.

I have some questions.

(1) Your module uses "struct security_operations" and
    is registered with register_security().

    TOMOYO also uses "struct security_operations" and
    must be registered with register_security().

    Can your module and TOMOYO coexist?

(2) Can your module handle incoming UDP's datagram too?

(3) How do you handle race window between security_socket_accept()
    and sock->ops->accept()?

Samir Bellabes wrote:
> My approach is to get the informations regarding the socket from
> socket(), bind() and and accept() syscalls hooks.
> Pushing this informations to userspace. Here the user can refuse or
> accept the sycalls.

    If a socket is shared by multiple processes and
    the user said "Accept this connection" at security_socket_accept(),
    the process does not always pick up what the user wanted to pick up
    because there is no mutex between security_socket_accept() and
    sock->ops->accept().

(4) If (3) is my misunderstanding (i.e. the user doesn't judge at security_socket_accept()),
    it means that the user judges it before select() says "ready to accept".
    Then ... what happens if a socket is shared by multiple programs?
    The user has to judge without knowing which program will pick up this connection.
    TOMOYO lets the user judge whether to accept or not
    with knowing the program's name who picks up this connection.

I think getting information at socket(), bind() and accept() is helpful for detailed judgement,
but I think it doesn't solve race problem as long as the user judges *before* sock->ops->accept().

Regards.

Re: [PATCH net-2.6.25] Add packet filtering based on process'ssecurity context.

[Samir Bellabes]

Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp> writes:

> Hello.
>
> Thank you for feedback.
>
> I have some questions.
>
> (1) Your module uses "struct security_operations" and
>     is registered with register_security().
>
>     TOMOYO also uses "struct security_operations" and
>     must be registered with register_security().
>
>     Can your module and TOMOYO coexist?

Not sure about that.
I already had concerns about the coexistance of my module and SELinux.
I have to take time for that.

> (2) Can your module handle incoming UDP's datagram too?

yes, and better.
In fact, information is not dependant of the protocol at all.
What I mean is that we focus on network's syscalls, so for me, protocol
informations is let to the user for his/her decision.
When the module is catching bind(), we don't care if it's
TCP/DCCP/UDP/. What I care is to give the procotol information to the
user, to let him decide.

> (3) How do you handle race window between security_socket_accept()
>     and sock->ops->accept()?
>
> Samir Bellabes wrote:
>> My approach is to get the informations regarding the socket from
>> socket(), bind() and and accept() syscalls hooks.
>> Pushing this informations to userspace. Here the user can refuse or
>> accept the sycalls.
>
>     If a socket is shared by multiple processes and
>     the user said "Accept this connection" at security_socket_accept(),
>     the process does not always pick up what the user wanted to pick up
>     because there is no mutex between security_socket_accept() and
>     sock->ops->accept().

at security_socket_accept(), the user only accept the fact that the
application is able to go to sock->ops->accept(). That's the purpose of
this hook.

After, when packet are coming, we can catch them with
libnetfilter_queue, and deal with filtering packets.

> (4) If (3) is my misunderstanding (i.e. the user doesn't judge at security_socket_accept()),
>     it means that the user judges it before select() says "ready to accept".
>     Then ... what happens if a socket is shared by multiple programs?
>     The user has to judge without knowing which program will pick up this connection.
>     TOMOYO lets the user judge whether to accept or not
>     with knowing the program's name who picks up this connection.
>
> I think getting information at socket(), bind() and accept() is helpful for detailed judgement,
> but I think it doesn't solve race problem as long as the user judges *before* sock->ops->accept().

here we agree. *but* in my module, the user don't judge before
sock->ops->accept(). He judges when packets are coming, throught the
libnetfilter_queue API, in userspace, and reinject packet if it's ok.

We are really trying to do the same thing, but I'm almost sure this can
be achieved with existing tool in fact, and put more "decision code" in
the userspace, and only keep a managing/detecting tool in the kernelspace.

regards,
sam

Re: [PATCH net-2.6.25] Add packet filtering based on process'ssecurity context.

[Tetsuo Handa]

Hello.

Samir Bellabes wrote:
> at security_socket_accept(), the user only accept the fact that the
> application is able to go to sock->ops->accept(). That's the purpose of
> this hook.
Yes. This hook can't perform filtering.

> After, when packet are coming, we can catch them with
> libnetfilter_queue, and deal with filtering packets.
Is this performed inside sock->ops->accept()?

> here we agree. *but* in my module, the user don't judge before
> sock->ops->accept(). He judges when packets are coming, throught the
> libnetfilter_queue API, in userspace, and reinject packet if it's ok.
I didn't understand what is happening.
Is there a hook which can perform filtering inside sock->ops->accept()?

Regards.

Re: [PATCH net-2.6.25] Add packet filtering based on process'ssecurity context.

[Samir Bellabes]

Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp> writes:

> Hello.
>
> Samir Bellabes wrote:
>> at security_socket_accept(), the user only accept the fact that the
>> application is able to go to sock->ops->accept(). That's the purpose of
>> this hook.
> Yes. This hook can't perform filtering.

By "filtering", you should mean "packets filtring", shouldn't you ?
because this hook is able to deny the accept() syscall for a process, so
it's a kind of "filtring" too.

>> After, when packet are coming, we can catch them with
>> libnetfilter_queue, and deal with filtering packets.
> Is this performed inside sock->ops->accept()?

No, it's performed from the userspace. the goal is to don't touch the
network stack at all.
after accepting a successful security_socket_accept(), the processus
will wait for client. first packet will arrived. Here we do the
filtering, and give the ability to the user to deny packets.
Dropping the TCP SYN for a TCP connection, for example, then the
process don't see the connection arrived and was dropped.

Another important point which make me sure we should need to use the
libnetfilter_queue is that the we need to work with the conntrack tool
to automatically let some connections going throught the firewall.

One example, a ftp client will listen on a arbitrary port for the
incoming data channel. This job is already handle with the conntrack_ftp
extension by netfilter.
With your tool, you will have to learn the ftp client to let incoming
connection, reach this dynamic port, so does this mean, as it's dynamic,
to allow TCP port 1024-65535 ? 
With the approach of using the libnetfilter_queue, we can first put the
network packet inside the conntrack, let the packets in the RELATED
state going trought the firewall and be ACCEPTED, and for others
packets, let the user decide.

>> here we agree. *but* in my module, the user don't judge before
>> sock->ops->accept(). He judges when packets are coming, throught the
>> libnetfilter_queue API, in userspace, and reinject packet if it's ok.
> I didn't understand what is happening.
> Is there a hook which can perform filtering inside sock->ops->accept()?

I'm not speaking anymore about socket filtering inside
sock->aps->accept(). I do filtering for sock->aps->accept() with the
netfilter tool, by handling packets directly.
So there's two thing, first dealing with socket filtering for socket(),
bind(), listen(), accept() (just to let application to have the right to
execute the syscall)
Then for managing the data inside the connection, I will use the packet
by packet way, with netfilter and libnetfilter_queue.

I really need time to made a real release, to show code. I will take it.

regards,
sam

Re: [PATCH net-2.6.25] Add packet filtering based on process'ssecurity context.

[Tetsuo Handa]

Hello.

Thank you for detailed explanation.

Samir Bellabes wrote:
> By "filtering", you should mean "packets filtring", shouldn't you ?
> because this hook is able to deny the accept() syscall for a process, so
> it's a kind of "filtring" too.
Yes, you are right.

> No, it's performed from the userspace. the goal is to don't touch the
> network stack at all.
OK. One thing I'm worrying.
Use of userspace process assumes that it shall not be killed by some reason
(SIGKILL or OOM-killer or something).
What happens if userspace process is dead?
TOMOYO wants to continue packet filtering functionality even if userspace process is dead.
So, TOMOYO loads all filtering rules inside kernel and performs filtering inside kernel.

TOMOYO's goals are
(1) perform simple stateless packet filtering without any assistance outside the kernel
(2) provide simple approach for people (including me) who disable iptables
    or worry the correctness of configurations because of very complicated syntax.
    (Many users disable both iptables/SELinux inside local network because
    their very-very-flexible-configurations give them a headache.)
(3) allow people describe per-an-application firewall rules in understandable syntax.

> Dropping the TCP SYN for a TCP connection, for example, then the
> process don't see the connection arrived and was dropped.
That's an advantage.
Making select() not to say "ready to accept" is what TOMOYO wants
(although it is very difficult to do so because of (3)).

> With your tool, you will have to learn the ftp client to let incoming
> connection, reach this dynamic port, so does this mean, as it's dynamic,
> to allow TCP port 1024-65535 ?
Yes. Users add lines like

 <kernel> /usr/sbin/vsftpd
 allow_network TCP accept xxx.xxx.xxx.xxx-yyy.yyy.yyy.yyy 1024-65535

which means "/usr/sbin/vsftpd is able to accept incoming TCP connections
if source IP address is between xxx.xxx.xxx.xxx-yyy.yyy.yyy.yyy and
source port is between 1024-65535" and

 <kernel> ... /usr/bin/ftp
 allow_network TCP accept zzz.zzz.zzz.zzz 1024-65535

which means "/usr/bin/ftp is able to accept incoming TCP connections if
source IP address is zzz.zzz.zzz.zzz and source port is between 1024-65535".
Users have to add explicitly, but it is very easy and understandable.

> I'm not speaking anymore about socket filtering inside
> sock->aps->accept(). I do filtering for sock->aps->accept() with the
> netfilter tool, by handling packets directly.
For TOMOYO, (3) is more important than making select() not to say "ready to accept".
Packet filtering without knowing the program's name who picks up this connection is not a TOMOYO's goal.
So, TOMOYO still wants to do filtering inside sock->aps->accept() or security_socket_post_accept().

Thank you.

Re: [PATCH net-2.6.25] Add packet filtering based on process'ssecurity context.

[Samir Bellabes]

Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp> writes:

> Hello.
> Thank you for detailed explanation.
> Samir Bellabes wrote:
>
>> No, it's performed from the userspace. the goal is to don't touch the
>> network stack at all.
> OK. One thing I'm worrying.
> Use of userspace process assumes that it shall not be killed by some reason
> (SIGKILL or OOM-killer or something).
> What happens if userspace process is dead?

here is the way:
1. a syscall is executed.
2. we send the informations to userspace daemon, and we are waiting for
   what I'm calling a "verdict" on it, there is of course a timer on
   that.
3. userspace daemon asks user - or something that TOMOYO don't seems to
   handle because it's living all in the kernel, a automatic decision
   process, throught a database rules, a XML file rules, etc.. 
4. userspace daemon give its verdict.
5. kernel execute the verdict.

Now, what if the userspace daemon died. There's 2 possibilities for the
moment.

1/ apply a DEFAULT_POLICY after timer expires. this default verdict are
   - DENY
   - GRANT
   - NOTIFY (in kernel log)
   - DELAY (with a fixed limit time). 

2/ something I'm currently designing, is to keep a cache of
rules/decision in the kernel part. The goal is that the system will
auto-learn about the decision of the user, and keep rules decisions
somewhere (database, XML file, ..). When starting, we put this rules
inside the kernel cache rules.
When a event occures (syscall):
   - we are looking for a macthe in the cached rules.
   - if we don't have a verdict in this cache, we are going to ask the
     userspace part for a verdict in this case, and save the decision
     for same matched conditions

When a new rules is applied, deleted or modified for userspace, we are
updating the kernel cache in real-time.
I want to have a tool nearly working as iptables for netfilter rules,
what I mean is that the "brain"/decision part is in the userspace, not
in the kernel.

there is also other reasons to that last point, because with all the
informations coming from the networking event like networking syscalls,
network packets, we can do more than a personnal security tool, we can
do with minimal cost:
    - monitoring, just save the network events (already done)
    - taking others "network decisions" : adding route inside the
      network, auto-mount distant filesystem, starting distant services
      (I have no shame to said that is currently a really big dream :)

> TOMOYO wants to continue packet filtering functionality even if userspace process is dead.
> So, TOMOYO loads all filtering rules inside kernel and performs
> filtering inside kernel.

Yes, as I said this is also something I want to do.

> TOMOYO's goals are
> (1) perform simple stateless packet filtering without any assistance
> outside the kernel

what differences between you approach and netfilter in this case ? if
it's about packet filtering, you already have all you wishes in
netfilter project.

> (2) provide simple approach for people (including me) who disable iptables
>     or worry the correctness of configurations because of very complicated syntax.
>     (Many users disable both iptables/SELinux inside local network because
>     their very-very-flexible-configurations give them a headache.)

No. I'm sorry you can't disable iptables in your model.

security :
what about crafted/bad/bogus packets ? what about stealth scans ?
netfilter is here to protect from this.

usuability:
what about forwarding ?
My goal is that someone having a gateway and a LAN box, he can, by
starting a service which is listening, on the LAN box, automatically
have a forwarding rule added to the gateway, for its service, the time
the process service is living.
It's the same for someone executing a connect() from the LAN to a
outside web service, we are dectecting this syscall, a put a rule on the
gateway to authorize the outgoing forwarding

It's also true for the DMZ, ie start sshd, then we are detecting the
listen() in sshd process, and we are putting a forwarding rule on the
router.
Think about the target is projects like linux-embedded routers.

> (3) allow people describe per-an-application firewall rules in
> understandable syntax.
Yes, that was also my starting point too. helping basics users.

>> Dropping the TCP SYN for a TCP connection, for example, then the
>> process don't see the connection arrived and was dropped.
> That's an advantage.
> Making select() not to say "ready to accept" is what TOMOYO wants
> (although it is very difficult to do so because of (3)).

thanks.

>> With your tool, you will have to learn the ftp client to let incoming
>> connection, reach this dynamic port, so does this mean, as it's dynamic,
>> to allow TCP port 1024-65535 ?
>
>  <kernel> ... /usr/bin/ftp
>  allow_network TCP accept zzz.zzz.zzz.zzz 1024-65535
>
> which means "/usr/bin/ftp is able to accept incoming TCP connections if
> source IP address is zzz.zzz.zzz.zzz and source port is between 1024-65535".
> Users have to add explicitly, but it is very easy and understandable.

so we are losing in granularity against the netfilter conntrack in this
case, because the conntrack will get the exact listening port, and not
all the unprivileged port.
We have to use the conntrack tool, first to continue having all the
existing features (like transparently get a RELATED connection working),
second because the libnetfilter_queue is the place to deal with packets,
and yes, if you want to filtering packets, there only one possibility
for the moment, netfilter.

What is really important with this new way of filtering is the win
regarding the granularity. With netfiler it's basically : IP/port src,
IP/port dst, protocol.
My view is to always have 2 more dimensions : userid and process, and
never fall inside a less granular case.

>> I'm not speaking anymore about socket filtering inside
>> sock->aps->accept(). I do filtering for sock->aps->accept() with the
>> netfilter tool, by handling packets directly.
> For TOMOYO, (3) is more important than making select() not to say "ready to accept".
> Packet filtering without knowing the program's name who picks up this connection is not a TOMOYO's goal.
> So, TOMOYO still wants to do filtering inside sock->aps->accept() or security_socket_post_accept().

ok, same goals, differents ways.

thanks for this discussion, it's really interesting to share the same idea.
regards
sam

Re: [PATCH net-2.6.25] Add packet filtering based on process'ssecurity context.

[Tetsuo Handa]

Hello, Samir.

Did you receive the following messages?
Since these messages were dropped at vger.kernel.org ,
I'm worrying that you couldn't receive the following messages.

Tetsuo Handa wrote:
> Hello.
> 
> Samir Bellabes wrote:
> > >> what differences between you approach and netfilter in this case ? if
> > >> it's about packet filtering, you already have all you wishes in
> > >> netfilter project.
> > > Except a hook for making decision with the name of process who picks that packet up known.
> > 
> > I think that we really don't need it, because we can catch the
> > informations as I explained.
> 
> Well, I haven't understood yet why we don't need it.
> 
> How can you know the the name of process who copies that datagram to its userspace memory?
> A socket may be shared by multiple different executable files,
> so the name of the executable file is not known until
> one of processes who share the socket issues accept()/recvmsg() syscall.
> 
> Are you saying that I should not use the name of the executable file?
> 
> Regards.
> 

Tetsuo Handa wrote:
> Hello.
> 
> I made an example.
> 
> Usage:
> 
>   Compile app1 and app2 and run /tmp/app1 .
> 
>   Run something like
>    curl http://localhost:10000/
>   to connect to /tmp/app1.
> 
> I want to know that */tmp/app2* accepts TCP connection
> so that the user can control
> whether this TCP connection from 127.0.0.1 port N
> should be accepted by */tmp/app2* or not.
> 
> How can we do this without socket_post_accept() change?
> 
> Regards.
> 
> ---------- app1.c start ----------
> /* gcc -Wall -O2 -o /tmp/app1 app1.c */
> #include <fcntl.h>
> #include <netinet/in.h>
> #include <stdio.h>
> #include <string.h>
> #include <sys/select.h>
> #include <sys/socket.h>
> #include <sys/types.h>
> #include <unistd.h>
> 
> int main(int argc, char *argv[]) {
> 	const int fd = socket(PF_INET, SOCK_STREAM, 0);
> 	struct sockaddr_in addr;
> 	char buf[16];
> 	memset(&addr, 0, sizeof(addr));
> 	addr.sin_family = AF_INET;
> 	addr.sin_addr.s_addr = htonl(INADDR_ANY);
> 	addr.sin_port = htons(10000);
> 	fprintf(stderr, "%s started.\n", argv[0]);
> 	if (bind(fd, (struct sockaddr *) &addr, sizeof(addr))) {
> 		fprintf(stderr, "Can't bind()\n");
> 		return 1;
> 	} else if (listen(fd, 5)) {
> 		fprintf(stderr, "Can't listen()\n");
> 		return 1;
> 	}
> 	while (1) {
> 		fd_set rfds;
> 		FD_ZERO(&rfds);
> 		FD_SET(fd, &rfds);
> 		select(fd + 1, &rfds, NULL, NULL, NULL);
> 		if (FD_ISSET(fd, &rfds)) break;
> 		fprintf(stderr, "Can't select()\n");
> 		return 1;
> 	}
> 	if (fcntl(fd, FD_CLOEXEC, 0)) {
> 		fprintf(stderr, "Can't fcntl()\n");
> 		return 1;
> 	}
> 	snprintf(buf, sizeof(buf), "%d", fd);
> 	execlp("/tmp/app2", "app2", buf, NULL);
> 	fprintf(stderr, "Can't execve()\n");
> 	return 1;
> }
> ---------- app1.c end ----------
> 
> ---------- app2.c start ----------
> /* gcc -Wall -O2 -o /tmp/app2 app2.c */
> #include <netinet/in.h>
> #include <stdio.h>
> #include <stdlib.h>
> #include <sys/socket.h>
> #include <sys/types.h>
> #include <unistd.h>
> 
> int main(int argc, char *argv[]) {
> 	int lfd;
> 	if (argc != 2) {
> 		fprintf(stderr, "Bad parameter.\n");
> 		return 1;
> 	}
> 	fprintf(stderr, "%s started.\n", argv[0]);
> 	lfd = atoi(argv[1]);
> 	while (1) {
> 		struct sockaddr_in addr;
> 		socklen_t size = sizeof(addr);
> 		int fd = accept(lfd, (struct sockaddr *) &addr, &size);
> 		char c;
> 		if (fd == EOF) {
> 			fprintf(stderr, "Can't accept()\n");
> 			return 1;
> 		}
> 		while (read(fd, &c, 1) == 1 && write(fd, &c, 1) == 1);
> 		close(fd);
> 	}
> 	return 0;
> }
> ---------- app2.c end ----------
> 

Re: [PATCH net-2.6.25] Add packet filtering based on process'ssecurity context.

[Samir Bellabes]

Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp> writes:

> Hello, Samir.
>
> Did you receive the following messages?
> Since these messages were dropped at vger.kernel.org ,
> I'm worrying that you couldn't receive the following messages.

Yes, I got it.
I will take time to investigate your example.

Re: [PATCH net-2.6.25] Add packet filtering based on process's securitycontext.

[Tetsuo Handa]

Hello.

Patrick McHardy wrote:
> No news on that. I'm also a bit sceptical if adding all this complexity
> and overhead would really be worth it (considering only netfilter) just
> to use the owner match and UID/GID matching. It wouldn't even be
> accurate because there is not 1:1 mapping of sockets and processes.
Considering only LSM, socket_post_accept()/socket_post_recv_datagram() hooks are
not complicated at all.
A socket may be mapped to multiple processes, but at the moment of picking up
(i.e. accept()/recvmsg()), I think it is accurate 1:1 mapping.
I'm more interested in "Who picks this connection/datagram up?" than
"Which socket enqueues this connection/datagram?"
It may be indifferent for netfilter, but it is region of interest for me.

> I actually like Samir Bellabes' approach, which doesn't suffer from
> these problems IIRC.
Oh, I found him at http://nfws.inl.fr/en/?p=50 . (Sorry, I didn't know.)
He is the person who was discussing with me a few days ago.

> >>From memory, one approach under discussion was to add netfilter hooks to 
> > the transport layer, which could be invoked correctly by each type of 
> > protocol when the target process is selected.
> 
> We can only invoke the hooks after the socket lookup, but we don't
> know which process is going to call recvmsg() for that socket.

Right. Thus, I'm proposing LSM hooks at accept()/recvmsg() time.

Regards.