Re: [PATCH v2 0/4] Introduce LSM-hook for socketpair(2)
On Fri, 4 May 2018, David Herrmann wrote: > Hi > > This is v2 of the socketpair(2) LSM hook introduction. Thanks, all applied to git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/linux-security.git next-general -- James Morris <jmor...@namei.org>
Re: [PATCH 0/3] Introduce LSM-hook for socketpair(2)
On Wed, 25 Apr 2018, Paul Moore wrote: > On Wed, Apr 25, 2018 at 2:44 PM, James Morris <jmor...@namei.org> wrote: > > On Mon, 23 Apr 2018, David Herrmann wrote: > >> This patch series tries to close this gap and makes both behave the > >> same. A new LSM-hook is added which allows LSMs to cache the correct > >> peer information on newly created socket-pairs. > > > > Looks okay to me. > > > > Once it's respun with the Smack backend and maybe the hook name change, > > I'll merge this unless DaveM wants it to go in via his networking tree. > > Note my objection to the hook placement in patch 2/3; I think we > should move the hook out of the AF_UNIX layer and up into the socket > layer. I vote for this as it maintains the intended abstraction of the socket API. -- James Morris <jmor...@namei.org>
Re: [PATCH 0/3] Introduce LSM-hook for socketpair(2)
On Mon, 23 Apr 2018, David Herrmann wrote: > This patch series tries to close this gap and makes both behave the > same. A new LSM-hook is added which allows LSMs to cache the correct > peer information on newly created socket-pairs. Looks okay to me. Once it's respun with the Smack backend and maybe the hook name change, I'll merge this unless DaveM wants it to go in via his networking tree. -- James Morris <jmor...@namei.org>
Re: [BUG] kernel stack corruption during/after Netlabel error
On Thu, 30 Nov 2017, Eric Dumazet wrote: > On Wed, 2017-11-29 at 19:16 -0800, Casey Schaufler wrote: > > On 11/29/2017 4:31 PM, James Morris wrote: > > > On Wed, 29 Nov 2017, Casey Schaufler wrote: > > > > > > > I see that there is a proposed fix later in the thread, but I > > > > don't see > > > > the patch. Could you send it to me, so I can try it on my > > > > problem? > > > > > > Forwarded off-list. > > > > The patch does fix the problem I was seeing in Smack. > > Can you guys test the following more complete patch ? > > It should cover IPv4 and IPv6, and also the corner cases. Tested-by: James Morris <james.l.mor...@oracle.com> -- James Morris <james.l.mor...@oracle.com>
Re: [BUG] kernel stack corruption during/after Netlabel error
On Wed, 29 Nov 2017, Casey Schaufler wrote: > I see that there is a proposed fix later in the thread, but I don't see > the patch. Could you send it to me, so I can try it on my problem? Forwarded off-list. Interestingly, I didn't see the KASAN output email from Stephen here. -- James Morris <james.l.mor...@oracle.com>
Re: [BUG] kernel stack corruption during/after Netlabel error
On Wed, 29 Nov 2017, Eric Dumazet wrote:
> On Wed, 2017-11-29 at 12:23 -0800, Eric Dumazet wrote:
> >
> > I suspect this exposes an ancient bug, caused by fact that TCP moves
> > IP[6]CB in skb->cb[]
> >
> > Basically the 2nd tcp_filter() added in commit
> > 8fac365f63c866a00015fa13932d8ffc584518b8
> > ("tcp: Add a tcp_filter hook before handle ack packet") was not
> > expecting selinux code being called a 2nd time,
> > while skb->cb[] has been mangled [1]
> >
> > [1]
> > memmove(_SKB_CB(skb)->header.h4, IPCB(skb),
> > sizeof(struct inet_skb_parm));
>
> Please try this fix for IPv4 (a similar patch will be needed for IPv6)
>
> net/ipv4/tcp_ipv4.c | 51 ++
> 1 file changed, 32 insertions(+), 19 deletions(-)
Works for me, no crashes with the testsuite running in a loop.
Tested-by: James Morris <james.l.mor...@oracle.com>
--
James Morris
<james.l.mor...@oracle.com>
[BUG] kernel stack corruption during/after Netlabel error
I'm seeing a kernel stack corruption bug (detected via gcc) when running the SELinux testsuite on a 4.15-rc1 kernel, in the 2nd inet_socket test: https://github.com/SELinuxProject/selinux-testsuite/blob/master/tests/inet_socket/test # Verify that unauthorized client cannot communicate with the server. $result = system "runcon -t test_inet_bad_client_t -- $basedir/client stream 127.0.0.1 65535 2>&1"; This correctlly causes an access control error in the Netlabel code, and the bug seems to be triggered during the ICMP send: [ 339.806024] SELinux: failure in selinux_parse_skb(), unable to parse packet [ 339.822505] Kernel panic - not syncing: stack-protector: Kernel stack is corrupted in: 81745af5 [ 339.822505] [ 339.852250] CPU: 4 PID: 3642 Comm: client Not tainted 4.15.0-rc1-test #15 [ 339.868498] Hardware name: LENOVO 10FGS0VA1L/30BC, BIOS FWKT68A 01/19/2017 [ 339.885060] Call Trace: [ 339.896875] [ 339.908103] dump_stack+0x63/0x87 [ 339.920645] panic+0xe8/0x248 [ 339.932668] ? ip_push_pending_frames+0x33/0x40 [ 339.946328] ? icmp_send+0x525/0x530 [ 339.958861] ? kfree_skbmem+0x60/0x70 [ 339.971431] __stack_chk_fail+0x1b/0x20 [ 339.984049] icmp_send+0x525/0x530 [ 339.996205] ? netlbl_skbuff_err+0x36/0x40 [ 340.008997] ? selinux_netlbl_err+0x11/0x20 [ 340.021816] ? selinux_socket_sock_rcv_skb+0x211/0x230 [ 340.035529] ? security_sock_rcv_skb+0x3b/0x50 [ 340.048471] ? sk_filter_trim_cap+0x44/0x1c0 [ 340.061246] ? tcp_v4_inbound_md5_hash+0x69/0x1b0 [ 340.074562] ? tcp_filter+0x2c/0x40 [ 340.086400] ? tcp_v4_rcv+0x820/0xa20 [ 340.098329] ? ip_local_deliver_finish+0x71/0x1a0 [ 340.111279] ? ip_local_deliver+0x6f/0xe0 [ 340.123535] ? ip_rcv_finish+0x3a0/0x3a0 [ 340.135523] ? ip_rcv_finish+0xdb/0x3a0 [ 340.147442] ? ip_rcv+0x27c/0x3c0 [ 340.158668] ? inet_del_offload+0x40/0x40 [ 340.170580] ? __netif_receive_skb_core+0x4ac/0x900 [ 340.183285] ? rcu_accelerate_cbs+0x5b/0x80 [ 340.195282] ? __netif_receive_skb+0x18/0x60 [ 340.207288] ? process_backlog+0x95/0x140 [ 340.218948] ? net_rx_action+0x26c/0x3b0 [ 340.230416] ? __do_softirq+0xc9/0x26a [ 340.241625] ? do_softirq_own_stack+0x2a/0x40 [ 340.253368] [ 340.262673] ? do_softirq+0x50/0x60 [ 340.273450] ? __local_bh_enable_ip+0x57/0x60 [ 340.285045] ? ip_finish_output2+0x175/0x350 [ 340.296403] ? ip_finish_output+0x127/0x1d0 [ 340.307665] ? nf_hook_slow+0x3c/0xb0 [ 340.318230] ? ip_output+0x72/0xe0 [ 340.328524] ? ip_fragment.constprop.54+0x80/0x80 [ 340.340070] ? ip_local_out+0x35/0x40 [ 340.350497] ? ip_queue_xmit+0x15c/0x3f0 [ 340.361060] ? __kmalloc_reserve.isra.40+0x31/0x90 [ 340.372484] ? __skb_clone+0x2e/0x130 [ 340.382633] ? tcp_transmit_skb+0x558/0xa10 [ 340.393262] ? tcp_connect+0x938/0xad0 [ 340.403370] ? ktime_get_with_offset+0x4c/0xb0 [ 340.414206] ? tcp_v4_connect+0x457/0x4e0 [ 340.424471] ? __inet_stream_connect+0xb3/0x300 [ 340.435195] ? inet_stream_connect+0x3b/0x60 [ 340.445607] ? SYSC_connect+0xd9/0x110 [ 340.455455] ? __audit_syscall_entry+0xaf/0x100 [ 340.466112] ? syscall_trace_enter+0x1d0/0x2b0 [ 340.476636] ? __audit_syscall_exit+0x209/0x290 [ 340.487151] ? SyS_connect+0xe/0x10 [ 340.496453] ? do_syscall_64+0x67/0x1b0 [ 340.506078] ? entry_SYSCALL64_slow_path+0x25/0x25 [ 340.516693] Kernel Offset: disabled [ 340.526393] Rebooting in 11 seconds.. This is mostly reliable, and I'm only seeing it on bare metal (not in a virtualbox vm). The SELinux skb parse error at the start only sometimes appears, and looking at the code, I suspect some kind of memory corruption being the cause at that point (basic packet header checks). I bisected the bug down to the following change: commit bffa72cf7f9df842f0016ba03586039296b4caaf Author: Eric Dumazet <eduma...@google.com> Date: Tue Sep 19 05:14:24 2017 -0700 net: sk_buff rbnode reorg ... Anyone else able to reproduce this, or have any ideas on what's happening? - James -- James Morris <james.l.mor...@oracle.com>
Re: [PATCH v5 next 0/5] Improve Module autoloading infrastructure
On Mon, 27 Nov 2017, Kees Cook wrote: > > if (WARN_ON_ONCE(!capable(CAP_SYS_MODULE) || > > !capable(CAP_SYS_ADMIN) || > > !capable(CAP_NET_ADMIN) || > > !unprivileged_autoload(module_name))) (Side note: the capable() calls would ideally come after the whitelist check). > We have some of this already with the module prefixes. Doing this > per-module would need to be exported to userspace, I think. It'd be > way too fragile sitting in the kernel. What about writing a whitelist to /proc (per-task) or /sys/fs (global) ? The per-task whitelist is inherited from the global one by default, or from a parent process if it's been modified in the parent. -- James Morris <james.l.mor...@oracle.com>
Re: [PATCH v5 next 0/5] Improve Module autoloading infrastructure
On Tue, 28 Nov 2017, David Miller wrote:
> From: Linus Torvalds <torva...@linux-foundation.org>
> Date: Mon, 27 Nov 2017 10:41:30 -0800
>
> > What are the real life use-cases for normal users having modules
> > auto-load?
>
> User opens SCTP socket, SCTP protocol module loads.
>
> People build test cases via namespaces, and in that namespaces normal
> users can setup virtual tunnel devices themselves, and those configure
> operations can bring the tunnel module in.
What about implementing a white list of modules which are able to be
loaded by unprivileged users?
Then, Linus' solution would look something like:
va_start(args, fmt);
ret = vsnprintf(module_name, MODULE_NAME_LEN, fmt, args);
va_end(args);
if (WARN_ON_ONCE(!capable(CAP_SYS_MODULE) ||
!capable(CAP_SYS_ADMIN) ||
!capable(CAP_NET_ADMIN) ||
!unprivileged_autoload(module_name)))
return -EPERM;
--
James Morris
<james.l.mor...@oracle.com>
Re: [RFC PATCH 1/5] security: Add support for SCTP security hooks
On Tue, 17 Oct 2017, Richard Haines wrote: > The SCTP security hooks are explained in: > Documentation/security/LSM-sctp.txt > > Signed-off-by: Richard Haines <richard_c_hai...@btinternet.com> > --- > Documentation/security/LSM-sctp.txt | 212 > > include/linux/lsm_hooks.h | 37 +++ > include/linux/security.h| 27 + > security/security.c | 23 > 4 files changed, 299 insertions(+) > create mode 100644 Documentation/security/LSM-sctp.txt This looks ok from an LSM API pov, but note that I'm not an expert on SCTP. It would be good to see more review from networking folk. Reviewed-by: James Morris <james.l.mor...@oracle.com> -- James Morris <james.l.mor...@oracle.com>
Re: [PATCH net-next v7 5/5] selinux: bpf: Add addtional check for bpf object file receive
On Wed, 18 Oct 2017, Chenbo Feng wrote: > From: Chenbo Feng <fe...@google.com> > > Introduce a bpf object related check when sending and receiving files > through unix domain socket as well as binder. It checks if the receiving > process have privilege to read/write the bpf map or use the bpf program. > This check is necessary because the bpf maps and programs are using a > anonymous inode as their shared inode so the normal way of checking the > files and sockets when passing between processes cannot work properly on > eBPF object. This check only works when the BPF_SYSCALL is configured. > > Signed-off-by: Chenbo Feng <fe...@google.com> > Acked-by: Stephen Smalley <s...@tycho.nsa.gov> Reviewed-by: James Morris <james.l.mor...@oracle.com> -- James Morris <james.l.mor...@oracle.com>
Re: [PATCH net-next v7 4/5] selinux: bpf: Add selinux check for eBPF syscall operations
On Wed, 18 Oct 2017, Chenbo Feng wrote: > From: Chenbo Feng <fe...@google.com> > > Implement the actual checks introduced to eBPF related syscalls. This > implementation use the security field inside bpf object to store a sid that > identify the bpf object. And when processes try to access the object, > selinux will check if processes have the right privileges. The creation > of eBPF object are also checked at the general bpf check hook and new > cmd introduced to eBPF domain can also be checked there. > > Signed-off-by: Chenbo Feng <fe...@google.com> > Acked-by: Alexei Starovoitov <a...@kernel.org> Reviewed-by: James Morris <james.l.mor...@oracle.com> -- James Morris <james.l.mor...@oracle.com>
Re: [PATCH net-next v7 3/5] security: bpf: Add LSM hooks for bpf object related syscall
On Wed, 18 Oct 2017, Chenbo Feng wrote: > From: Chenbo Feng <fe...@google.com> > > Introduce several LSM hooks for the syscalls that will allow the > userspace to access to eBPF object such as eBPF programs and eBPF maps. > The security check is aimed to enforce a per object security protection > for eBPF object so only processes with the right priviliges can > read/write to a specific map or use a specific eBPF program. Besides > that, a general security hook is added before the multiplexer of bpf > syscall to check the cmd and the attribute used for the command. The > actual security module can decide which command need to be checked and > how the cmd should be checked. > > Signed-off-by: Chenbo Feng <fe...@google.com> Acked-by: James Morris <james.l.mor...@oracle.com> -- James Morris <james.l.mor...@oracle.com>
Re: [PATCH net-next v6 0/5] bpf: security: New file mode and LSM hooks for eBPF object permission control
On Wed, 18 Oct 2017, David Miller wrote: > Series applied. I hadn't gotten to reviewing this patchset yet. Please wait for more acks/reviews from LSM folk for things touching security/, next time. -- James Morris <james.l.mor...@oracle.com>
Re: [PATCH net-next 2/4] security: bpf: Add LSM hooks for bpf object related syscall
On Wed, 4 Oct 2017, Chenbo Feng wrote:
> int bpf_map_new_fd(struct bpf_map *map, int flags)
> {
> + if (security_bpf_map(map, OPEN_FMODE(flags)))
> + return -EPERM;
> +
Don't hardcode -EPERM here, return the actual error from
security_bpf_map().
> + if (security_bpf_prog(prog))
> + return -EPERM;
> +
Same.
> + err = security_bpf(cmd, , size);
> + if (err)
> + return -EPERM;
Same.
- James
Re: [PATCH net-next v7 04/10] bpf: Define handle_fs and add a new helper bpf_handle_fs_get_mode()
On Mon, 21 Aug 2017, Mickaël Salaün wrote:
> @@ -85,6 +90,8 @@ enum bpf_arg_type {
>
> ARG_PTR_TO_CTX, /* pointer to context */
> ARG_ANYTHING, /* any (initialized) argument is ok */
> +
> + ARG_CONST_PTR_TO_HANDLE_FS, /* pointer to an abstract FS struct */
> };
Looks like a spurious empty line.
--
James Morris
<jmor...@namei.org>
Re: [kernel-hardening] Re: [PATCH net-next v7 02/10] bpf: Add eBPF program subtype and is_valid_subtype() verifier
On Wed, 23 Aug 2017, Mickaël Salaün wrote:
> >> + struct {
> >> + __u32 abi; /* minimal ABI version, cf. user doc */
> >
> > the concept of abi (version) sounds a bit weird to me.
> > Why bother with it at all?
> > Once the first set of patches lands the kernel as whole will have landlock
> > feature
> > with a set of helpers, actions, event types.
> > Some future patches will extend the landlock feature step by step.
> > This abi concept assumes that anyone who adds new helper would need
> > to keep incrementing this 'abi'. What value does it give to user or to
> > kernel?
> > The users will already know that landlock is present in kernel 4.14 or
> > whatever
> > and the kernel 4.18 has more landlock features. Why bother with extra abi
> > number?
>
> That's right for helpers and context fields, but we can't check the use
> of one field's content. The status field is intended to be a bitfield
> extendable in the future. For example, one use case is to set a flag to
> inform the eBPF program that it was already called with the same context
> and can skip most of its check (if not related to maps). Same goes for
> the FS action bitfield, one may want to add more of them. Another
> example may be the check for abilities. We may want to relax/remove the
> capability require to set one of them. With an ABI version, the user can
> easily check if the current kernel support that.
Don't call it an ABI, perhaps minimum policy version (similar to
what SELinux does). Changes need to be made so that any existing
userspace still works.
--
James Morris
<jmor...@namei.org>
Re: [PATCH net-next v7 02/10] bpf: Add eBPF program subtype and is_valid_subtype() verifier
On Tue, 22 Aug 2017, Alexei Starovoitov wrote: > more general question: what is the status of security/ bits? > I'm assuming they still need to be reviewed and explicitly acked by James, > right? Yep, along with other core security developers where possible. -- James Morris <jmor...@namei.org>
Re: [kernel-hardening] [PATCH net-next v7 00/10] Landlock LSM: Toward unprivileged sandboxing
On Mon, 21 Aug 2017, Mickaël Salaün wrote: > ## Why a new LSM? Are SELinux, AppArmor, Smack and Tomoyo not good enough? > > The current access control LSMs are fine for their purpose which is to give > the > *root* the ability to enforce a security policy for the *system*. What is > missing is a way to enforce a security policy for any application by its > developer and *unprivileged user* as seccomp can do for raw syscall filtering. > You could mention here that the first case is Mandatory Access Control, in general terms. -- James Morris <jmor...@namei.org>
Re: [PATCH] MAINTAINERS: update the NetLabel and Labeled Networking information
On Thu, 10 Aug 2017, Paul Moore wrote: > On Thu, Aug 10, 2017 at 3:13 PM, Paul Moore <pmo...@redhat.com> wrote: > > From: Paul Moore <p...@paul-moore.com> > > > > Signed-off-by: Paul Moore <p...@paul-moore.com> > > --- > > MAINTAINERS | 24 ++-- > > 1 file changed, 14 insertions(+), 10 deletions(-) > > I'm planning on sending this up via the SELinux tree with some other > MAINTAINERS updates, consider this more of a FYI posting. Oops, already applied to -next. > > > diff --git a/MAINTAINERS b/MAINTAINERS > > index 65990909fe73..be25ebaaeec3 100644 > > --- a/MAINTAINERS > > +++ b/MAINTAINERS > > @@ -9112,15 +9112,6 @@ F: net/*/netfilter/ > > F: net/netfilter/ > > F: net/bridge/br_netfilter*.c > > > > -NETLABEL > > -M: Paul Moore <p...@paul-moore.com> > > -W: http://netlabel.sf.net > > -L: netdev@vger.kernel.org > > -S: Maintained > > -F: Documentation/netlabel/ > > -F: include/net/netlabel.h > > -F: net/netlabel/ > > - > > NETROM NETWORK LAYER > > M: Ralf Baechle <r...@linux-mips.org> > > L: linux-h...@vger.kernel.org > > @@ -9248,10 +9239,23 @@ F: net/ipv6/ > > F: include/net/ip* > > F: arch/x86/net/* > > > > -NETWORKING [LABELED] (NetLabel, CIPSO, Labeled IPsec, SECMARK) > > +NETWORKING [LABELED] (NetLabel, Labeled IPsec, SECMARK) > > M: Paul Moore <p...@paul-moore.com> > > +W: https://github.com/netlabel > > L: netdev@vger.kernel.org > > +L: linux-security-mod...@vger.kernel.org > > S: Maintained > > +F: Documentation/netlabel/ > > +F: include/net/calipso.h > > +F: include/net/cipso_ipv4.h > > +F: include/net/netlabel.h > > +F: include/uapi/linux/netfilter/xt_SECMARK.h > > +F: include/uapi/linux/netfilter/xt_CONNSECMARK.h > > +F: net/netlabel/ > > +F: net/ipv4/cipso_ipv4.c > > +F: net/ipv6/calipso.c > > +F: net/netfilter/xt_CONNSECMARK.c > > +F: net/netfilter/xt_SECMARK.c > > > > NETWORKING [TLS] > > M: Ilya Lesokhin <il...@mellanox.com> > > -- James Morris <jmor...@namei.org>
Re: [PATCH] MAINTAINERS: update the NetLabel and Labeled Networking information
On Thu, 10 Aug 2017, Paul Moore wrote: > From: Paul Moore <p...@paul-moore.com> > > Signed-off-by: Paul Moore <p...@paul-moore.com> Applied to git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/linux-security.git next -- James Morris <jmor...@namei.org>
Re: [PATCH v5 03/10] bpf: Define handle_fs and add a new helper bpf_handle_fs_get_mode()
On Wed, 22 Feb 2017, Mickaël Salaün wrote:
> Add an eBPF function bpf_handle_fs_get_mode(handle_fs) to get the mode
> of a an abstract object wrapping either a file, a dentry, a path, or an
> inode.
>
> Changes since v4:
> * use a file abstraction (handle) to wrap inode, dentry, path and file
> structs
Good to see these abstractions. As discussed at LPC, we need to ensure
that we don't couple the Landlock API too closely with the LSM API, as the
former is an ABI exposed to userland -- we don't want to lose the ability
to change LSM internally due to breaking Landlock policies.
> @@ -82,6 +87,8 @@ enum bpf_arg_type {
>
> ARG_PTR_TO_CTX, /* pointer to context */
> ARG_ANYTHING, /* any (initialized) argument is ok */
> +
> + ARG_CONST_PTR_TO_HANDLE_FS, /* pointer to an abstract FS struct */
> };
Extraneous whitespace?
--
James Morris
<jmor...@namei.org>
Re: [PATCH 0/2] Quiet noisy LSM denial when accessing net sysctl
On Thu, 2 Jun 2016, Tyler Hicks wrote: > On 05/17/2016 09:13 AM, Tyler Hicks wrote: > > On 05/08/2016 10:56 PM, David Miller wrote: > >> From: Tyler Hicks <tyhi...@canonical.com> > >> Date: Fri, 6 May 2016 18:04:12 -0500 > >> > >>> This pair of patches does away with what I believe is a useless denial > >>> audit message when a privileged process initially accesses a net sysctl. > >> > >> The LSM folks can apply this if they agree with you. > > > > Hi James - Could you pick up these two bug fix patches? Thanks! > > Hello - Just checking in again to see if you plan on taking these > through the security tree? Sure, please resend. -- James Morris <jmor...@namei.org>
Re: [v3] skbuff: Do not scrub skb mark within the same name space
On Thu, 16 Apr 2015, Herbert Xu wrote: On Wed, Apr 15, 2015 at 05:41:26PM +0200, Nicolas Dichtel wrote: Le 15/04/2015 15:57, Herbert Xu a écrit : On Wed, Apr 15, 2015 at 06:22:29PM +0800, Herbert Xu wrote: [snip] Subject: skbuff: Do not scrub skb mark within the same name space The commit ea23192e8e577dfc51e0f4fc5ca113af334edff9 (tunnels: Maybe add a Fixes tag? Fixes: ea23192e8e57 (tunnels: harmonize cleanup done on skb on rx path) harmonize cleanup done on skb on rx path) broke anyone trying to use netfilter marking across IPv4 tunnels. While most of the fields that are cleared by skb_scrub_packet don't matter, the netfilter mark must be preserved. This patch rearranges skb_scurb_packet to preserve the mark field. nit: s/scurb/scrub Else it's fine for me. Sure. PS I used the wrong email for James the first time around. So let me repeat the question here. Should secmark be preserved or cleared across tunnels within the same name space? In fact, do our security models even support name spaces? They don't support namespaces, and maintaining the label is critical for SELinux, at least, which mediates security for the system as a whole. -- James Morris jmor...@namei.org
Re: [RFC PATCH v2 1/2] NET: Clone the sk_buff 'iif' field in __skb_clone()
On Mon, 7 Jan 2008, Paul Moore wrote: Both NetLabel and SELinux (other LSMs may grow to use it as well) rely on the 'iif' field to determine the receiving network interface of inbound packets. Unfortunately, at present this field is not preserved across a skb clone operation which can lead to garbage values if the cloned skb is sent back through the network stack. This patch corrects this problem by properly copying the 'iif' field in __skb_clone() and removing the 'iif' field assignment from skb_act_clone() since it is no longer needed. Also, while we are here, put the assignments in the same order as the offsets to reduce cacheline bounces. Signed-off-by: Paul Moore [EMAIL PROTECTED] Dave, perhaps this one should pushed to Linus now as a bugfix? --- include/net/sch_generic.h |1 - net/core/skbuff.c | 11 ++- 2 files changed, 6 insertions(+), 6 deletions(-) diff --git a/include/net/sch_generic.h b/include/net/sch_generic.h index c926551..4c3b351 100644 --- a/include/net/sch_generic.h +++ b/include/net/sch_generic.h @@ -325,7 +325,6 @@ static inline struct sk_buff *skb_act_clone(struct sk_buff *skb, gfp_t gfp_mask) n-tc_verd = SET_TC_VERD(n-tc_verd, 0); n-tc_verd = CLR_TC_OK2MUNGE(n-tc_verd); n-tc_verd = CLR_TC_MUNGED(n-tc_verd); - n-iif = skb-iif; } return n; } diff --git a/net/core/skbuff.c b/net/core/skbuff.c index 5b4ce9b..b628377 100644 --- a/net/core/skbuff.c +++ b/net/core/skbuff.c @@ -416,16 +416,17 @@ static struct sk_buff *__skb_clone(struct sk_buff *n, struct sk_buff *skb) C(len); C(data_len); C(mac_len); - n-cloned = 1; n-hdr_len = skb-nohdr ? skb_headroom(skb) : skb-hdr_len; + n-cloned = 1; n-nohdr = 0; n-destructor = NULL; - C(truesize); - atomic_set(n-users, 1); - C(head); - C(data); + C(iif); C(tail); C(end); + C(head); + C(data); + C(truesize); + atomic_set(n-users, 1); atomic_inc((skb_shinfo(skb)-dataref)); skb-cloned = 1; -- To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html -- James Morris [EMAIL PROTECTED] -- To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC PATCH v9 06/18] LSM: Add inet_sys_snd_skb() LSM hook (fwd)
This is part of a large patchset which finally fixes labeled networking,
which we're hoping to get into 2.6.25.
Thread @ http://thread.gmane.org/gmane.linux.kernel.lsm/4894
The patch below is the only one which is not self-contained impacts on
core networking code.
If anyone has any objections or comments on this patch, please let us
know.
-- Forwarded message --
Date: Fri, 21 Dec 2007 12:09:28 -0500
From: Paul Moore [EMAIL PROTECTED]
To: [EMAIL PROTECTED], [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED], [EMAIL PROTECTED]
Subject: [RFC PATCH v9 06/18] LSM: Add inet_sys_snd_skb() LSM hook
Add an inet_sys_snd_skb() LSM hook to allow the LSM to provide packet level
access control for all outbound packets. Using the existing postroute_last
netfilter hook turns out to be problematic as it is can be invoked multiple
times for a single packet, e.g. individual IPsec transforms, adding unwanted
overhead and complicating the security policy.
Signed-off-by: Paul Moore [EMAIL PROTECTED]
---
include/linux/security.h | 11 +++
net/ipv4/ip_output.c |7 +++
net/ipv6/ip6_output.c|5 +
security/dummy.c |8 +++-
security/security.c |6 ++
5 files changed, 36 insertions(+), 1 deletions(-)
diff --git a/include/linux/security.h b/include/linux/security.h
index db19c92..1b8d332 100644
--- a/include/linux/security.h
+++ b/include/linux/security.h
@@ -876,6 +876,10 @@ struct request_sock;
* Sets the connection's peersid to the secmark on skb.
* @req_classify_flow:
* Sets the flow's sid to the openreq sid.
+ * @inet_sys_snd_skb:
+ * Check permissions on outgoing network packets.
+ * @skb is the packet to check
+ * @family is the packet's address family
*
* Security hooks for XFRM operations.
*
@@ -1416,6 +1420,7 @@ struct security_operations {
void (*inet_csk_clone)(struct sock *newsk, const struct request_sock
*req);
void (*inet_conn_established)(struct sock *sk, struct sk_buff *skb);
void (*req_classify_flow)(const struct request_sock *req, struct flowi
*fl);
+ int (*inet_sys_snd_skb)(struct sk_buff *skb, int family);
#endif /* CONFIG_SECURITY_NETWORK */
#ifdef CONFIG_SECURITY_NETWORK_XFRM
@@ -2328,6 +2333,7 @@ void security_sk_free(struct sock *sk);
void security_sk_clone(const struct sock *sk, struct sock *newsk);
void security_sk_classify_flow(struct sock *sk, struct flowi *fl);
void security_req_classify_flow(const struct request_sock *req, struct flowi
*fl);
+int security_inet_sys_snd_skb(struct sk_buff *skb, int family);
void security_sock_graft(struct sock*sk, struct socket *parent);
int security_inet_conn_request(struct sock *sk,
struct sk_buff *skb, struct request_sock *req);
@@ -2471,6 +2477,11 @@ static inline void security_req_classify_flow(const
struct request_sock *req, st
{
}
+static inline int security_inet_sys_snd_skb(struct sk_buff *skb, int family)
+{
+ return 0;
+}
+
static inline void security_sock_graft(struct sock* sk, struct socket *parent)
{
}
diff --git a/net/ipv4/ip_output.c b/net/ipv4/ip_output.c
index fd99fbd..82a7297 100644
--- a/net/ipv4/ip_output.c
+++ b/net/ipv4/ip_output.c
@@ -204,6 +204,8 @@ static inline int ip_skb_dst_mtu(struct sk_buff *skb)
static int ip_finish_output(struct sk_buff *skb)
{
+ int err;
+
#if defined(CONFIG_NETFILTER) defined(CONFIG_XFRM)
/* Policy lookup after SNAT yielded a new policy */
if (skb-dst-xfrm != NULL) {
@@ -211,6 +213,11 @@ static int ip_finish_output(struct sk_buff *skb)
return dst_output(skb);
}
#endif
+
+ err = security_inet_sys_snd_skb(skb, AF_INET);
+ if (err)
+ return err;
+
if (skb-len ip_skb_dst_mtu(skb) !skb_is_gso(skb))
return ip_fragment(skb, ip_finish_output2);
else
diff --git a/net/ipv6/ip6_output.c b/net/ipv6/ip6_output.c
index 6338a9c..44ddf32 100644
--- a/net/ipv6/ip6_output.c
+++ b/net/ipv6/ip6_output.c
@@ -72,8 +72,13 @@ static __inline__ void ipv6_select_ident(struct sk_buff
*skb, struct frag_hdr *f
static int ip6_output_finish(struct sk_buff *skb)
{
+ int err;
struct dst_entry *dst = skb-dst;
+ err = security_inet_sys_snd_skb(skb, AF_INET6);
+ if (err)
+ return err;
+
if (dst-hh)
return neigh_hh_output(dst-hh, skb);
else if (dst-neighbour)
diff --git a/security/dummy.c b/security/dummy.c
index 0b62f95..384979a 100644
--- a/security/dummy.c
+++ b/security/dummy.c
@@ -848,6 +848,11 @@ static inline void dummy_req_classify_flow(const struct
request_sock *req,
struct flowi *fl)
{
}
+
+static inline int dummy_inet_sys_snd_skb(struct sk_buff *skb, int family)
+{
+ return 0;
+}
#endif /* CONFIG_SECURITY_NETWORK */
#ifdef CONFIG_SECURITY_NETWORK_XFRM
@@ -1122,7 +1127,8 @@ void security_fixup_ops (struct security_operations *ops)
Re: [RFC PATCH] LSM: Add inet_sys_snd_skb() LSM hook
On Wed, 19 Dec 2007, Paul Moore wrote: Add an inet_sys_snd_skb() LSM hook to allow the LSM to provide packet level access control for all outbound packets. Using the existing postroute_last netfilter hook turns out to be problematic as it is can be invoked multiple times for a single packet, e.g. individual IPsec transforms, adding unwanted overhead and complicating the security policy. I'm fine to ack this from a security pov -- any objections on the networking side? - James -- James Morris [EMAIL PROTECTED] -- To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3] XFRM: Assorted IPsec fixups
On Thu, 20 Dec 2007, Paul Moore wrote:
This patch fixes a number of small but potentially troublesome things in the
XFRM/IPsec code:
* Use the 'audit_enabled' variable already in include/linux/audit.h
Removed the need for extern declarations local to each XFRM audit fuction
* Convert 'sid' to 'secid' everywhere we can
The 'sid' name is specific to SELinux, 'secid' is the common naming
convention used by the kernel when refering to tokenized LSM labels,
unfortunately we have to leave 'ctx_sid' in 'struct xfrm_sec_ctx' otherwise
we risk breaking userspace
* Convert address display to use standard NIP* macros
Similar to what was recently done with the SPD audit code, this also also
includes the removal of some unnecessary memcpy() calls
* Move common code to xfrm_audit_common_stateinfo()
Code consolidation from the less is more book on software development
* Proper spacing around commas in function arguments
Minor style tweak since I was already touching the code
Signed-off-by: Paul Moore [EMAIL PROTECTED]
Acked-by: James Morris [EMAIL PROTECTED]
---
include/net/xfrm.h | 14 ++---
net/xfrm/xfrm_policy.c | 15 ++
net/xfrm/xfrm_state.c | 53
3 files changed, 36 insertions(+), 46 deletions(-)
diff --git a/include/net/xfrm.h b/include/net/xfrm.h
index 32b99e2..ac6cf09 100644
--- a/include/net/xfrm.h
+++ b/include/net/xfrm.h
@@ -548,7 +548,7 @@ struct xfrm_audit
};
#ifdef CONFIG_AUDITSYSCALL
-static inline struct audit_buffer *xfrm_audit_start(u32 auid, u32 sid)
+static inline struct audit_buffer *xfrm_audit_start(u32 auid, u32 secid)
{
struct audit_buffer *audit_buf = NULL;
char *secctx;
@@ -561,8 +561,8 @@ static inline struct audit_buffer *xfrm_audit_start(u32
auid, u32 sid)
audit_log_format(audit_buf, auid=%u, auid);
- if (sid != 0
- security_secid_to_secctx(sid, secctx, secctx_len) == 0) {
+ if (secid != 0
+ security_secid_to_secctx(secid, secctx, secctx_len) == 0) {
audit_log_format(audit_buf, subj=%s, secctx);
security_release_secctx(secctx, secctx_len);
} else
@@ -571,13 +571,13 @@ static inline struct audit_buffer *xfrm_audit_start(u32
auid, u32 sid)
}
extern void xfrm_audit_policy_add(struct xfrm_policy *xp, int result,
- u32 auid, u32 sid);
+ u32 auid, u32 secid);
extern void xfrm_audit_policy_delete(struct xfrm_policy *xp, int result,
- u32 auid, u32 sid);
+ u32 auid, u32 secid);
extern void xfrm_audit_state_add(struct xfrm_state *x, int result,
- u32 auid, u32 sid);
+ u32 auid, u32 secid);
extern void xfrm_audit_state_delete(struct xfrm_state *x, int result,
- u32 auid, u32 sid);
+ u32 auid, u32 secid);
#else
#define xfrm_audit_policy_add(x, r, a, s)do { ; } while (0)
#define xfrm_audit_policy_delete(x, r, a, s) do { ; } while (0)
diff --git a/net/xfrm/xfrm_policy.c b/net/xfrm/xfrm_policy.c
index d2084b1..c8f0656 100644
--- a/net/xfrm/xfrm_policy.c
+++ b/net/xfrm/xfrm_policy.c
@@ -24,6 +24,7 @@
#include linux/netfilter.h
#include linux/module.h
#include linux/cache.h
+#include linux/audit.h
#include net/dst.h
#include net/xfrm.h
#include net/ip.h
@@ -2317,15 +2318,14 @@ static inline void
xfrm_audit_common_policyinfo(struct xfrm_policy *xp,
}
}
-void
-xfrm_audit_policy_add(struct xfrm_policy *xp, int result, u32 auid, u32 sid)
+void xfrm_audit_policy_add(struct xfrm_policy *xp, int result,
+u32 auid, u32 secid)
{
struct audit_buffer *audit_buf;
- extern int audit_enabled;
if (audit_enabled == 0)
return;
- audit_buf = xfrm_audit_start(sid, auid);
+ audit_buf = xfrm_audit_start(auid, secid);
if (audit_buf == NULL)
return;
audit_log_format(audit_buf, op=SPD-add res=%u, result);
@@ -2334,15 +2334,14 @@ xfrm_audit_policy_add(struct xfrm_policy *xp, int
result, u32 auid, u32 sid)
}
EXPORT_SYMBOL_GPL(xfrm_audit_policy_add);
-void
-xfrm_audit_policy_delete(struct xfrm_policy *xp, int result, u32 auid, u32
sid)
+void xfrm_audit_policy_delete(struct xfrm_policy *xp, int result,
+ u32 auid, u32 secid)
{
struct audit_buffer *audit_buf;
- extern int audit_enabled;
if (audit_enabled == 0)
return;
- audit_buf = xfrm_audit_start(sid, auid);
+ audit_buf = xfrm_audit_start(auid, secid);
if (audit_buf == NULL)
return;
audit_log_format(audit_buf, op=SPD-delete res=%u, result);
diff --git a/net/xfrm/xfrm_state.c b/net/xfrm
Re: [PATCH 2/3] XFRM: RFC4303 compliant auditing
On Thu, 20 Dec 2007, Paul Moore wrote:
This patch adds a number of new IPsec audit events to meet the auditing
requirements of RFC4303. This includes audit hooks for the following events:
* Could not find a valid SA [sections 2.1, 3.4.2]
. xfrm_audit_state_notfound()
. xfrm_audit_state_notfound_simple()
* Sequence number overflow [section 3.3.3]
. xfrm_audit_state_replay_overflow()
* Replayed packet [section 3.4.3]
. xfrm_audit_state_replay()
* Integrity check failure [sections 3.4.4.1, 3.4.4.2]
. xfrm_audit_state_icvfail()
While RFC4304 deals only with ESP most of the changes in this patch apply to
IPsec in general, i.e. both AH and ESP. The one case, integrity check
failure, where ESP specific code had to be modified the same was done to the
AH code for the sake of consistency.
Signed-off-by: Paul Moore [EMAIL PROTECTED]
Acked-by: James Morris [EMAIL PROTECTED]
---
include/net/xfrm.h | 33 --
net/ipv4/ah4.c |4 +
net/ipv4/esp4.c|1
net/ipv6/ah6.c |2 -
net/ipv6/esp6.c|1
net/ipv6/xfrm6_input.c |4 +
net/xfrm/xfrm_input.c |6 +-
net/xfrm/xfrm_output.c |2 +
net/xfrm/xfrm_policy.c | 14 ++--
net/xfrm/xfrm_state.c | 153
+++-
10 files changed, 184 insertions(+), 36 deletions(-)
diff --git a/include/net/xfrm.h b/include/net/xfrm.h
index ac6cf09..941d5cd 100644
--- a/include/net/xfrm.h
+++ b/include/net/xfrm.h
@@ -548,26 +548,33 @@ struct xfrm_audit
};
#ifdef CONFIG_AUDITSYSCALL
-static inline struct audit_buffer *xfrm_audit_start(u32 auid, u32 secid)
+static inline struct audit_buffer *xfrm_audit_start(const char *op)
{
struct audit_buffer *audit_buf = NULL;
- char *secctx;
- u32 secctx_len;
+ if (audit_enabled == 0)
+ return NULL;
audit_buf = audit_log_start(current-audit_context, GFP_ATOMIC,
- AUDIT_MAC_IPSEC_EVENT);
+ AUDIT_MAC_IPSEC_EVENT);
if (audit_buf == NULL)
return NULL;
+ audit_log_format(audit_buf, op=%s, op);
+ return audit_buf;
+}
- audit_log_format(audit_buf, auid=%u, auid);
+static inline void xfrm_audit_helper_usrinfo(u32 auid, u32 secid,
+ struct audit_buffer *audit_buf)
+{
+ char *secctx;
+ u32 secctx_len;
+ audit_log_format(audit_buf, auid=%u, auid);
if (secid != 0
security_secid_to_secctx(secid, secctx, secctx_len) == 0) {
audit_log_format(audit_buf, subj=%s, secctx);
security_release_secctx(secctx, secctx_len);
} else
audit_log_task_context(audit_buf);
- return audit_buf;
}
extern void xfrm_audit_policy_add(struct xfrm_policy *xp, int result,
@@ -578,11 +585,22 @@ extern void xfrm_audit_state_add(struct xfrm_state *x,
int result,
u32 auid, u32 secid);
extern void xfrm_audit_state_delete(struct xfrm_state *x, int result,
u32 auid, u32 secid);
+extern void xfrm_audit_state_replay_overflow(struct xfrm_state *x,
+ struct sk_buff *skb);
+extern void xfrm_audit_state_notfound_simple(struct sk_buff *skb, u16
family);
+extern void xfrm_audit_state_notfound(struct sk_buff *skb, u16 family,
+ __be32 net_spi, __be32 net_seq);
+extern void xfrm_audit_state_icvfail(struct xfrm_state *x,
+ struct sk_buff *skb, u8 proto);
#else
#define xfrm_audit_policy_add(x, r, a, s)do { ; } while (0)
#define xfrm_audit_policy_delete(x, r, a, s) do { ; } while (0)
#define xfrm_audit_state_add(x, r, a, s) do { ; } while (0)
#define xfrm_audit_state_delete(x, r, a, s) do { ; } while (0)
+#define xfrm_audit_state_replay_overflow(x, s) do { ; } while (0)
+#define xfrm_audit_state_notfound_simple(s, f) do { ; } while (0)
+#define xfrm_audit_state_notfound(s, f, sp, sq) do { ; } while (0)
+#define xfrm_audit_state_icvfail(x, s, p)do { ; } while (0)
#endif /* CONFIG_AUDITSYSCALL */
static inline void xfrm_pol_hold(struct xfrm_policy *policy)
@@ -1193,7 +1211,8 @@ extern int xfrm_state_delete(struct xfrm_state *x);
extern int xfrm_state_flush(u8 proto, struct xfrm_audit *audit_info);
extern void xfrm_sad_getinfo(struct xfrmk_sadinfo *si);
extern void xfrm_spd_getinfo(struct xfrmk_spdinfo *si);
-extern int xfrm_replay_check(struct xfrm_state *x, __be32 seq);
+extern int xfrm_replay_check(struct xfrm_state *x,
+ struct sk_buff *skb, __be32 seq);
extern void xfrm_replay_advance(struct xfrm_state *x, __be32 seq);
extern void xfrm_replay_notify(struct xfrm_state *x, int event);
extern int xfrm_state_mtu(struct xfrm_state *x, int mtu);
diff --git a/net/ipv4
Re: [PATCH 3/3] XFRM: Drop packets when replay counter would overflow
On Thu, 20 Dec 2007, Paul Moore wrote:
According to RFC4303, section 3.3.3 we need to drop outgoing packets which
cause the replay counter to overflow:
3.3.3. Sequence Number Generation
The sender's counter is initialized to 0 when an SA is established.
The sender increments the sequence number (or ESN) counter for this
SA and inserts the low-order 32 bits of the value into the Sequence
Number field. Thus, the first packet sent using a given SA will
contain a sequence number of 1.
If anti-replay is enabled (the default), the sender checks to ensure
that the counter has not cycled before inserting the new value in the
Sequence Number field. In other words, the sender MUST NOT send a
packet on an SA if doing so would cause the sequence number to cycle.
An attempt to transmit a packet that would result in sequence number
overflow is an auditable event. The audit log entry for this event
SHOULD include the SPI value, current date/time, Source Address,
Destination Address, and (in IPv6) the cleartext Flow ID.
Signed-off-by: Paul Moore [EMAIL PROTECTED]
Acked-by: James Morris [EMAIL PROTECTED]
---
net/xfrm/xfrm_output.c |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/net/xfrm/xfrm_output.c b/net/xfrm/xfrm_output.c
index ebb..284eeef 100644
--- a/net/xfrm/xfrm_output.c
+++ b/net/xfrm/xfrm_output.c
@@ -57,8 +57,11 @@ static int xfrm_output_one(struct sk_buff *skb, int err)
if (x-type-flags XFRM_TYPE_REPLAY_PROT) {
XFRM_SKB_CB(skb)-seq = ++x-replay.oseq;
- if (unlikely(x-replay.oseq == 0))
+ if (unlikely(x-replay.oseq == 0)) {
+ x-replay.oseq--;
xfrm_audit_state_replay_overflow(x, skb);
+ goto error;
+ }
if (xfrm_aevent_is_on())
xfrm_replay_notify(x, XFRM_REPLAY_UPDATE);
}
--
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
James Morris
[EMAIL PROTECTED]
--
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH net-2.6.25] Add packet filtering based on process's security context.
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 [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH]: SELINUX fixup for netfilter hook changes
On Mon, 15 Oct 2007, David Miller wrote:
I just noticed a warning for this in my allmodconfig build,
so I checked in the obvious fix.
Thanks.
commit d0a23b19f552c4fd0126d903078ea5ceca968617
Author: David S. Miller [EMAIL PROTECTED]
Date: Mon Oct 15 02:58:25 2007 -0700
[SELINUX]: Update for netfilter -hook() arg changes.
They take a struct sk_buff * instead of a struct sk_buff ** now.
Signed-off-by: David S. Miller [EMAIL PROTECTED]
diff --git a/security/selinux/hooks.c b/security/selinux/hooks.c
index 3c3fff3..cf76150 100644
--- a/security/selinux/hooks.c
+++ b/security/selinux/hooks.c
@@ -3932,7 +3932,7 @@ out:
}
static unsigned int selinux_ip_postroute_last(unsigned int hooknum,
- struct sk_buff **pskb,
+ struct sk_buff *skb,
const struct net_device *in,
const struct net_device *out,
int (*okfn)(struct sk_buff *),
@@ -3941,7 +3941,6 @@ static unsigned int selinux_ip_postroute_last(unsigned
int hooknum,
char *addrp;
int len, err = 0;
struct sock *sk;
- struct sk_buff *skb = *pskb;
struct avc_audit_data ad;
struct net_device *dev = (struct net_device *)out;
struct sk_security_struct *sksec;
@@ -3977,23 +3976,23 @@ out:
}
static unsigned int selinux_ipv4_postroute_last(unsigned int hooknum,
- struct sk_buff **pskb,
+ struct sk_buff *skb,
const struct net_device *in,
const struct net_device *out,
int (*okfn)(struct sk_buff *))
{
- return selinux_ip_postroute_last(hooknum, pskb, in, out, okfn, PF_INET);
+ return selinux_ip_postroute_last(hooknum, skb, in, out, okfn, PF_INET);
}
#if defined(CONFIG_IPV6) || defined(CONFIG_IPV6_MODULE)
static unsigned int selinux_ipv6_postroute_last(unsigned int hooknum,
- struct sk_buff **pskb,
+ struct sk_buff *skb,
const struct net_device *in,
const struct net_device *out,
int (*okfn)(struct sk_buff *))
{
- return selinux_ip_postroute_last(hooknum, pskb, in, out, okfn,
PF_INET6);
+ return selinux_ip_postroute_last(hooknum, skb, in, out, okfn, PF_INET6);
}
#endif /* IPV6 */
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
James Morris
[EMAIL PROTECTED]
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] net: fix kernel_accept() error path
On Thu, 4 Oct 2007, Tony Battersby wrote:
If accept() returns an error, kernel_accept() releases the new socket
but passes a pointer to the released socket back to the caller. Make it
pass back NULL instead.
Signed-off-by: Tony Battersby [EMAIL PROTECTED]
---
--- linux-2.6.23-rc9/net/socket.c.bak 2007-10-04 15:21:17.0 -0400
+++ linux-2.6.23-rc9/net/socket.c 2007-10-04 15:21:22.0 -0400
@@ -2230,6 +2230,7 @@ int kernel_accept(struct socket *sock, s
err = sock-ops-accept(sock, *newsock, flags);
if (err 0) {
sock_release(*newsock);
+ *newsock = NULL;
goto done;
}
If you get an error back from kernel_accept, you should not be trying to
use newsock.
--
James Morris
[EMAIL PROTECTED]
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] Wild and crazy ideas involving struct sk_buff
On Wed, 22 Aug 2007, David Miller wrote: From: Paul Moore [EMAIL PROTECTED] Date: Wed, 22 Aug 2007 17:26:36 -0400 Was it just a thought, or was there some actual design/code/patchset to go along with it that described the idea? It was a thought mentioned at the first two netconfs, but it went nowhere because the more we discussed the implementation the more horrific it began to sound :-) Don't forget Rusty's skb reservation patches from 1999... -- James Morris [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] Wild and crazy ideas involving struct sk_buff
On Wed, 22 Aug 2007, Paul Moore wrote: Don't forget Rusty's skb reservation patches from 1999... I'm guessing those would probably need to be forward ported just a teensy weensy bit ;) The point being that the idea has been around since last century and has never gone anywhere :-) -- James Morris [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] NET: fix memory leaks from security_secid_to_secctx()
Both patches applied to: git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/selinux-2.6.git#for-akpm -- James Morris [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH]: revised make xfrm_audit_log more generic patch
On Mon, 23 Jul 2007, Joy Latten wrote: Revised patch that modifies xfrm_audit_log() such that it can accomodate auditing other ipsec events besides add/delete of an SA or SPD entry. This patch differs from original in that it does not remove existing ipsec audit defines so as to not break existing audit apps. This is a small change to accomodate updating ipsec protocol to RFCs 4301, 4302 and 4303 which require auditing some ipsec events if auditing is available. Please let me know if ok. Regards, Joy Signed-off-by: Joy Latten [EMAIL PROTECTED] Acked-by: James Morris [EMAIL PROTECTED] -- James Morris [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/1] Allow LSM to use IP address/port number.
On Sat, 21 Jul 2007, Tetsuo Handa wrote: I can't use netfilter infrastructure because it is too early to know who the recipant process of the packet is. I think the way forward on this is to re-visit the idea of providing a proper solution for the incoming packet/user match problem. I posted one possible solution a couple of years ago (skfilter): http://lwn.net/Articles/157137/ I think there has been some recent discussion by netfilter developers about this issue, so perhaps you could talk to them (cd'd Patrick). - James -- James Morris [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] make xfrm_audit_log more generic
On Thu, 19 Jul 2007, Joy Latten wrote: --- linux-2.6.22/include/linux/audit.h2007-07-19 13:17:22.0 -0500 +++ linux-2.6.22.patch/include/linux/audit.h 2007-07-19 13:21:29.0 -0500 @@ -108,10 +108,7 @@ #define AUDIT_MAC_CIPSOV4_DEL1408/* NetLabel: del CIPSOv4 DOI entry */ #define AUDIT_MAC_MAP_ADD1409/* NetLabel: add LSM domain mapping */ #define AUDIT_MAC_MAP_DEL1410/* NetLabel: del LSM domain mapping */ -#define AUDIT_MAC_IPSEC_ADDSA1411/* Add a XFRM state */ -#define AUDIT_MAC_IPSEC_DELSA1412/* Delete a XFRM state */ -#define AUDIT_MAC_IPSEC_ADDSPD 1413/* Add a XFRM policy */ -#define AUDIT_MAC_IPSEC_DELSPD 1414/* Delete a XFRM policy */ +#define AUDIT_MAC_IPSEC_EVENT1411/* Audit IPSec events */ Will this cause existing applications to break? - James -- James Morris [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: TCP stalls in current git, possibly splice related
On Fri, 13 Jul 2007, Jens Axboe wrote: On Fri, Jul 13 2007, Johannes Berg wrote: On Thu, 2007-07-12 at 16:12 -0400, James Morris wrote: I'm seeing TCP connection stalls with current git, and a bisect found the following as a possible cause: I'm also seeing stalls with synergy. Please try the below. Works for me. -- James Morris [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
TCP stalls in current git, possibly splice related
I'm seeing TCP connection stalls with current git, and a bisect found the following as a possible cause: 534f2aaa6ab07cd71164180bc958a7dcde41db11 is first bad commit commit 534f2aaa6ab07cd71164180bc958a7dcde41db11 Author: Jens Axboe [EMAIL PROTECTED] Date: Fri Jun 1 14:52:37 2007 +0200 sys_sendfile: switch to using -splice_read, if available This patch makes sendfile prefer to use -splice_read(), if it's available in the file_operations structure. Signed-off-by: Jens Axboe [EMAIL PROTECTED] It's a large patch, and not clear if it's the patch itself or coincidental to it. I've looked at some tcpdumps, but may not be able to get back to them until tomorrow or the weekend, thought it might be useful to get the report out now. - James -- James Morris [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: TCP stalls in current git, possibly splice related
On Thu, 12 Jul 2007, David Miller wrote: From: James Morris [EMAIL PROTECTED] Date: Thu, 12 Jul 2007 16:12:25 -0400 (EDT) I'm seeing TCP connection stalls with current git, and a bisect found the following as a possible cause: To add to this James is seeing this with distcc I believe. Correct. -- James Morris [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] IPv6: optionaly validate RAs on raw sockets
On Wed, 11 Jul 2007, David Miller wrote: One remaining corner case is NFS/IPv6 root, whereby userland won't have a chance to start before the network, and hence may miss the solicited RA. Or would it? By default, the next unsolicited RA can be anytime from now to after 10 minutes, so that's not sufficient. I wouldn't personnaly care, but... We already have cases like that with network device firmware that has to be loaded in from the filesystem in userspace, and the answer is to use a properly populated initrd. Same goes for things like this. That's the fact of life these days, like it or not. Same story for NFS root when using strong authentication -- something has to be running in userland to manage that. - James -- James Morris [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] Allow LSM to use IP address/port number. (was Re: [PATCH 1/1] Add post accept()/recvmsg() hooks.) (fwd)
(original cc list has wrong netdev addr) -- Forwarded message -- Date: Mon, 9 Jul 2007 15:17:28 -0400 (EDT) From: James Morris [EMAIL PROTECTED] To: Tetsuo Handa [EMAIL PROTECTED] Cc: [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] Subject: Re: [RFC] Allow LSM to use IP address/port number. (was Re: [PATCH 1/1] Add post accept()/recvmsg() hooks.) On Mon, 9 Jul 2007, Tetsuo Handa wrote: Hello. This thread is from http://marc.info/?t=11834645705r=1w=2 . I want to use tcp_wrapper-like filtering using LSM. The appropriate way to do this would be via netfilter queuing to userspace, as already suggested by Paul Moore. -- James Morris [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe linux-security-module in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] Allow LSM to use IP address/port number.
On Mon, 9 Jul 2007, Tetsuo Handa wrote: It drops messages from unwanted IP address/ports. (To be exact, it doesn't drop, it just tells userland process not to use received messages by returning errors.) This is broken. You need to properly fail the network operation and ensure that the peers are appropriately notified using the standard failure paths, not just arbitrarily propagate errors to the local user. - James -- James Morris [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] Allow LSM to use IP address/port number.
On Mon, 9 Jul 2007, Stephen Hemminger wrote: Isn't it better to hook into existing netfilter infrastructure somehow? Yes, it has been suggested several times. -- James Morris [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [SKBUFF]: Fix incorrect config #ifdef around skb_copy_secmark
Thanks. Acked-by: James Morris [EMAIL PROTECTED] -- James Morris [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] Allow group ownership of TUN/TAP devices (fwd)
-- Forwarded message --
Date: Mon, 18 Jun 2007 12:05:49 -0400
From: Jeff Dike [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Cc: Guido Guenther [EMAIL PROTECTED], LKML [EMAIL PROTECTED],
[EMAIL PROTECTED]
Subject: [PATCH] Allow group ownership of TUN/TAP devices
I recieved from Guido Guenther the patch below to the TUN/TAP driver
which allows group ownerships to be effective.
It seems reasonable to me.
the attached patches allow tun ownership by group. We found this useful
since we can then spawn tapX devices on system boot (via
/etc/network/interfaces) which logged on users can then use for their
virtual machines.
The first patch is for the kernel, the second one for the tunctl. They
shouldn't change existing behaviour and we introduced a new syscall for
the group setting. The user now is allowed to send packages if either
his euid or his egid matches the one specified via tunctl (via -u or -g
respecitvely). If both gid and uid are set via tunctl, both have to
match. In case you find these useful, please apply.
--
Work email - jdike at linux dot intel dot com
From: Guido Guenther [EMAIL PROTECTED]
Date: Fri, 25 May 2007 11:10:27 +0200
Subject: [PATCH] allow tun ownership by group
---
drivers/net/tun.c | 15 +--
include/linux/if_tun.h |2 ++
2 files changed, 15 insertions(+), 2 deletions(-)
diff --git a/drivers/net/tun.c b/drivers/net/tun.c
index a2c6caa..62b2b30 100644
--- a/drivers/net/tun.c
+++ b/drivers/net/tun.c
@@ -432,6 +432,7 @@ static void tun_setup(struct net_device *dev)
init_waitqueue_head(tun-read_wait);
tun-owner = -1;
+ tun-group = -1;
SET_MODULE_OWNER(dev);
dev-open = tun_net_open;
@@ -467,8 +468,11 @@ static int tun_set_iff(struct file *file, struct ifreq
*ifr)
return -EBUSY;
/* Check permissions */
- if (tun-owner != -1
- current-euid != tun-owner !capable(CAP_NET_ADMIN))
+ if (((tun-owner != -1
+ current-euid != tun-owner) ||
+(tun-group != -1
+ current-egid != tun-group))
+!capable(CAP_NET_ADMIN))
return -EPERM;
}
else if (__dev_get_by_name(ifr-ifr_name))
@@ -610,6 +614,13 @@ static int tun_chr_ioctl(struct inode *inode, struct file
*file,
DBG(KERN_INFO %s: owner set to %d\n, tun-dev-name,
tun-owner);
break;
+ case TUNSETGROUP:
+ /* Set group of the device */
+ tun-group= (gid_t) arg;
+
+ DBG(KERN_INFO %s: group set to %d\n, tun-dev-name,
tun-group);
+ break;
+
case TUNSETLINK:
/* Only allow setting the type when the interface is down */
if (tun-dev-flags IFF_UP) {
diff --git a/include/linux/if_tun.h b/include/linux/if_tun.h
index 88aef7b..42eb694 100644
--- a/include/linux/if_tun.h
+++ b/include/linux/if_tun.h
@@ -36,6 +36,7 @@ struct tun_struct {
unsigned long flags;
int attached;
uid_t owner;
+ gid_t group;
wait_queue_head_t read_wait;
struct sk_buff_head readq;
@@ -78,6 +79,7 @@ struct tun_struct {
#define TUNSETPERSIST _IOW('T', 203, int)
#define TUNSETOWNER _IOW('T', 204, int)
#define TUNSETLINK_IOW('T', 205, int)
+#define TUNSETGROUP _IOW('T', 206, int)
/* TUNSETIFF ifr flags */
#define IFF_TUN0x0001
--
1.5.1.4
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [2/2] 2.6.22-rc5: known regressions with patches
On Sun, 17 Jun 2007, Michal Piotrowski wrote: SELinux Subject: very high non-preempt latency in context_struct_compute_av() References : http://lkml.org/lkml/2007/6/4/78 Submitter : Ingo Molnar [EMAIL PROTECTED] Handled-By : Stephen Smalley [EMAIL PROTECTED] James Morris [EMAIL PROTECTED] Patch : http://lkml.org/lkml/2007/6/7/334 Status : patch available This patch is queued for -mm, and will be submitted for 2.6.23. - James -- James Morris [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] NetLabel: consolidate the struct socket/sock handling to just struct sock
On Thu, 7 Jun 2007, Paul Moore wrote: The current NetLabel code has some redundant APIs which allow both struct socket and struct sock types to be used; this may have made sense at some point but it is wasteful now. Remove the functions that operate on sockets and convert the callers. Not only does this make the code smaller and more consistent but it pushes the locking burden up to the caller which can be more intelligent about the locks. Also, perform the same conversion (socket to sock) on the SELinux/NetLabel glue code where it make sense. Signed-off-by: Paul Moore [EMAIL PROTECTED] Acked-by: James Morris [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] fix several unaligned kernel accesses in the CIPSO engine
On Thu, 7 Jun 2007, Paul Moore wrote: IPv4 options are not very well aligned within the packet and the format of a CIPSO option is even worse. The result is that the CIPSO engine in the kernel does a few unaligned accesses when parsing and validating incoming packets with CIPSO options attached which generate error messages on certain alignment sensitive platforms. This patch fixes this by marking these unaligned accesses with the get_unaliagned() macro. Signed-off-by: Paul Moore [EMAIL PROTECTED] Acked-by: James Morris [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH]: Add security check before flushing SAD/SPD
On Mon, 4 Jun 2007, Eric Paris wrote: Some time ago this thread bounced back and forth and seemed to come to rest with the patch below, I cleaned up the comments and put all the ACKs it received in one place below, but so much time has passed I doubt if they should still count for free. I also rediffed the patch against the latest miller tree. Is the idea or patch in any way flawed or unacceptable to people at the moment? Anyone willing to step up an re-ack the patch to get it moving into the tree? Looks good to me. Acked-by: James Morris [EMAIL PROTECTED] -- James Morris [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH]: Add security check before flushing SAD/SPD
I've applied this patch to git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/selinux-2.6.git#for-davem Dave, feel free to pull from that branch. - James -- James Morris [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
oops in net/ipv4/icmp.c:icmp_send() with icmp_errors_use_inbound_ifaddr (fwd)
-- Forwarded message --
Date: Mon, 14 May 2007 08:15:50 -0700 (PDT)
From: Curtis Doty [EMAIL PROTECTED]
To: Linux Kernel [EMAIL PROTECTED]
Subject: oops in net/ipv4/icmp.c:icmp_send() with icmp_errors_use_inbound_ifaddr
Summary: On a multi-homed box, after turning on
/proc/sys/net/ipv4/icmp_errors_use_inbound_ifaddr, it now periodically oopses
when trying to lookup the source address to use for sending an ICMP in response
to a jump ipt_REJECT.
I'm still trying to figure out what makes this test case unique. It spuriously
occurs with many fedora builds of 2.6.{18,19,20} all of which don't appear to
have any patches in this area of the kernel. Just _maybe_ it's because of a
combination of dogleg routing and overloading one vlan with multiple subnets:
# ip route list table main proto kernel scope link
10.10.36.208/28 dev eth0.1 src 10.10.36.210
10.10.36.224/27 dev eth0.1 src 10.10.36.226
10.10.1.0/24 dev eth0.5 src 10.10.1.48
10.10.2.0/24 dev eth0.9 src 10.10.2.27
10.10.10.0/24 dev eth0.8 src 10.10.10.1
Policy routing has been disabled and the problem still occurs. Only one route
remains. It is gw:
# ip route list table main proto boot
default via 10.10.36.209 dev eth0.1
Am I on the right track here or is this a distro/build/config issue? Here's the
oops:
BUG: unable to handle kernel NULL pointer dereference at virtual address
00a8
printing eip:
c05fe72b
*pde = 3d429067
Oops: [#1]
SMP
last sysfs file: /devices/platform/i2c-9191/name
Modules linked in: it87 hwmon_vid hwmon i2c_isa eeprom 8021q nf_nat_ftp
nf_conntrack_ftp ipt_REJECT ipt_owner ipt_ULOG xt_limit xt_state xt_multiport
iptable_filter xt_tcpudp iptable_nat nf_nat nf_conntrack_ipv4 nf_conntrack
nfnetlink ip_tables x_tables video sbs i2c_ec dock button battery asus_acpi
backlight ac parport_pc lp parport 8139too 8139cp mii pcspkr i2c_i801 i2c_i810
iTCO_wdt i2c_algo_bit i2c_core iTCO_vendor_support dm_snapshot dm_zero dm_mirror
dm_mod ata_piix libata sd_mod scsi_mod ext3 jbd ehci_hcd ohci_hcd uhci_hcd
CPU:0
EIP:0060:[c05fe72b]Not tainted VLI
EFLAGS: 00010246 (2.6.20-1.2948.fc6 #1)
EIP is at inet_select_addr+0x4/0x9f
eax: ebx: f8b97046 ecx: 00fd edx:
esi: 00fd edi: 0001 ebp: f71cd0ac esp: c078bc9c
ds: 007b es: 007b ss: 0068
Process swapper (pid: 0, ti=c078b000 task=c06fc480 task.ti=c0746000)
Stack: f8b97046 f601b130 c05fd0b6 f728b980 f728b980 f8b5adbb c05bcb6e c078bd74
0003 0003 0246 0246 f887e014 f8a611a6 f7c1ea80
f728b9a8 f727d220 f887e000 0001 0072 f7383800 f728b980
Call Trace:
[f8b97046] reject+0x0/0x4ae [ipt_REJECT]
[c05fd0b6] icmp_send+0x14d/0x39b
[f8b5adbb] nf_conntrack_free+0x18/0x20 [nf_conntrack]
[c05bcb6e] __kfree_skb+0xc5/0x10d
[f8a611a6] rtl8139_start_xmit+0xe2/0x112 [8139too]
[c05c12fc] dev_hard_start_xmit+0x1bc/0x21b
[c060e141] xfrm_decode_session+0x44/0x4b
[c0620667] _spin_lock_irqsave+0x9/0xd
[c042edc9] lock_timer_base+0x15/0x2f
[c042eed5] __mod_timer+0x94/0x9e
[f8b90406] ipt_ulog_packet+0x2f0/0x3ba [ipt_ULOG]
[f8b97046] reject+0x0/0x4ae [ipt_REJECT]
[f8b9709c] reject+0x56/0x4ae [ipt_REJECT]
[c06205bd] _spin_unlock_bh+0x5/0xd
[f8b904f6] ipt_ulog_target+0x26/0x2e [ipt_ULOG]
[f8b97046] reject+0x0/0x4ae [ipt_REJECT]
[f8b3d454] ipt_do_table+0x28c/0x2e8 [ip_tables]
[c05d7550] nf_iterate+0x38/0x6a
[c05d7681] nf_hook_slow+0x4d/0xb5
[c05dec14] dst_output+0x0/0x7
[c05e0f14] ip_queue_xmit+0x3a3/0x3f4
[c05dec14] dst_output+0x0/0x7
[c0422645] try_to_wake_up+0x3aa/0x3b4
[c05f47f1] tcp_v4_send_check+0x74/0xaa
[c05ef1c3] tcp_transmit_skb+0x6d5/0x703
[c05eff49] tcp_retransmit_skb+0x4b1/0x592
[c05e8db7] tcp_enter_loss+0x1a8/0x205
[c05f258b] tcp_write_timer+0x43f/0x638
[c0620655] _spin_unlock_irq+0x5/0x7
[c0439d17] hrtimer_run_queues+0x127/0x141
[c0422add] run_rebalance_domains+0x116/0x33e
[c05f214c] tcp_write_timer+0x0/0x638
[c042e51b] run_timer_softirq+0x101/0x164
[c042b7b0] __do_softirq+0x5d/0xba
[c040615b] do_softirq+0x59/0xb1
[c0419d4e] smp_apic_timer_interrupt+0x76/0x80
[c04049b0] apic_timer_interrupt+0x28/0x30
[c0402d52] default_idle+0x0/0x3e
[c061007b] __xfrm_policy_check+0x4c5/0x592
[c0402d7e] default_idle+0x2c/0x3e
[c04023d0] cpu_idle+0x9e/0xb7
[c074b812] start_kernel+0x3b6/0x3be
[c074b25a] unknown_bootoption+0x0/0x202
===
Code: eb 10 39 72 18 75 09 89 f8 33 42 14 85 c6 74 0e 8b 12 85 d2 74 08 f6 42 25
01 74 e6 31 d2 83 c4 0c 89 d0 5b 5e 5f c3 56 89 ce 53 8b 80 a8 00 00 00 85 c0
74 39 8b 48 0c 31 db eb 24 0f b6 41 24
EIP: [c05fe72b] inet_select_addr+0x4/0x9f SS:ESP 0068:c078bc9c
0Kernel panic - not syncing: Fatal exception in interrupt
0Rebooting in 60 seconds..
And a few relevant details:
# uname -a
Linux host 2.6.20-1.2948.fc6 #1 SMP Fri Apr 27 19:48:40 EDT 2007 i686 i686 i386
GNU/Linux
# lspci -tv
-[:00]-+-00.0 Intel Corporation 82845G/GL[Brookdale-G]/GE/PE DRAM
Controller/Host-Hub Interface
+-02.0 Intel
Re: [PATCH][IPSEC] fix panic when using inter address familiy IPsec on loopback
On Fri, 20 Apr 2007, Kazunori MIYAZAWA wrote: Hello, I send patches to fix panic when using inter address family IPsec on loopback device. These patches can be applied to current linux-2.6 and should also be net-2.6. Looks good to me, although I wonder why the !IFF_LOOPBACK check was there in the first place. - James -- James Morris [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
FYI: Xen or kernel bug? (fwd)
Could be an upstream kernel issue lurking. -- Forwarded message -- Date: Fri, 20 Apr 2007 22:21:26 +0200 From: Mark Stier [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: FYI: Xen or kernel bug? Hello, tcp_vegas produces division by zero kernel oopses in dom0 when running a Xen-patched 2.6.16.28 kernel. I have tracked down the problem to line #256 in tcp_vegas.c: presumably due to flaky Xen timing, the rtt seems to get zero from time to time (adding 1 to the rtt variable solves the problem for me). The same should apply to line #140 in tcp_veno.c, too. Best regards, Mark - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: PATCH[1/1]: kernel panic when large security contexts in ACQUIRE
On Fri, 13 Apr 2007, Joy Latten wrote:
Signed-off-by: Joy Latten [EMAIL PROTECTED]
Acked-by: James Morris [EMAIL PROTECTED]
diff -urpN linux-2.6.20/net/xfrm/xfrm_user.c
linux-2.6.20.patch/net/xfrm/xfrm_user.c
--- linux-2.6.20/net/xfrm/xfrm_user.c 2007-04-12 15:12:27.0 -0500
+++ linux-2.6.20.patch/net/xfrm/xfrm_user.c 2007-04-13 09:32:35.0
-0500
@@ -272,9 +272,8 @@ static int attach_encap_tmpl(struct xfrm
}
-static inline int xfrm_user_sec_ctx_size(struct xfrm_policy *xp)
+static inline int xfrm_user_sec_ctx_size(struct xfrm_sec_ctx *xfrm_ctx)
{
- struct xfrm_sec_ctx *xfrm_ctx = xp-security;
int len = 0;
if (xfrm_ctx) {
@@ -2170,7 +2169,7 @@ static int xfrm_send_acquire(struct xfrm
len = RTA_SPACE(sizeof(struct xfrm_user_tmpl) * xp-xfrm_nr);
len += NLMSG_SPACE(sizeof(struct xfrm_user_acquire));
- len += RTA_SPACE(xfrm_user_sec_ctx_size(xp));
+ len += RTA_SPACE(xfrm_user_sec_ctx_size(x-security));
#ifdef CONFIG_XFRM_SUB_POLICY
len += RTA_SPACE(sizeof(struct xfrm_userpolicy_type));
#endif
@@ -2280,7 +2279,7 @@ static int xfrm_exp_policy_notify(struct
len = RTA_SPACE(sizeof(struct xfrm_user_tmpl) * xp-xfrm_nr);
len += NLMSG_SPACE(sizeof(struct xfrm_user_polexpire));
- len += RTA_SPACE(xfrm_user_sec_ctx_size(xp));
+ len += RTA_SPACE(xfrm_user_sec_ctx_size(xp-security));
#ifdef CONFIG_XFRM_SUB_POLICY
len += RTA_SPACE(sizeof(struct xfrm_userpolicy_type));
#endif
--
James Morris
[EMAIL PROTECTED]
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Ensure local assignment bit on tun device MAC addr
On Sat, 31 Mar 2007, Rusty Russell wrote: This becomes especially important after the tun patch sitting in the -mm tree is applied, but it works standalone. Please apply. (See netdev posting Message-Id: [EMAIL PROTECTED]) == The effect of this bug was made worse by Brian Braunstein's patch to keep net_device.dev_addr and tun.dev_addr in sync. Signed-off-by: Rusty Russell [EMAIL PROTECTED] Acked-by: James Morris [EMAIL PROTECTED] diff -r fd8c40f4f533 drivers/net/tun.c --- a/drivers/net/tun.c Fri Mar 30 17:02:19 2007 +1000 +++ b/drivers/net/tun.c Sat Mar 31 10:30:47 2007 +1000 @@ -507,9 +507,7 @@ static int tun_set_iff(struct file *file tun-flags = flags; /* Be promiscuous by default to maintain previous behaviour. */ tun-if_flags = IFF_PROMISC; - /* Generate random Ethernet address. */ - *(u16 *)tun-dev_addr = htons(0x00FF); - get_random_bytes(tun-dev_addr + sizeof(u16), 4); + random_ether_addr(tun-dev_addr); memset(tun-chr_filter, 0, sizeof tun-chr_filter); tun_net_init(dev); - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html -- James Morris [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
LSPP kernels (was Re: [PATCH]: SAD sometimes has double SAs).
On Wed, 28 Mar 2007, Joy Latten wrote: Eric, sorry as I know you already patched lspp kernel for testing. I think it'd be better to have the lspp kernel join the upstream workflow process, rather than being a shortcut into RHEL. Please consider creating an lspp git tree (based off Linus' tree), then once patches there are tested and ready to submit upstream, post them here or selinux-list, where they can be reviewed and applied to either my or DaveM's git tree. From there, they'll be picked up in -mm for even wider testing then be merged into mainline as appropriate. Then, they can be incorporated into distro devel kernels when they update their kernels, or backported to stable distro kernels as already reviewed tested upstream patches. If there are any objections, please respond. - James -- James Morris [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] NET : secure sequence number functions can use nsec resolution instead of usec
On Wed, 28 Mar 2007, Eric Dumazet wrote: Hello David We could use the nanosec resolution for various functions defined in drivers/char/random.c (secure_tcpv6_sequence_number(), secure_tcp_sequence_number(), secure_dccp_sequence_number()) I am not sure if it's a netdev related patch or core kernel, so I have CC Andrew. Thank you [PATCH] NET : random functions can use nsec resolution instead of usec In order to get more randomness for secure_tcpv6_sequence_number(), secure_tcp_sequence_number(), secure_dccp_sequence_number() functions, we can use the high resolution time services, providing nanosec resolution. I've also done two kmalloc()/kzalloc() conversions. Signed-off-by: Eric Dumazet [EMAIL PROTECTED] Looks good to me. Acked-by: James Morris [EMAIL PROTECTED] - James -- James Morris [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: LSPP kernels (was Re: [PATCH]: SAD sometimes has double SAs).
On Wed, 28 Mar 2007, Eric Paris wrote: It is definitely NOT a shortcut into RHEL. Ok, that was a poor choice of words on my part. I don't want to give the impression that upstream is not coming first. All the work is being done upstream either on netdev or linux-audit and then I pull it back into this LSPP kernel she talked about so that people interested primarily in the testing necessary to meet that particular government standard have a neat tidy little prebuild rpm to work with. Eventually all of these will show up in RHEL, but not until all of the patches i'm dealing with are upstream. It seems my understanding wasn't clear on the overall workflow. If the consensus is to stay with this scheme, then please disregard my previous post. -- James Morris [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH]: Add security check before flushing SAD/SPD
On Mon, 26 Mar 2007, Joy Latten wrote:
Signed-off-by: Joy Latten[EMAIL PROTECTED]
This looks ok to me, although I have a couple of minor issues (which
should probably not stop it being merged):
+ if ((err = security_xfrm_policy_delete(pol)) != 0) {
The value of 'err' is implicitly inverted several times in this function
(and similarly in the state flush one). Something like
ret = (fn() != 0);
might be better.
+}
+ for (i = xfrm_policy_bydst[dir].hmask; i = 0; i--) {
Tab damage?
- James
--
James Morris
[EMAIL PROTECTED]
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH]: Add security check before flushing SAD/SPD
On Mon, 26 Mar 2007, James Morris wrote:
On Mon, 26 Mar 2007, Joy Latten wrote:
Signed-off-by: Joy Latten[EMAIL PROTECTED]
This looks ok to me, although I have a couple of minor issues (which
should probably not stop it being merged):
+ if ((err = security_xfrm_policy_delete(pol)) != 0) {
The value of 'err' is implicitly inverted several times in this function
(and similarly in the state flush one). Something like
ret = (fn() != 0);
Oops, ignore the above.
The correct idiom is:
err = fn();
if (err) {
/* handle error */
}
Please use that, to reduce confusion :-)
- James
--
James Morris
[EMAIL PROTECTED]
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH]: Add security check before flushing SAD/SPD
On Mon, 26 Mar 2007, Joy Latten wrote:
Sending again since one of the email addresses was incorrect.
Ok, I have made improvements based on James' and Eric's comments.
Acked-by: James Morris [EMAIL PROTECTED]
+ if (xfrm_id_proto_match(x-id.proto, proto)
+(err = security_xfrm_state_delete(x)) != 0) {
Still not a showstopper, but standard idiom would be nice at some point.
- James
--
James Morris
[EMAIL PROTECTED]
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH]: Add security check before flushing SAD/SPD
On Fri, 23 Mar 2007, Eric Paris wrote: Maybe I'm way out on a limb here but if I am a regular user and I say rm /tmp/* and I only have permissions to delete some of the files I expect just those couple to be delete, not the whole operation denied. I don't think this analogy holds up, as rm is a per-file deletion operation, and it is the shell which expands the wildcard for you. A 'flush' has a semantic implication that all entries will be removed, and it should be atomic and either succeed or fail at that granularity. - James -- James Morris [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH]: Add security check before flushing SAD/SPD
On Thu, 22 Mar 2007, Joy Latten wrote: I would look at this patch differently if there were some security level key being checked for a match here, which is an input key to the flush, but that is not what is happening here as the object is being looked at by itself. Yes, I understand what you are saying. I was concerned about having to check each entry to flush database. I did this patch because we check for authorization when deleting single specified entries from the SAD/SPD. It seem like a hole to me that we check for this, but that same user/process can delete the entire database with no checks. Indeed. Removing an entry is modifying MAC policy, which requires appropriate authorization. The security label is encapsulated with the object, which is why it's passed to the security layer. Perhaps a better semantic would be to fail the entire flush operation if one of the security checks failed. e.g. loop through for permissions first, then if all ok, loop through for deletion. - James -- James Morris [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] NetLabel: parse the CIPSO ranged tag on incoming packets
On Mon, 12 Mar 2007, Paul Moore wrote: Commit 484b366932be0b73a22c74a82748ca10a721643e added support for the CIPSO ranged categories tag. However, it appears that I made a mistake when rebasing then patch to the latest upstream sources for submission and dropped the part of the patch that actually parses the tag on incoming packets. This patch fixes this mistake by adding the required function call to the cipso_v4_skbuff_getattr() function. I've run this patch over the weekend and have not noticed any problems. Signed-off-by: Paul Moore [EMAIL PROTECTED] Acked-by: James Morris [EMAIL PROTECTED] --- net/ipv4/cipso_ipv4.c |5 + 1 file changed, 5 insertions(+) Index: net-2.6_bugfix_2/net/ipv4/cipso_ipv4.c === --- net-2.6_bugfix_2.orig/net/ipv4/cipso_ipv4.c +++ net-2.6_bugfix_2/net/ipv4/cipso_ipv4.c @@ -1933,6 +1933,11 @@ int cipso_v4_skbuff_getattr(const struct cipso_ptr[6], secattr); break; + case CIPSO_V4_TAG_RANGE: + ret_val = cipso_v4_parsetag_rng(doi_def, + cipso_ptr[6], + secattr); + break; } skbuff_getattr_return: -- paul moore linux security @ hp - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html -- James Morris [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Add xfrm policy change auditing to pfkey_spdget
On Thu, 8 Mar 2007, Eric Paris wrote: which didn't have my fix up because i didn't commit it to my local branch. Is there a better way to get a diff between my miller tree and 'everything in the branch I have checked out even if it is not committed'? I'd suggest you commit all your changes in local branches, then export them as emails via git-format-patch for posting. Something like: davem-upstream [1] +- for-davem [2] +- for-davem-prep [3] Do all of your work in [3], so you can manage the queue of patches there before merging/applying them into [2] as a final patch series. So, if one of the commits in [3] needs fixing, you can, for example, export commits up to that with git-format-patch, git-reset --hard to the broken commit, fix, compile, test then reapply the exported commits. Then, once it's all ready, merge into [2] (or export apply to avoid merge commits). This is just one possible workflow. There are probably several better. - James -- James Morris [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: compat_sock_common_getsockopt typo?
On Tue, 6 Mar 2007, Johannes Berg wrote:
The function reads as follows:
int compat_sock_common_getsockopt(struct socket *sock, int level, int optname,
char __user *optval, int __user *optlen)
{
struct sock *sk = sock-sk;
if (sk-sk_prot-compat_setsockopt != NULL)
^^^
return sk-sk_prot-compat_getsockopt(sk, level, optname,
^^^
optval, optlen);
return sk-sk_prot-getsockopt(sk, level, optname, optval, optlen);
}
EXPORT_SYMBOL(compat_sock_common_getsockopt);
Is that intentional to make protocol writers assign both if they want
compat_setsockopt? :P
It's a bug.
--
James Morris
[EMAIL PROTECTED]
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] fix compat_sock_common_getsockopt typo
On Tue, 6 Mar 2007, Johannes Berg wrote:
This patch fixes a typo in compat_sock_common_getsockopt.
Signed-off-by: Johannes Berg [EMAIL PROTECTED]
--- wireless-dev.orig/net/core/sock.c 2007-03-06 15:44:15.618565674 +0100
+++ wireless-dev/net/core/sock.c 2007-03-06 15:44:25.948565674 +0100
@@ -1597,7 +1597,7 @@ int compat_sock_common_getsockopt(struct
{
struct sock *sk = sock-sk;
- if (sk-sk_prot-compat_setsockopt != NULL)
+ if (sk-sk_prot-compat_getsockopt != NULL)
return sk-sk_prot-compat_getsockopt(sk, level, optname,
optval, optlen);
return sk-sk_prot-getsockopt(sk, level, optname, optval, optlen);
Acked-by: James Morris [EMAIL PROTECTED]
--
James Morris
[EMAIL PROTECTED]
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: when having to acquire an SA, ipsec drops the packet
On Tue, 6 Mar 2007, Joy Latten wrote: I saw something similar to this some time ago when testing various failure modes, and discused it with Herbert. IIRC, there's a larval SA which is not torn down properly by Racoon once the full SA is established, and the larval SA keeps resending until it times out. Ok, good to know. I thought a bit more about this last night but am not sure best way to fix it. Perhaps a way to keep larval SA around until all SAs resulting from xfrm_vec[xfrm_nr] are established... oh well, just thinking out loud... :-) I think the solution, if this actually the problem, is for the userland code to maintain the SAs. - James -- James Morris [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: netlink recvmsg() and MSG_TRUNC
On Tue, 6 Mar 2007, David Miller wrote: I guess one thing the user could do when it sees MSG_TRUNC is keep calling recvmsg() until the receive queue is emptied of packets, in order to get that pesky nlk-cb cleared to NULL, then resubmit. But that's rediculous and complicated. Any ideas? Only slightly less complicated: user calls recvmsg() once with a new flag MSG_FLUSH, which causes the queue to be flushed, then resubmits ? - James -- James Morris [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] xfrm_policy delete security check misplaced
On Mon, 5 Mar 2007, Venkat Yekkirala wrote: Signed-off-by: Eric Paris [EMAIL PROTECTED] Acked-by: Venkat Yekkirala [EMAIL PROTECTED] What about your previous comment: I guess you meant to do this here? else if (err) return err; -- James Morris [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] xfrm_policy delete security check misplaced
On Fri, 2 Mar 2007, Eric Paris wrote: Signed-off-by: Eric Paris [EMAIL PROTECTED] Acked-by: James Morris [EMAIL PROTECTED] -- James Morris [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Add xfrm policy change auditing to pfkey_spdget
On Fri, 2 Mar 2007, Eric Paris wrote: pfkey_spdget neither had an LSM security hook nor auditing for the removal of xfrm_policy structs. The security hook was added when it was moved into xfrm_policy_byid instead of the callers to that function by my earlier patch and this patch adds the auditing hooks as well. Signed-off-by: Eric Paris [EMAIL PROTECTED] Acked-by: James Morris [EMAIL PROTECTED] -- James Morris [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] xfrm audit hook misplaced in pfkey_delete and xfrm_del_sa
On Fri, 2 Mar 2007, Eric Paris wrote: Inside pfkey_delete and xfrm_del_sa the audit hooks were not called if there was any permission/security failures in attempting to do the del operation (such as permission denied from security_xfrm_state_delete). This patch moves the audit hook to the exit path such that all failures (and successes) will actually get audited. Signed-off-by: Eric Paris [EMAIL PROTECTED] Acked-by: James Morris [EMAIL PROTECTED] -- James Morris [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] NetLabel: Verify sensitivity level has a valid CIPSO mapping
On Wed, 28 Feb 2007, Paul Moore wrote:
The current CIPSO engine has a problem where it does not verify that the given
sensitivity level has a valid CIPSO mapping when the std CIPSO DOI type is
used. The end result is that bad packets are sent on the wire which should
have never been sent in the first place. This patch corrects this problem by
verifying the sensitivity level mapping similar to what is done with the
category mapping. This patch also changes the returned error code in this
case
to -EPERM to better match what the category mapping verification code returns.
Signed-off-by: Paul Moore [EMAIL PROTECTED]
[removed redhat-lspp, which is subscriber only]
Acked-by: James Morris [EMAIL PROTECTED]
---
net/ipv4/cipso_ipv4.c |7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
Index: net-2.6_bugfix/net/ipv4/cipso_ipv4.c
===
--- net-2.6_bugfix.orig/net/ipv4/cipso_ipv4.c
+++ net-2.6_bugfix/net/ipv4/cipso_ipv4.c
@@ -732,11 +732,12 @@ static int cipso_v4_map_lvl_hton(const s
*net_lvl = host_lvl;
return 0;
case CIPSO_V4_MAP_STD:
- if (host_lvl doi_def-map.std-lvl.local_size) {
+ if (host_lvl doi_def-map.std-lvl.local_size
+ doi_def-map.std-lvl.local[host_lvl] CIPSO_V4_INV_LVL) {
*net_lvl = doi_def-map.std-lvl.local[host_lvl];
return 0;
}
- break;
+ return -EPERM;
}
return -EINVAL;
@@ -771,7 +772,7 @@ static int cipso_v4_map_lvl_ntoh(const s
*host_lvl = doi_def-map.std-lvl.cipso[net_lvl];
return 0;
}
- break;
+ return -EPERM;
}
return -EINVAL;
--
paul moore
linux security @ hp
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
James Morris
[EMAIL PROTECTED]
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] net: Convert xtime.tv_sec to get_seconds()
Where appropriate, convert references to xtime.tv_sec to the
get_seconds() helper function.
Signed-off-by: James Morris [EMAIL PROTECTED]
---
Please review apply if ok.
include/net/tcp.h|4 ++--
net/ipv4/route.c |2 +-
net/ipv4/tcp_input.c |6 +++---
net/ipv4/tcp_ipv4.c | 10 +-
net/ipv4/tcp_minisocks.c |8
net/ipv6/xfrm6_output.c |2 +-
net/rxrpc/main.c |2 +-
net/xfrm/xfrm_policy.c | 12 ++--
net/xfrm/xfrm_state.c|6 +++---
9 files changed, 26 insertions(+), 26 deletions(-)
diff --git a/include/net/tcp.h b/include/net/tcp.h
index 5c472f2..fbeddcb 100644
--- a/include/net/tcp.h
+++ b/include/net/tcp.h
@@ -1011,7 +1011,7 @@ static inline int tcp_paws_check(const s
{
if ((s32)(rx_opt-rcv_tsval - rx_opt-ts_recent) = 0)
return 0;
- if (xtime.tv_sec = rx_opt-ts_recent_stamp + TCP_PAWS_24DAYS)
+ if (get_seconds() = rx_opt-ts_recent_stamp + TCP_PAWS_24DAYS)
return 0;
/* RST segments are not recommended to carry timestamp,
@@ -1026,7 +1026,7 @@ static inline int tcp_paws_check(const s
However, we can relax time bounds for RST segments to MSL.
*/
- if (rst xtime.tv_sec = rx_opt-ts_recent_stamp + TCP_PAWS_MSL)
+ if (rst get_seconds() = rx_opt-ts_recent_stamp + TCP_PAWS_MSL)
return 0;
return 1;
}
diff --git a/net/ipv4/route.c b/net/ipv4/route.c
index 37e0d4d..0b3d7bf 100644
--- a/net/ipv4/route.c
+++ b/net/ipv4/route.c
@@ -2683,7 +2683,7 @@ #endif
id = rt-peer-ip_id_count;
if (rt-peer-tcp_ts_stamp) {
ts = rt-peer-tcp_ts;
- tsage = xtime.tv_sec - rt-peer-tcp_ts_stamp;
+ tsage = get_seconds() - rt-peer-tcp_ts_stamp;
}
}
diff --git a/net/ipv4/tcp_input.c b/net/ipv4/tcp_input.c
index 1a14191..eb613cd 100644
--- a/net/ipv4/tcp_input.c
+++ b/net/ipv4/tcp_input.c
@@ -2737,7 +2737,7 @@ static int tcp_fast_parse_options(struct
static inline void tcp_store_ts_recent(struct tcp_sock *tp)
{
tp-rx_opt.ts_recent = tp-rx_opt.rcv_tsval;
- tp-rx_opt.ts_recent_stamp = xtime.tv_sec;
+ tp-rx_opt.ts_recent_stamp = get_seconds();
}
static inline void tcp_replace_ts_recent(struct tcp_sock *tp, u32 seq)
@@ -2751,7 +2751,7 @@ static inline void tcp_replace_ts_recent
*/
if((s32)(tp-rx_opt.rcv_tsval - tp-rx_opt.ts_recent) = 0 ||
- xtime.tv_sec = tp-rx_opt.ts_recent_stamp + TCP_PAWS_24DAYS)
+ get_seconds() = tp-rx_opt.ts_recent_stamp +
TCP_PAWS_24DAYS)
tcp_store_ts_recent(tp);
}
}
@@ -2803,7 +2803,7 @@ static inline int tcp_paws_discard(const
{
const struct tcp_sock *tp = tcp_sk(sk);
return ((s32)(tp-rx_opt.ts_recent - tp-rx_opt.rcv_tsval)
TCP_PAWS_WINDOW
- xtime.tv_sec tp-rx_opt.ts_recent_stamp + TCP_PAWS_24DAYS
+ get_seconds() tp-rx_opt.ts_recent_stamp + TCP_PAWS_24DAYS
!tcp_disordered_ack(sk, skb));
}
diff --git a/net/ipv4/tcp_ipv4.c b/net/ipv4/tcp_ipv4.c
index 0ba74bb..b34149b 100644
--- a/net/ipv4/tcp_ipv4.c
+++ b/net/ipv4/tcp_ipv4.c
@@ -149,7 +149,7 @@ int tcp_twsk_unique(struct sock *sk, str
*/
if (tcptw-tw_ts_recent_stamp
(twp == NULL || (sysctl_tcp_tw_reuse
-xtime.tv_sec - tcptw-tw_ts_recent_stamp 1))) {
+get_seconds() - tcptw-tw_ts_recent_stamp 1))) {
tp-write_seq = tcptw-tw_snd_nxt + 65535 + 2;
if (tp-write_seq == 0)
tp-write_seq = 1;
@@ -224,7 +224,7 @@ int tcp_v4_connect(struct sock *sk, stru
* when trying new connection.
*/
if (peer != NULL
- peer-tcp_ts_stamp + TCP_PAWS_MSL = xtime.tv_sec) {
+ peer-tcp_ts_stamp + TCP_PAWS_MSL = get_seconds()) {
tp-rx_opt.ts_recent_stamp = peer-tcp_ts_stamp;
tp-rx_opt.ts_recent = peer-tcp_ts;
}
@@ -1351,7 +1351,7 @@ #endif
(dst = inet_csk_route_req(sk, req)) != NULL
(peer = rt_get_peer((struct rtable *)dst)) != NULL
peer-v4daddr == saddr) {
- if (xtime.tv_sec peer-tcp_ts_stamp + TCP_PAWS_MSL
+ if (get_seconds() peer-tcp_ts_stamp + TCP_PAWS_MSL
(s32)(peer-tcp_ts - req-ts_recent)
TCP_PAWS_WINDOW) {
NET_INC_STATS_BH(LINUX_MIB_PAWSPASSIVEREJECTED);
@@ -1770,7 +1770,7 @@ int tcp_v4_remember_stamp(struct sock *s
if (peer) {
if ((s32)(peer-tcp_ts - tp-rx_opt.ts_recent) = 0 ||
- (peer-tcp_ts_stamp
Re: [PATCH 09/29] selinux: tag avc cache alloc as non-critical
On Wed, 21 Feb 2007, Peter Zijlstra wrote:
Failing to allocate a cache entry will only harm performance.
Signed-off-by: Peter Zijlstra [EMAIL PROTECTED]
---
security/selinux/avc.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Acked-by: James Morris [EMAIL PROTECTED]
Index: linux-2.6-git/security/selinux/avc.c
===
--- linux-2.6-git.orig/security/selinux/avc.c 2007-02-14 08:31:13.0
+0100
+++ linux-2.6-git/security/selinux/avc.c 2007-02-14 10:10:47.0
+0100
@@ -332,7 +332,7 @@ static struct avc_node *avc_alloc_node(v
{
struct avc_node *node;
- node = kmem_cache_zalloc(avc_node_cachep, GFP_ATOMIC);
+ node = kmem_cache_zalloc(avc_node_cachep, GFP_ATOMIC|__GFP_NOMEMALLOC);
if (!node)
goto out;
--
James Morris
[EMAIL PROTECTED]
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: ip_append_page and the socket send buffer
On Fri, 16 Feb 2007, Elad Lahav wrote: I wrote a function that is equivalent to udp_sendmsg, but uses ip_append_page to attach data to an skb. The function is implemented as follows: Why? Where is the code? -- James Morris [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: when having to acquire an SA, ipsec drops the packet
On Sun, 4 Feb 2007, David Miller wrote: Something like this (untested) on the ipv4 side, for example: Looks like it should work. Will do some testing. -- James Morris [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: when having to acquire an SA, ipsec drops the packet
On Mon, 5 Feb 2007, James Morris wrote: On Sun, 4 Feb 2007, David Miller wrote: Something like this (untested) on the ipv4 side, for example: Looks like it should work. Will do some testing. Appears to work well, with a slight delay on the first packet as expected. Tested with tcp, udp icmp. - James -- James Morris [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC][PATCH][XFRM][1/5] extension to XFRM for dynamic endpoint update (MIGRATE)
On Fri, 2 Feb 2007, Shinta Sugimoto wrote: +EXPORT_SYMBOL(xfrm_state_clone); Why not EXPORT_SYMBOL_GPL ? (for all of your exports). Actually I don't have specific preference on either EXPORT_SYMBOL or EXPORT_SYMBOL_GPL. It seemed to me that other functions defined in files under net/xfrm/ are using EXPORT_SYMBOL, so I followed that. Hmm, you're right, most of them are not _GPL. Do you think EXPORT_SYMBOL_GPL is more appropriate in this case? Well, I would have thought that users of xfrm were generally derivative of the kernel, but it doesn't make much sense to have only a couple of symbols exported as GPL, so probably keep it the way you already have it. - James -- James Morris [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC][PATCH][XFRM][1/5] extension to XFRM for dynamic endpoint update (MIGRATE)
On Thu, 1 Feb 2007, Shinta Sugimoto wrote:
+int xfrm_migrate(struct xfrm_selector *sel, u8 dir, u8 type,
+ struct xfrm_migrate *m, int num_migrate)
+{
+ int i, err, nx_cur = 0, nx_new = 0;
+ struct xfrm_policy *pol = NULL;
[...]
+donothing:
+ if (pol)
+ xfrm_pol_put(pol);
If you reach 'donothing', pol must be NULL, so you don't need to check for
it before xfrm_pol_put().
+#ifdef CONFIG_XFRM_MIGRATE
+static struct xfrm_algo *xfrm_algo_solidclone(struct xfrm_algo *orig)
+{
+ struct xfrm_algo *a;
+ a = kmalloc(sizeof(*orig) + orig-alg_key_len, GFP_KERNEL);
+ if (a)
+ memcpy(a, orig, sizeof(*orig) + orig-alg_key_len);
Use kmemdup() ?
+if (orig-encap) {
+ x-encap = kmalloc(sizeof(*x-encap), GFP_KERNEL);
+ if (!x-encap)
+ goto error;
+ memcpy(x-encap, orig-encap, sizeof(*x-encap));
+ }
+
+ if (orig-coaddr) {
+ x-coaddr = kmalloc(sizeof(*x-coaddr), GFP_KERNEL);
+ if (!x-coaddr)
+ goto error;
+ memcpy(x-coaddr, orig-coaddr, sizeof(*x-coaddr));
+ }
Ditto.
+EXPORT_SYMBOL(xfrm_state_clone);
Why not EXPORT_SYMBOL_GPL ?
(for all of your exports).
- James
--
James Morris
[EMAIL PROTECTED]
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC][PATCH][XFRM][4/5] extension to XFRM for dynamic endpoint update (MIGRATE)
On Thu, 1 Feb 2007, Shinta Sugimoto wrote: + /* allow IPSEC_PROTO_ANY to match all protocols */ + //sel.proto = pfkey_proto_to_xfrm(sa-sadb_address_proto); + sel.proto = sa-sadb_address_proto; Which one is correct ? :-) + /* allow IPSEC_PROTO_ANY to match all protocols */ + //sel.proto = pfkey_proto_to_xfrm(sa-sadb_address_proto); + sel.proto = sa-sadb_address_proto; ... - James -- James Morris [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: when having to acquire an SA, ipsec drops the packet
On Thu, 1 Feb 2007, Joy Latten wrote: IPsec returns EAGAIN when it needs to acquire an SA. There have been a thread or two about this... Has there been any info or progress in how best to fix this? James Morris presented some work/ideas, http://vger.kernel.org/jmorris_ipsec_sa_resolution_netconf2006.pdf The status of this is that I started refactoring some core IPv6 code (to bring it in line with the IPv4 code, e.g. create an ip6_route_connect() to match ip_route_connect(), and manage the packet queuing from there) and ran into some IPv6 bugs, and fixed those, but then ran out of time on the IPsec stuff. AFAIK, no other progress has been made. Generally, the problem is only seen when using the BSD userland, which does not proactively maintain SAs. Openswan does, and general IPsec users running it never see the problem, so it's not clear how high the priority is for fixing this really is in the general case. It's quite a lot of surgery on core networking to fix a problem which doesn't occur with the Linux tools, which seemingly most people use when they're not using proprietary and/or userland IPsec stacks. Non-kernel options include moving to Openswan (which I would hope is getting labeled networking support at some stage in any case), or have the BSD code proactively maintain SAs. Also, applications using TCP, and UDP applications with their own session management, will resend packets while the SA is being negotiated, which I've observed as typically completing before the first resend. I think one of the practical problems with this is that the apps are not expecting an EAGAIN and thus decide to crash. A quick dirty solution, which is what I think the BSD kernels do, is to still drop the packet but just not return an error to the app. The app then just sees a slight delay on the initial connection, as if a DNS lookup took a bit longer than usual. When using labeled xfrms (xfrms that contain a security context), there is potential for a greater amount of SAs to be created than when using regular xfrms. An SA may be created every time a different security context is encountered in a particular traffic stream. This could be many if each networking app has its own security context, making current behavior problematic. Do you have any examples of how many SAs would need to be created on a typical system? It may not be the end of the world if an MLS box has to negotiate a whole bunch of SAs when it boots up. - James -- James Morris [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [IPSEC] flow: Cache negative results
On Wed, 10 Jan 2007, Herbert Xu wrote: Hi: [IPSEC] flow: Cache negative security checks We did some work in this part of the code a few months back -- IIRC it was resolved correctly from a security point of view. (cc'ing Venkat Paul for review). This patch causes security policy denials to be cached instead of causing a relookup every time. This is OK because we already cache positive security policy results which is strictly worse as far as security is concerned. In particular, if the security system (not IPsec policies but the rules under security/) changes such that a positive result turns negative (denial), we will ignore it and continue to allow traffic through based on the cached policy. So if the security folks actually care about this, they'd need to flush the flow cache whenever a relevant change is made to the security database. Whether this is done or not does not affect this patch. Given that we do want to cache positive results even in the presence of SELinux (otherwise we might as well disable flow.c entirely), it is natural to cache negative results too. This patch also happens to fix a nasty bug where if an expiring flow entry that's not at the head happens to trigger a security denial, all entries before it are removed from the cache and leaked. Signed-off-by: Herbert Xu [EMAIL PROTECTED] Cheers, -- James Morris [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/2] A bugfix patchset for NetLabel
On Mon, 18 Dec 2006, Paul Moore wrote: ... however, I still think this might qualify for the 2.6.19 stable kernel. When a MLS sensitivity level or category maps to zero then whenever the NetLabel subsystem is called to resolve the security attributes of a packet it will, in certain configurations, return security attributes/contexts which are incorrect. Please let me know if you think that has merit for the stable tree and I'll send the patch to the stable mailing list. I really don't know. Try submitting them and see what happens :-) -- James Morris [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/2] A bugfix patchset for NetLabel
On Fri, 15 Dec 2006, [EMAIL PROTECTED] wrote: This patch set fixes two bugs that were found recently when adding new CIPSOv4 DOI definitions. These patches are pretty small and have been tested by a few different people on several different platforms. Applied to git://git.infradead.org/~jmorris/selinux-2.6#fixes Please apply these for 2.6.20 and they should probably be pushed to the 2.6.19 stable tree as well; is there anything special I need to do for that? I'm not sure that they qualify. The first is a privileged operation, right? For the second, what are the implications of mapping to zero? Also review Documentation/stable_kernel_rules.txt. -- James Morris [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: RFC: consistent disable_xfrm behaviour
On Mon, 4 Dec 2006, Patrick McHardy wrote: disable_xfrm - BOOLEAN Disable IPSEC encryption on this interface, whatever the policy Opinions? Looks good to me, wonder what the original rationale was, though. -- James Morris [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/1] additional ipsec audit patch
On Thu, 30 Nov 2006, Joy Latten wrote: I ran a stress test overnight using labeled ipsec on a patched lspp55 kernel using racoon last week. The additional patch to xfrm_state.c was my fault when rebasing to 2.6.19-rc6 to send upstream. I plan to run an ipv4 and ipv6 stress test tonight and tomorrow using labeled ipsec with auditing enabled on the lspp56 kernel, which contains ipsec audit patch, to ensure no regression has occurred. I can also run an ipv4 and ipv6 stress tests with regular ipsec over the weekend for further ensurance. I compiled and did unit test with SELINUX disabled, AUDITSYSCALL disabled, and with both enabled. Thanks, applied to git://git.infradead.org/~jmorris/selinux-net-2.6.20#for-akpm might be worth having it in -mm for a bit. -- James Morris [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/3] NetLabel: add the ranged tag to the CIPSOv4 protocol
On Wed, 29 Nov 2006, [EMAIL PROTECTED] wrote:
+{
+ /* The constant '16' is not random, it is the maximum number of
+ * high/low category range pairs as permitted by the CIPSO draft based
+ * on a maximum IPv4 header length of 60 bytes - the BUG_ON() assertion
+ * does a sanity check to make sure we don't overflow the array. */
+ int iter = -1;
+ u16 array[16];
Perhaps in a future update, make this a value a macro definition and
document it in the header.
--
James Morris
[EMAIL PROTECTED]
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/3] NetLabel: add the remaining CIPSO tag types from the IETF draft
All applied to: git://git.infradead.org/~jmorris/selinux-net-2.6.20 Thanks, - James -- James Morris [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/3] NetLabel: add the remaining CIPSO tag types from the IETF draft
On Wed, 29 Nov 2006, Paul Moore wrote: James Morris wrote: All applied to: git://git.infradead.org/~jmorris/selinux-net-2.6.20 Thanks. Did you mean your kernel.org git tree? There's a copy at infradead (which may have still been cloning if you checked it immediately). -- James Morris [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/1] additional ipsec audit patch
On Wed, 29 Nov 2006, Joy Latten wrote: This patch disables auditing in ipsec when CONFIG_AUDITSYSCALL is disabled in the kernel. This patch also includes a bug fix for xfrm_state.c as a result of original ipsec audit patch. Let me know if it looks ok. Also, the last patch contains no Signed-off-by: line, please resend. -- James Morris [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/1] additional ipsec audit patch
On Wed, 29 Nov 2006, James Morris wrote: On Wed, 29 Nov 2006, Joy Latten wrote: This patch disables auditing in ipsec when CONFIG_AUDITSYSCALL is disabled in the kernel. This patch also includes a bug fix for xfrm_state.c as a result of original ipsec audit patch. Let me know if it looks ok. Also, the last patch contains no Signed-off-by: line, please resend. And, what is the testing status of these patches? -- James Morris [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/1] add auditing to ipsec
On Mon, 27 Nov 2006, Joy Latten wrote: This patch adds auditing to ipsec in support of labeled ipsec. An audit message occurs when an ipsec SA or ipsec policy is created/deleted. Patch was built against linux kernel 2.6.19-rc6. Please let me know if this is acceptable. Looks ok to me. Acked-by: James Morris [EMAIL PROTECTED] -- James Morris [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/13] NetLabel cleanups for 2.6.20 [GIT]
On Sat, 18 Nov 2006, Paul Moore wrote: There was one minor compilation issue caused by including linux/skbuff.h in an SELinux header, which I fixed (see below). scratching head Huh, sorry about that ... thanks for accepting the patches and making the fix. /scratching head Here's the error: security/selinux/ss/policydb.c:472: error: conflicting types for â'class_destroy' include/linux/device.h:295: error: previous declaration of â'class_destroy' was here -- James Morris [EMAIL PROTECTED]
Re: [PATCH 00/13] NetLabel cleanups for 2.6.20 [GIT]
On Fri, 17 Nov 2006, [EMAIL PROTECTED] wrote: This patchset consists of a lot of small-ish cleanups for NetLabel and in some cases labeled networking in general. I've tested these patches for the past few days and I haven't seen any regressions so please consider them for the net-2.6.20 git tree. Thanks, excellent! There was one minor compilation issue caused by including linux/skbuff.h in an SELinux header, which I fixed (see below). Applied to git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/selinux-net-2.6.20 --- diff --git a/security/selinux/include/security.h b/security/selinux/include/security.h index 015f697..210eec7 100644 --- a/security/selinux/include/security.h +++ b/security/selinux/include/security.h @@ -8,7 +8,6 @@ #ifndef _SELINUX_SECURITY_H_ #define _SELINUX_SECURITY_H_ -#include linux/skbuff.h #include flask.h #define SECSID_NULL0x /* unspecified SID */ @@ -35,6 +34,8 @@ #else #define POLICYDB_VERSION_MAX POLICYDB_VERSION_RANGETRANS #endif +struct sk_buff; + extern int selinux_enabled; extern int selinux_mls_enabled; - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Network virtualization/isolation
On Tue, 14 Nov 2006, Daniel Lezcano wrote: the attached document describes the network isolation at the layer 2 and at the layer 3, it presents the pros and cons of the different approaches, their common points and the impacted network code. I hope it will be helpful :) What about other network subsystems: xfrm, netfilter, iptables, netlink, etc. ? - James -- James Morris [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
