[RFC] Allow LSM to use IP address/port number. (was Re: [PATCH 1/1] Add post accept()/recvmsg() hooks.)

? Regards. Signed-off-by: Tetsuo Handa [EMAIL PROTECTED] --- include/linux/security.h | 38 ++ net/socket.c | 40 ++-- security/dummy.c | 11 +-- 3 files changed, 77 insertions(+), 12 deletions

Re: [RFC] Allow LSM to use IP address/port number.

Hello. Thank you for your comment. David Miller wrote: I don't think it's such a hot idea to return errors if the wait_on_sync_kiocb() has returned success. My patch may return errors for non-wait_on_sync_kiocb() case too. Are you saying only wait_on_sync_kiocb() case is bad? If so, could you

Re: [RFC] Allow LSM to use IP address/port number.

Thank you for your comment. I have a question regarding netfilter infrastructure. I want to filter messages using task_struct-security. Can the netfilter's queuing to userspace feature get a list of struct task_struct who shares a socket that is going to receive incoming messages? My approach

[PATCH 1/1] Allow LSM to use IP address/port number.

is. The only chance to perform ip/port based filtering using ACLs associated with the recipant process of the packet is post-accept() and post-recvmsg(). Therefore, I re-post my patch again. Regards. Signed-off-by: Tetsuo Handa [EMAIL PROTECTED] --- include/linux/security.h | 44

Re: [PATCH 1/1] Allow LSM to use IP address/port number.

Hello. Patrick McHardy wrote: Quoting Tetsuo: So, my approach is not using security context associated with a socket but security context associated with a process. Isn't the socket context derived from the process context? Not so regarding my case. static int

What does -EIOCBQUEUED do?

Hello. There are several locations that handle -EIOCBQUEUED error code. According to include/linux/errno.h , it seems this code is NFS related and caller will receive completion event later. But I couldn't figure out where is the beginning point and what is happening. What functions are called

Re: [TOMOYO 15/15] LSM expansion for TOMOYO Linux.

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

[PATCH] Add packet filtering based on process\'s security context.

this datagram will repeat recvmsg() forever, which is a worse side effect. Signed-off-by: Kentaro Takeda [EMAIL PROTECTED] Signed-off-by: Tetsuo Handa [EMAIL PROTECTED] include/linux/security.h | 34 +- net/core/datagram.c | 26 -- net

[PATCH] Add packet filtering based on process's security context.

-by: Tetsuo Handa [EMAIL PROTECTED] include/linux/security.h | 34 +- net/core/datagram.c | 26 -- net/socket.c |7 +-- security/dummy.c | 13 ++--- security/security.c | 10 -- 5

Re: [README] away until Dec 3rd

Hello. I have a question. Yesterday, I posted a patch based on 2.6.24-rc3-mm1 that modifies the following files. include/linux/security.h | 34 +- net/core/datagram.c | 26 -- net/socket.c |7 +--

[PATCH net-2.6.25] Add packet filtering based on process's security context.

Hello. Herbert Xu wrote: On Thu, Nov 22, 2007 at 09:57:14PM +0900, Tetsuo Handa wrote: But you say that I should make patches based on the net-2.6.25 tree. Which tree (-mm or net-2.6.25) should I use for making this patch? The net-2.6.25 tree is the one. Please use the tree

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

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

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

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.

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

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,

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

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?

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

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

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

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

Re: AF_UNIX MSG_PEEK bug?

Hello. Brent Casavant wrote: However, the program would occasionally get into a situation where a call to recv(sockfd, buf, len, MSG_PEEK) returns some number of bytes less than the requested length, and persists in this state (i.e. retrying the call continues to return the same amount of

[PATCH net-2.6.25] Add packet filtering based on process's security context.

receives the incoming packet is not known until a process calls sys_recvmsg(). So, I want to add a LSM hook to give a security module a chance to control after the recipient of the incoming packet is known. Signed-off-by: Kentaro Takeda [EMAIL PROTECTED] Signed-off-by: Tetsuo Handa [EMAIL PROTECTED

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

Hello. Casey Schaufler wrote: Do you have a real situation where two user processes with different security contexts share a socket? How do you get into that situation, and is it appropriate to have that situation in your security scheme? Can this occur without using privilege? I hope such

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

to control after the recipient of the incoming packet is known. Signed-off-by: Kentaro Takeda [EMAIL PROTECTED] Signed-off-by: Tetsuo Handa [EMAIL PROTECTED] --- include/linux/security.h | 34 +- net/core/datagram.c | 29 - net

[2.6.24-mm1] TCP/IPv6 connect() oopses at twothirdsMD4Transform()

Hello. Kernel config is at http://I-love.SAKURA.ne.jp/tmp/config-2.6.24-mm1 2.6.24 works fine. Regards. -- BUG: unable to handle kernel paging request at 25476bec IP: [c0211c28] twothirdsMD4Transform+0x78/0x37c *pde = Oops: [#1] SMP DEBUG_PAGEALLOC last sysfs file:

Re: [2.6.24-mm1] TCP/IPv6 connect() oopses at twothirdsMD4Transform()

Hello. random: revert braindamage that snuck into checkpatch cleanup Signed-off-by: Matt Mackall [EMAIL PROTECTED] Yes. It solved the oops. Thank you. -- To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at

[2.6.25-rc1] Locks in udp_recvmsg()?

Hello. I found that udp_recvmsg() in net/ipv4/udp.c for 2.6.25-rc1 calls lock_sock() only when it releases the datagram (i.e. out_free: and csum_copy_err:). Is it correct to call __skb_recv_datagram() without calling lock_sock() when it acquires the datagram (i.e. try_again:)? Regards. -- To

Re: [PATCHSET] printk, netconsole: implement reliable netconsole

Tejun Heo wrote: On Sat, Apr 18, 2015 at 03:03:46AM +0900, Tetsuo Handa wrote: packet will be sufficient for finding out whether the packets were lost and/or reordered in flight. printk(Hello); = netconsole sends Hello using UDP printk(netconsole

Re: [PATCHSET] printk, netconsole: implement reliable netconsole

Tejun Heo wrote: Hello, David. On Fri, Apr 17, 2015 at 01:17:12PM -0400, David Miller wrote: If userland cannot run properly, it is almost certain that neither will your complex reliability layer logic. * The bulk of patches are to pipe extended log messages to console drivers and

Re: [PATCHSET] printk, netconsole: implement reliable netconsole

Tejun Heo wrote: printk() cannot wait for ack. Trying to wait for ack would break something. How can you transmit subsequent kernel messages which failed to enqueue due to waiting for ack for previous kernel messages? Well, if log buffer overflows and the messages aren't at the logging

Re: [PATCHSET] printk, netconsole: implement reliable netconsole

Tejun Heo wrote: * Implement netconsole retransmission support. Matching rx socket on the source port is automatically created for extended targets and the log receiver can request retransmission by sending reponse packets. This is completely decoupled from the main write path and

Re: [PATCHSET] printk, netconsole: implement reliable netconsole

Tejun Heo wrote: If we can assume that scheduler is working, adding a kernel thread that does while (1) { read messages with metadata from /dev/kmsg send them using UDP network } might be easier than modifying netconsole module. But, I mean, if we are gonna

Re: [patch] cxgb4: memory corruption in debugfs

Dan Carpenter wrote: You can't use kstrtoul() with an int or it causes memory corruption. Also j should be unsigned or we have underflow bugs. I considered changing j to unsigned long but everything fits in a u32. Excuse me, but kstrtouint()'s last argument is not u32 * but unsigned int *.

[PATCH] tree wide: Use kvfree() than conditional kfree()/vfree()

check and reply if you found problems. Signed-off-by: Tetsuo Handa <penguin-ker...@i-love.sakura.ne.jp> Acked-by: Michal Hocko <mho...@suse.com> Cc: Russell King <li...@arm.linux.org.uk> # arm Cc: <linux-a...@vger.kernel.org> # apei Cc: <drbd-u...@lists.linbit

[PATCH] tcp: use kmalloc() than kmalloc_array().

no need to use kmalloc_array(). Since I assume it won't overflow, use kmalloc() than kmalloc_array(). Signed-off-by: Tetsuo Handa <penguin-ker...@i-love.sakura.ne.jp> --- net/ipv4/inet_hashtables.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/net/ipv4/inet_hashtabl

Re: [PATCH] tcp: use kmalloc() than kmalloc_array().

Tetsuo Handa wrote: > Commit 095dc8e0c3686d58 ("tcp: fix/cleanup inet_ehash_locks_alloc()") > silently changed from kmalloc() to kmalloc_array(). The latter has > overflow check whereas the former doesn't have. > > If nblocks * locksz might overflow, we need to do lik

Re: [PATCH] tcp: use kmalloc() than kmalloc_array().

David Miller wrote: > From: Eric Dumazet > Date: Sat, 07 Nov 2015 10:50:07 -0800 > > > I do not feel we should go back to kmalloc() just because > > vmalloc_array() does not exist yet. > > Agreed. > Please change as you like. I was thinking to introduce a helper that

Re: [PATCH] unix: properly account for FDs passed over unix sockets

before the culprit process is killed (CVE-2013-4312)". Reported-by: Tetsuo Handa <penguin-ker...@i-love.sakura.ne.jp> Mitigates: CVE-2013-4312 (Linux 2.0+) -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html

Re: [PATCH] ath6kl: Use vmalloc for loading firmware using api1 method

Andy Shevchenko wrote: > On Sat, Nov 28, 2015 at 8:58 PM, Brent Taylor wrote: > > Whats the status on this patch? I don't see it on patchwork anymore > > nor is it in any of the git trees I checked. > > > > You forget to use kvfree() instead of kfree() in core.c. > In

Re: [PATCH] vmxnet3: avoid calling pskb_may_pull with interrupts disabled

Neil Horman wrote: > On Mon, Mar 07, 2016 at 03:16:14PM -0500, David Miller wrote: > > From: Neil Horman > > Date: Fri, 4 Mar 2016 13:40:48 -0500 This patch is calling spin_unlock_irqrestore() without spin_lock_irqsave(). In file included from

Re: 4.4.3: OOPS when running "stress-ng --sock 5"

Holger Schurig wrote: > So I did an "arm-linux-gnueabihf-objdump -Sgd linux/vmlinux", not sure > if that helps: > > c00972ec <__rmqueue>: > * Do the hard work of removing an element from the buddy allocator. > * Call me with the zone->lock already held. > */ > static struct page

[PATCH] netfilter: x_tables: fix kmemcheck warning.

10 [ 367.501792] ip6_tables: (C) 2000-2006 Netfilter Core Team [ 367.502971] NET: Registered protocol family 17 Signed-off-by: Tetsuo Handa <penguin-ker...@i-love.sakura.ne.jp> --- net/netfilter/x_tables.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/net/net

[linux-next] NULL pointer dereference in rt6_fill_node

Hello. I'm hitting this with linux-next-20170125. Is this known? [ OK ] Started Show Plymouth Reboot Screen. [ OK ] Stopped PostgreSQL database server. [ OK ] Stopped Dynamic System Tuning Daemon. [ OK ] Stopped target Network.

Re: WARNING in add_uevent_var

0; } >From 3eba6541da0c7338e3d71ea83cbc69962923d65e Mon Sep 17 00:00:00 2001 From: Tetsuo Handa <penguin-ker...@i-love.sakura.ne.jp> Date: Mon, 7 May 2018 15:58:37 +0900 Subject: [PATCH] net: rfkill: Add filename varidity test at rfkill_alloc(). syzbot is hitting WARN() at kobject_ue

Re: WARNING in kernfs_add_one

vious fault injection messages... >From 7ddcaa3d4327d4f29d11053bd2011bf77ecf72af Mon Sep 17 00:00:00 2001 From: Tetsuo Handa <penguin-ker...@i-love.sakura.ne.jp> Date: Mon, 7 May 2018 14:19:50 +0900 Subject: [PATCH] driver core: Don't ignore class_dir_create_and_add() failure. syzbot i

Re: INFO: rcu detected stall in __schedule

I'm not sure whether this is a PPP bug. As of uptime = 484, RCU says that it stalled for 125 seconds. -- [ 484.407032] INFO: rcu_sched self-detected stall on CPU [ 484.412488] 0-...!: (125000 ticks this GP) idle=f3e/1/4611686018427387906 softirq=112858/112858 fqs=0 [ 484.422300]

Re: [4.15-rc9] fs_reclaim lockdep trace

Peter Zijlstra wrote: > On Mon, Jan 29, 2018 at 08:47:20PM +0900, Tetsuo Handa wrote: > > Peter Zijlstra wrote: > > > On Sun, Jan 28, 2018 at 02:55:28PM +0900, Tetsuo Handa wrote: > > > > This warning seems to be caused by commit d92a8cfcb37ecd13 > > >

Re: kernel panic: Out of memory and no killable processes... (2)

syzbot wrote: > syzbot hit the following crash on net-next commit > 6bb46bc57c8e9ce947cc605e555b7204b44d2b10 (Fri Jan 26 16:00:23 2018 +) > Merge branch 'cxgb4-fix-dump-collection-when-firmware-crashed' > > C reproducer is attached. > syzkaller reproducer is attached. > Raw console output is

Re: [4.15-rc9] fs_reclaim lockdep trace

Peter Zijlstra wrote: > On Sun, Jan 28, 2018 at 02:55:28PM +0900, Tetsuo Handa wrote: > > This warning seems to be caused by commit d92a8cfcb37ecd13 > > ("locking/lockdep: Rework FS_RECLAIM annotation") which moved the > > location of > >

Re: [4.15-rc9] fs_reclaim lockdep trace

Linus Torvalds wrote: > On Sat, Jan 27, 2018 at 2:24 PM, Dave Jones wrote: >> On Tue, Jan 23, 2018 at 08:36:51PM -0500, Dave Jones wrote: >> > Just triggered this on a server I was rsync'ing to. >> >> Actually, I can trigger this really easily, even with an rsync from

Re: [4.15-rc9] fs_reclaim lockdep trace

On 2018/01/28 10:16, Tetsuo Handa wrote: > Linus Torvalds wrote: >> On Sat, Jan 27, 2018 at 2:24 PM, Dave Jones <da...@codemonkey.org.uk> wrote: >>> On Tue, Jan 23, 2018 at 08:36:51PM -0500, Dave Jones wrote: >>> > Just triggered this on a server I was r

Re: [4.15-rc9] fs_reclaim lockdep trace

Dave, would you try below patch? >From cae2cbf389ae3cdef1b492622722b4aeb07eb284 Mon Sep 17 00:00:00 2001 From: Tetsuo Handa <penguin-ker...@i-love.sakura.ne.jp> Date: Sun, 28 Jan 2018 14:17:14 +0900 Subject: [PATCH] lockdep: Fix fs_reclaim warning. Dave Jones reported fs_reclai

Re: [PATCH v2] lockdep: Fix fs_reclaim warning.

Nikolay Borisov wrote: > I think I've hit another incarnation of that one. The call stack is: > http://paste.opensuse.org/3f22d013 > > The cleaned up callstack of all the ? entries look like: > > __lock_acquire+0x2d8a/0x4b70 > lock_acquire+0x110/0x330 > kmem_cache_alloc+0x29/0x2c0 >

[PATCH v2] lockdep: Fix fs_reclaim warning.

>From 361d37a7d36978020dfb4c11ec1f4800937ccb68 Mon Sep 17 00:00:00 2001 From: Tetsuo Handa <penguin-ker...@i-love.sakura.ne.jp> Date: Thu, 8 Feb 2018 10:35:35 +0900 Subject: [PATCH v2] lockdep: Fix fs_reclaim warning. Dave Jones reported fs_reclaim lockdep

Re: [PATCH v2] lockdep: Fix fs_reclaim warning.

Peter, are you OK with this patch? Tetsuo Handa wrote: > From 361d37a7d36978020dfb4c11ec1f4800937ccb68 Mon Sep 17 00:00:00 2001 > From: Tetsuo Handa <penguin-ker...@i-love.sakura.ne.jp> > Date: Thu, 8 Feb 2018 10:35:35 +0900 > Subject: [PATCH v2] lockdep: Fix fs_reclaim warnin

Re: WARNING: refcount bug in should_fail

Eric W. Biederman wrote: > Al Viro writes: > > > On Mon, Apr 02, 2018 at 10:59:34PM +0100, Al Viro wrote: > > > >> FWIW, I'm going through the ->kill_sb() instances, fixing that sort > >> of bugs (most of them preexisting, but I should've checked instead > >> of assuming

Re: WARNING: refcount bug in should_fail

syzbot wrote: > > On Sun, Mar 4, 2018 at 6:57 AM, Tetsuo Handa > > <penguin-ker...@i-love.sakura.ne.jp> wrote: > >> Switching from mm to fsdevel, for this report says that put_net(net) in > >> rpc_kill_sb() made net->count < 0 when mount_ns() fail

Re: WARNING: refcount bug in should_fail

Dmitry Vyukov wrote: > On Sun, Apr 1, 2018 at 12:32 PM, Dmitry Vyukov <dvyu...@google.com> wrote: > > On Sun, Mar 4, 2018 at 6:57 AM, Tetsuo Handa > > <penguin-ker...@i-love.sakura.ne.jp> wrote: > >> Switching from mm to fsdevel, for this report says that put

Re: WARNING: refcount bug in should_fail

Switching from mm to fsdevel, for this report says that put_net(net) in rpc_kill_sb() made net->count < 0 when mount_ns() failed due to register_shrinker() failure. Relevant commits will be commit 9ee332d99e4d5a97 ("sget(): handle failures of register_shrinker()") and commit d91ee87d8d85a080

Re: bpf: Massive skbuff_head_cache memory leak?

Hello, Alexei and Daniel. Can you show us how to run testcases you are testing? On 2018/09/22 22:25, Tetsuo Handa wrote: > Hello. > > syzbot is reporting many lockup problems on bpf.git / bpf-next.git / net.git > / net-next.git trees. > > INFO: