From: Paul Moore <paul.moore@hp.com>
To: Tetsuo Handa <penguin-kernel@i-love.sakura.ne.jp>
Cc: davem@davemloft.net, eric.dumazet@gmail.com, jmorris@namei.org,
sam@synack.fr, serge@hallyn.com, netdev@vger.kernel.org,
linux-security-module@vger.kernel.org
Subject: Re: [PATCH] LSM: Add post accept() hook.
Date: Tue, 20 Jul 2010 15:52:29 -0400 [thread overview]
Message-ID: <201007201552.29539.paul.moore@hp.com> (raw)
In-Reply-To: <201007200136.o6K1aVc5015269@www262.sakura.ne.jp>
On Monday, July 19, 2010 09:36:31 pm Tetsuo Handa wrote:
> Paul Moore wrote:
> > I think you need to show how you plan to use this hook in an LSM before
> > we can consider merging it with mainline. What you are proposing here
> > is giving an LSM the ability to drop a connection _after_ allowing it to
> > be established in the first place; this seems very wrong to me and I
> > want to make sure everyone else is aware of that before accepting this
> > code into the kernel. I understand that TOMOYO's security model does
> > not allow it to reject incoming connections at the beginning of the
> > connection request like some of the LSMs currently in use, but I'm just
> > not very happy with the idea of finishing a connection handshake only to
> > later drop the connection on the floor.
>
> Yes. I'm planning to use security_socket_post_accept() for two purposes.
>
> One is for dropping connections from unwanted hosts. Administrators define
> policy before enabling enforcing mode (the mode which connections are
> dropped if operation was not granted by policy). Administrators specify
> acceptable hosts (i.e. hosts which this host needs to communicate with)
> and unacceptable hosts (i.e. hosts which this host needn't to communicate
> with).
You can enforce per-host access controls without the need for a post-accept()
hooks, e.g. security_sock_rcv_skb() and the netfilter hooks
(NF_INET_POST_ROUTING, NF_INET_FORWARD, NF_INET_LOCAL_OUT). Or are you
interested in controlling which hosts an _application_ can communicate with?
> Dropping connections would happen if some process was hijacked and the
> process attempted to communicate with other processes using TCP
> connections. But dropping connections should not happen in normal
> circumstance.
It doesn't matter if dropping connections is normal or not, what matters is
that it can happen.
> The other is for updating process's state variable upon accept() operation.
> LKM version of TOMOYO has per a task_struct variable that is used for
> implementing stateful permissions. (As of now, not implemented for LSM
> version of TOMOYO.)
I'm open to re-introducing a post-accept() hook that does not have a return
value, in other words, a hook that can only be used to update LSM state and
not affect the connection. Although I do think you could probably achieve the
same thing using some of the existing LSM hooks (look at how SELinux updates
its state upon accept()) but that is something you would have to look it and
see if it works for TOMOYO.
--
paul moore
linux @ hp
next prev parent reply other threads:[~2010-07-20 19:52 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
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 [this message]
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=201007201552.29539.paul.moore@hp.com \
--to=paul.moore@hp.com \
--cc=davem@davemloft.net \
--cc=eric.dumazet@gmail.com \
--cc=jmorris@namei.org \
--cc=linux-security-module@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=penguin-kernel@i-love.sakura.ne.jp \
--cc=sam@synack.fr \
--cc=serge@hallyn.com \
/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;
as well as URLs for NNTP newsgroup(s).