From: Eric Dumazet <eric.dumazet@gmail.com>
To: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Cc: davem@davemloft.net, kuznet@ms2.inr.ac.ru, pekkas@netcore.fi,
jmorris@namei.org, yoshfuji@linux-ipv6.org, kaber@trash.net,
paul.moore@hp.com, netdev@vger.kernel.org,
linux-security-module@vger.kernel.org
Subject: Re: [PATCH] LSM: Add post recvmsg() hook.
Date: Sun, 18 Jul 2010 10:33:10 +0200 [thread overview]
Message-ID: <1279441990.2476.26.camel@edumazet-laptop> (raw)
In-Reply-To: <201007171017.DFC73498.SFFFOMLVJOHOtQ@I-love.SAKURA.ne.jp>
Le samedi 17 juillet 2010 à 10:17 +0900, Tetsuo Handa a écrit :
> David Miller wrote:
> > From: Tetsuo Handa
> > Date: Sat, 17 Jul 2010 01:14:38 +0900
> >
> > > Below is a patch for post recvmsg() operation. I modified the patch to call
> > > skb_recv_datagram() again (for udp_recvmsg(), raw_recvmsg(), udpv6_recvmsg())
> > > if LSM dicided to drop the message. (Regarding rawv6_recvmsg(), I didn't do so
> > > in accordance with the comment at "csum_copy_err:".)
> > > What do you think about this verion?
> >
> > This looks fine, but regardless of that comment I think the IPV6 raw recvmsg()
> > should loop just as the IPV4 one does in your patch.
> >
> Thank you, David.
> I updated to call skb_recv_datagram() for rawv6_recvmsg() case too.
>
> NETWORKING [IPv4/IPv6] maintainers and Paul, is below patch fine for you?
>
> Regards.
> ----------------------------------------
> >From b43154a90bc7494ec1ee301e692d2bbf29c8f2f8 Mon Sep 17 00:00:00 2001
> From: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
> Date: Sat, 17 Jul 2010 09:52:38 +0900
> Subject: [PATCH] LSM: Add post recvmsg() hook.
>
> Current pre recvmsg hook (i.e. security_socket_recvmsg()) has two problems.
>
> One is that it will cause eating 100% of CPU time if the caller does not
> close() the socket when recvmsg() failed due to security_socket_recvmsg(), for
> subsequent select() notifies the caller of readiness for recvmsg() since the
> datagram which would have been already picked up if security_socket_recvmsg()
> did not return error is remaining in the queue.
>
> The other is that it is racy if LSM module wants to do filtering based on
> "which process can pick up datagrams from which source" because the process
> which picks up the datagram is not known until skb_recv_datagram() and lock
> is not held between security_socket_recvmsg() and skb_recv_datagram().
>
> This patch introduces post recvmsg hook (i.e. security_socket_post_recvmsg())
> in order to solve above problems at the cost of ability to pick up the datagram
> which would have been picked up if preceding security_socket_post_recvmsg() did
> not return error.
>
> Signed-off-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
I read this patch and could not find out if an SNMP counter was
increased in the case a frame was not delivered but dropped in kernel
land.
--
To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
next prev parent reply other threads:[~2010-07-18 8:33 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-07-16 16:14 [RFC] LSM hook for post recvmsg Tetsuo Handa
2010-07-16 19:35 ` David Miller
2010-07-17 1:17 ` [PATCH] LSM: Add post recvmsg() hook Tetsuo Handa
2010-07-17 20:34 ` Paul Moore
2010-07-18 8:33 ` Eric Dumazet [this message]
2010-07-18 10:49 ` Tetsuo Handa
2010-07-18 21:25 ` David Miller
2010-07-19 4:25 ` [PATCH] LSM: Add post accept() hook Tetsuo Handa
2010-07-19 22:15 ` Paul Moore
2010-07-20 1:36 ` Tetsuo Handa
2010-07-20 19:52 ` Paul Moore
2010-07-21 2:00 ` Tetsuo Handa
2010-07-21 16:06 ` Paul Moore
2010-07-21 18:45 ` [PATCH] LSM: Add post recvmsg() hook David Miller
2010-07-22 3:38 ` Tetsuo Handa
2010-07-22 4:06 ` David Miller
2010-07-22 4:41 ` Tetsuo Handa
2010-07-22 4:45 ` David Miller
2010-07-22 5:02 ` Tetsuo Handa
2010-07-22 5:06 ` David Miller
2010-07-22 12:46 ` Tetsuo Handa
2010-07-22 17:22 ` David Miller
2010-07-22 17:26 ` David Miller
2010-07-23 0:22 ` Tetsuo Handa
2010-07-23 5:44 ` David Miller
2010-07-23 7:21 ` Tetsuo Handa
2010-07-23 7:29 ` David Miller
2010-07-23 12:37 ` Tetsuo Handa
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1279441990.2476.26.camel@edumazet-laptop \
--to=eric.dumazet@gmail.com \
--cc=davem@davemloft.net \
--cc=jmorris@namei.org \
--cc=kaber@trash.net \
--cc=kuznet@ms2.inr.ac.ru \
--cc=linux-security-module@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=paul.moore@hp.com \
--cc=pekkas@netcore.fi \
--cc=penguin-kernel@I-love.SAKURA.ne.jp \
--cc=yoshfuji@linux-ipv6.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox