On Thursday, September 6 2007 9:04:01 am Tetsuo Handa wrote:
> (1) It uses userspace intervention to allow/reject
> connections and/or packets based on the application's domain.
> Since existent hooks can't be used for this purpose,
> I inserted a new hook post_recv_datagram() at skb_re
Hello.
Thank you very much for your time, Paul.
Yes, you understood what I wanted to do.
TOMOYO Linux's approach:
(1) It uses userspace intervention to allow/reject
connections and/or packets based on the application's domain.
Since existent hooks can't be used for this purpose,
I in
On Tuesday 04 September 2007 10:02:46 am Tetsuo Handa wrote:
> According to Patrick McHardy's posting at
> http://www.mail-archive.com/[EMAIL PROTECTED]/msg00999.
>html netfilter *socket filters* cannot know final recipient process.
> Can netfilter *userspace queue mechanism* know final recipient p
On Sep 04, 2007, at 10:02:46, Tetsuo Handa wrote:
Hmm, I can't understand why I have to perform access control at
"enqueue" time.
What I want to do is
allow process1 receive UDP packets from 10.0.0.1 port 1024
allow process2 receive UDP packets from 10.0.0.2 port 2048
when there is no guar
Hello.
Thank you for your comment.
Hmm, I can't understand why I have to perform access control at "enqueue" time.
What I want to do is
allow process1 receive UDP packets from 10.0.0.1 port 1024
allow process2 receive UDP packets from 10.0.0.2 port 2048
when there is no guarantee that proces
On Monday 03 September 2007 9:15:27 am Tetsuo Handa wrote:
> Hello.
Hi.
> Paul Moore wrote:
> > I apologize for not recognizing your approach from our earlier discussion
> > on the LSM mailing list in July. Unfortunately, I have the same
> > objections to these changes that I did back then and f
Hello.
Paul Moore wrote:
> I apologize for not recognizing your approach from our earlier discussion on
> the LSM mailing list in July. Unfortunately, I have the same objections to
> these changes that I did back then and from what I can recall of the
> discussion the rest of the kernel networ
On Tuesday, August 28 2007 6:39:13 am Tetsuo Handa wrote:
> Hello.
Hello.
> Paul Moore wrote:
> > >* post_recv_datagram is added in skb_recv_datagram.
> >
> > Can you explain to me why this is not possible using the existing
> > security_socket_sock_rcv_skb() LSM hook?
>
> socket_sock_rcv_skb
Hello.
Paul Moore wrote:
> >* post_recv_datagram is added in skb_recv_datagram.
>
> Can you explain to me why this is not possible using the existing
> security_socket_sock_rcv_skb() LSM hook?
socket_sock_rcv_skb() is a hook for enqueue time.
I want a hook for dequeue time, because what TOMO
On Friday, August 24 2007 8:58:28 am Kentaro Takeda wrote:
> LSM hooks for network accept and recv:
>* socket_post_accept is modified to return int.
This has been discussed several times on various lists and is not considered
an acceptable solution to blocking incoming stream connection attem
LSM expansion for TOMOYO Linux.
LSM hooks for sending signal:
* task_kill_unlocked is added in sys_kill
* task_tkill_unlocked is added in sys_tkill
* task_tgkill_unlocked is added in sys_tgkill
LSM hooks for network accept and recv:
* socket_post_accept is modified to return int.
*
11 matches
Mail list logo
