Re: 2.6.24-rc6-mm1 - oddness with IPv4/v6 mapped sockets hanging...

[Paul Moore]

On Monday 14 January 2008 11:15:38 am [EMAIL PROTECTED] wrote:
 On Sun, 13 Jan 2008 02:35:33 EST, [EMAIL PROTECTED] said:
  I'm seeing problems with Sendmail on 24-rc6-mm1, where the main Sendmail
  is listening on ::1/25, and Fetchmail connects to 127.0.0.1:25 to inject
  mail it has just fetched from an outside server via IMAP - it will often
  just hang and not make any further progress. Looking at netstat shows
  something interesting:
 
  % netstat -n -a -A inet | grep 25
  tcp0   5108 127.0.0.1:59355 127.0.0.1:25 
ESTABLISHED

 The IPv6 is apparently a red herring - this morning I'm seeing the same
 problem with another totally separate pair of programs that are IPv4-only,
 hanging on loopback.

Are you still only seeing these problems on loopback?  I can't help but wonder 
if this is the skb_clone() problem where it wasn't copying skb-iif causing 
SELinux to silently drop the packets.  Then again, I'm not sure if there is a 
clone operation in the code path are going down.  From what I can remember I 
only saw clones on some of the multicast stuff but I'm still learning some of 
the darker corners of the stack.

If you've got some spare cycles, the kernel below should both have the 
clone/iif fix (it's in Linus' tree now) as well as some printks when errors 
occur so packet's are no longer silently dropped by SELinux.

 * git://git.infradead.org/users/pcmoore/lblnet-2.6_testing

-- 
paul moore
linux security @ hp
--
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/

Re: 2.6.24-rc6-mm1 - oddness with IPv4/v6 mapped sockets hanging...

[Paul Moore]

On Monday 14 January 2008 1:50:39 pm [EMAIL PROTECTED] wrote:
 On Mon, 14 Jan 2008 13:22:10 EST, [EMAIL PROTECTED] said:
  Apparently the only new commit in there since the tree that was in
  24-rc6-mm1 is 5d95575903fd3865b884952bd93c339d48725c33 adding some
  warning printk's.  Would it be more productive to test against the full
  tree, or leaving out the one commit I already reverted?

 voice=Emily Litella Nevermind... /voice :)

 The new commit won't apply with the other one reverted - it patches
 security/selinux/netnode.c which was created by the problematic commit...

There have been quite a few changes in lblnet-2.6_testing since 2.6.24-rc6-mm1 
so I would recommend taking the whole tree.  I'm also not quite sure if 
simply reverting the Convert the netif code to use ifindex values patch 
would solve the problem as there are other patches in the rc6-mm1 tree that 
rely on skb-iif being valid (new code, not converted code).  If you want to 
stick with a _relatively_ vanilla rc6-mm1 tree I would leave everything in 
and simply apply the following patch which solved the skb_clone()/iif 
problem:

http://git.infradead.org/?p=users/pcmoore/lblnet-2.6_testing;a=commitdiff;h=02f1c89d6e36507476f78108a3dcc78538be460b

-- 
paul moore
linux security @ hp
--
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/

Re: 2.6.24-rc6-mm1 - oddness with IPv4/v6 mapped sockets hanging...

[Paul Moore]

On Monday 14 January 2008 6:04:28 pm [EMAIL PROTECTED] wrote:
 On Mon, 14 Jan 2008 14:07:46 EST, Paul Moore said:
  http://git.infradead.org/?p=users/pcmoore/lblnet-2.6_testing;a=commitdiff
 ;h=02f1c89d6e36507476f78108a3dcc78538be460b

 Initial testing indicates that 2.6.24-rc6-mm1 plus this one commit is
 behaving itself correctly - my Tcl test case that reliably demonstrated
 wedges during SYN handling is definitively fixed, and the current issue
 with hangs with data pending seems to be gone as well (after admittedly
 light testing).

 Thanks for finding the commit that fixed it...

No problem, glad to hear that fixed the problem.  It's already in Linus' tree 
so any future -mm kernels as well as 2.6.24 should be problem-free, at least 
with respect to this ;)

-- 
paul moore
linux security @ hp
--
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/

Re: [TOMOYO #5 18/18] LSM expansion for TOMOYO Linux.

[Paul Moore]

On Friday 16 November 2007 12:34:57 pm [EMAIL PROTECTED] 
wrote:
 LSM hooks for network accept and recv:
* socket_post_accept is modified to return int.
* post_recv_datagram is added in skb_recv_datagram.

 You can try TOMOYO Linux without this patch, but in that case, you
 can't use access control functionality for restricting signal
 transmission and incoming network data.

As discussed a few times before, I'm still not really excited about adding a 
new LSM hook in skb_recv_datagram() when we already have hooks to control 
locally consumed network traffic.  However, I will admit that these existing 
hooks do not allow the LSM to block and query userspace for an access 
decision like you are trying to do with TOMOYO.  I would prefer not to see 
this new LSM hook added but I do not have an alternative solution to your 
problem so I can't in good conscience completely object to this patch.

Regardless, I have a few comments which are included below ...

 --- linux-2.6-mm.orig/net/core/datagram.c 2007-10-10 05:31:38.0
 +0900 +++ linux-2.6-mm/net/core/datagram.c2007-11-14 15:15:44.0
 +0900 @@ -55,6 +55,7 @@
  #include net/checksum.h
  #include net/sock.h
  #include net/tcp_states.h
 +#include linux/security.h

  /*
   *   Is a socket 'connection oriented' ?
 @@ -178,6 +179,27 @@ struct sk_buff *skb_recv_datagram(struct
   } else
   skb = skb_dequeue(sk-sk_receive_queue);

 + error = security_post_recv_datagram(sk, skb, flags);
 + if (error) {
 + unsigned long cpu_flags;

With this patch the 'cpu_flags' variable will be used in two different 
if-blocks in this function and declared locally within each block.  Please 
move the 'cpu_flags' declaration to the top of the function so it only needs 
to be declared once.

 +
 + if (!(flags  MSG_PEEK))
 + goto no_peek;
 +
 + spin_lock_irqsave(sk-sk_receive_queue.lock,
 +   cpu_flags);
 + if (skb == skb_peek(sk-sk_receive_queue)) {

I might be missing something here, but why do you need to do a skb_peek() 
again?  You already have the skb and the sock, just do the unlink.

 + __skb_unlink(skb,
 +  sk-sk_receive_queue);
 + atomic_dec(skb-users);
 + }
 + spin_unlock_irqrestore(sk-sk_receive_queue.lock,
 +cpu_flags);
 +no_peek:
 + skb_free_datagram(sk, skb);
 + goto no_packet;

Two things.  First you can probably just call kfree_skb() instead of 
skb_free_datagram().  Second, why not move the 'no_peek' code to just 
before 'no_packet'?

-- 
paul moore
linux security @ hp
-
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/

Re: [TOMOYO #5 18/18] LSM expansion for TOMOYO Linux.

[Paul Moore]

On Friday 16 November 2007 10:45:32 pm Tetsuo Handa wrote:
 Paul Moore wrote:
  I might be missing something here, but why do you need to do a skb_peek()
  again?  You already have the skb and the sock, just do the unlink.

 The skb might be already dequeued by other thread while I slept inside
 security_post_recv_datagram().

Okay, well if that is the case I think you are going to have another problem 
in that you could end up throwing away skbs that haven't been through your 
security_post_recv_datagram() hook because you _always_ throw away the result 
of the second skb_peek().  Once again, if I'm wrong please correct me.

  Second, why not move the 'no_peek' code to just before 'no_packet'?

 Oh, I didn't notice I can insert here. Now I can also move the rest code
 like

 | error = security_post_recv_datagram(sk, skb, flags);
 | if (error)
 |   goto force_dequeue;
 |
 | } while (!wait_for_packet(sk, err, timeo));

Where did the 'if (skb) return skb;' code go?  Don't you need to do you LSM 
call before you return the skb?

-- 
paul moore
linux security @ hp
-
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/

Re: [TOMOYO #5 18/18] LSM expansion for TOMOYO Linux.

[Paul Moore]

On Saturday 17 November 2007 11:00:20 pm Tetsuo Handa wrote:
 Hello.

Hello.

 Paul Moore wrote:
  Okay, well if that is the case I think you are going to have another
  problem in that you could end up throwing away skbs that haven't been
  through your security_post_recv_datagram() hook because you _always_
  throw away the result of the second skb_peek().  Once again, if I'm wrong
  please correct me.

 I didn't understand what's wrong with throwing away the result of
 the second skb_peek().

My concern is that you stated earlier that you needed to do the second 
skb_peek() because the first skb may have been removed from the socket queue 
while your LSM was making an access decision in 
security_post_recv_datagram().  If that is the case then the second call to 
skb_peek() will return a different skb then the one you passed to 
security_post_recv_datagram().  This is significant because you always throw 
away this second skb without first consulting the LSM via 
security_post_recv_datagram().

-- 
paul moore
linux security @ hp
-
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/

Re: [TOMOYO #5 18/18] LSM expansion for TOMOYO Linux.

[Paul Moore]

On Monday 19 November 2007 9:29:52 am Tetsuo Handa wrote:
 Paul Moore wrote:
  If that is the case then the second call to
  skb_peek() will return a different skb then the one you passed to
  security_post_recv_datagram().

 Yes. The second call to skb_peek() might return a different skb than the
 one I passed to security_post_recv_datagram().

My apologies, I mistakenly read the following if statement in your patch:

 +   if (skb == skb_peek(sk-sk_receive_queue)) {
 +   __skb_unlink(skb, sk-sk_receive_queue);
 +   atomic_dec(skb-users);
 +   }

I read the conditional as the following:

 +   if (skb = skb_peek(sk-sk_receive_queue)) {

... which would have caused the problems I was describing.  I'm sorry for all 
of the confusion/frustration, you patient explanations are correct; I was 
wrong in this particular case.

-- 
paul moore
linux security @ hp
-
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/

Re: [PATCH] net/netlabel/: Spelling fixes

[Paul Moore]

On Monday 17 December 2007 2:40:35 pm Joe Perches wrote:
 Signed-off-by: Joe Perches [EMAIL PROTECTED]

Thanks Joe.

Acked-by: Paul Moore [EMAIL PROTECTED]

 ---
  net/netlabel/netlabel_mgmt.c |2 +-
  1 files changed, 1 insertions(+), 1 deletions(-)

 diff --git a/net/netlabel/netlabel_mgmt.c b/net/netlabel/netlabel_mgmt.c
 index 5648337..9c41464 100644
 --- a/net/netlabel/netlabel_mgmt.c
 +++ b/net/netlabel/netlabel_mgmt.c
 @@ -71,7 +71,7 @@ static const struct nla_policy
 netlbl_mgmt_genl_policy[NLBL_MGMT_A_MAX + 1] = { };

  /*
 - * NetLabel Misc Managment Functions
 + * NetLabel Misc Management Functions
   */

  /**



-- 
paul moore
linux security @ hp
--
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/

Re: mm snapshot broken-out-2007-11-20-01-45.tar.gz uploaded

[Paul Moore]

On Tuesday 20 November 2007 3:34:24 pm Kamalesh Babulal wrote:
 Hi Andrew,

 The kernel build fails, in selinux with following error

   CHK include/linux/compile.h
   UPD include/linux/compile.h
   CC  init/version.o
   LD  init/built-in.o
   LD  .tmp_vmlinux1
 security/built-in.o(.toc1+0x928): undefined reference to
 `selinux_xfrm_refcount' make: *** [.tmp_vmlinux1] Error 1
 11/20/2007-14:42:08 Build the kernel. Failed rc = 2
 11/20/2007-14:42:08 build: Building kernel... Failed rc = 1

 The patch causing this error is git-lblnet.patch, where in the
 selinux_xfrm_enabled() is called from security/selinux/hooks.c, depends on
 the extern atomic_tselinux_xfrm_refcount.

The problem appears to be that the selinux_xfrm_refcount functionality is not 
properly protected by CONFIG_SECURITY_NETWORK_XFRM.  I'm fixing that now.

-- 
paul moore
linux security @ hp
-
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/

Re: mm snapshot broken-out-2007-11-20-01-45.tar.gz uploaded

[Paul Moore]

On Tuesday 20 November 2007 3:48:44 pm Paul Moore wrote:
 On Tuesday 20 November 2007 3:34:24 pm Kamalesh Babulal wrote:
  Hi Andrew,
 
  The kernel build fails, in selinux with following error
 
CHK include/linux/compile.h
UPD include/linux/compile.h
CC  init/version.o
LD  init/built-in.o
LD  .tmp_vmlinux1
  security/built-in.o(.toc1+0x928): undefined reference to
  `selinux_xfrm_refcount' make: *** [.tmp_vmlinux1] Error 1
  11/20/2007-14:42:08 Build the kernel. Failed rc = 2
  11/20/2007-14:42:08 build: Building kernel... Failed rc = 1
 
  The patch causing this error is git-lblnet.patch, where in the
  selinux_xfrm_enabled() is called from security/selinux/hooks.c, depends
  on the extern atomic_tselinux_xfrm_refcount.

 The problem appears to be that the selinux_xfrm_refcount functionality is
 not properly protected by CONFIG_SECURITY_NETWORK_XFRM.  I'm fixing that
 now.

I've fixed the problem in the git tree below, meaning I just did a quick 
compile without defining CONFIG_SECURITY_NETWORK_XFRM and everything appeared 
to link correctly.  I haven't had a chance to try booting the fix yet because 
my test machine is a little slow compiling right now, but the fix was pretty 
trivial (simply move the extern and the inline function) so I don't expect 
any problems.

 * git://git.infradead.org/users/pcmoore/lblnet-2.6_testing

-- 
paul moore
linux security @ hp
-
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/

Re: 2.6.24-rc6-mm1 - git-lblnet.patch and networking horkage

[Paul Moore]

As James said I'm away right now and computer access is limited.  However, I'm 
stuck in the airport right now and spent some time looking at the code ... 
Based on what has been found so far I wonder if the problem isn't a race but a 
problem of skb-iif never being initialized correctly?  To my untrained eye it 
looks like __netdev_alloc_skb() should be setting skb-iif (like it does for 
skb-dev) but it currently doesn't.

Am I barking up the wrong tree here?

. paul moore
. linux security @ hp
-Original Message-
From: James Morris [EMAIL PROTECTED]
Date: Wednesday, Dec 26, 2007 7:16 am
Subject: Re: 2.6.24-rc6-mm1 - git-lblnet.patch and networking horkage
To: [EMAIL PROTECTED]
CC: Andrew Morton [EMAIL PROTECTED],  Paul Moore [EMAIL PROTECTED], 
linux-kernel@vger.kernel.org,   Stephen Smalley [EMAIL PROTECTED]

On Wed, 26 Dec 2007, James Morris wrote:

 What does the following say ?
 
 # sestatus   rpm -q selinux-policy

Don't worry about that -- I reproduced it with Paul Moore's git tree: 
git://git.infradead.org/users/pcmoore/lblnet-2.6_testing

(under current -mm, the e1000 driver doesn't find my ethernet card  the 
tcl tests won't run without an external interface).

The offending commit is when SELinux is converted to the new ifindex 
interface:

  9c6ad8f6895db7a517c04c2147cb5e7ffb83a315 is first bad commit
  commit 9c6ad8f6895db7a517c04c2147cb5e7ffb83a315
  Author: Paul Moore [EMAIL PROTECTED]
  Date:   Fri Dec 21 11:44:26 2007 -0500

  SELinux: Convert the netif code to use ifindex values

  [...]

In some case (not yet fully identified -- also happens when avahi starts 
up, although seemingly silently  without obvious issues), SELinux is 
passed an ifindex of 1515870810, which corresponds to 0x5a5a5a5a, the slab 
poison value, suggesting a race in the calling code where we're being 
asked to check an skb which has been freed.

The SELinux code is erroring out before performing an access check 
(perhaps there should be WARN_ON, at least), so this will affect both 
permissive and enforcing mode without generating any log messages.

Andrew: I suggest dropping the patchset from -mm until Paul gets back from 
vacation.


- James
-- 
James Morris
[EMAIL PROTECTED]


--
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/

Re: 2.6.24-rc6-mm1 - git-lblnet.patch and networking horkage

[Paul Moore]

On Wednesday 26 December 2007 4:52:03 pm James Morris wrote:
 On Thu, 26 Dec 2007, Paul Moore wrote:
  As James said I'm away right now and computer access is limited.
  However, I'm stuck in the airport right now and spent some time looking
  at the code ... Based on what has been found so far I wonder if the
  problem isn't a race but a problem of skb-iif never being initialized
  correctly?  To my untrained eye it looks like __netdev_alloc_skb()
  should be setting skb-iif (like it does for skb-dev) but it currently
  doesn't.

 -iif will be zeroed during skb allocation, then set during
 netif_receive_skb().

So it is ... I didn't look at __alloc_skb() close enough.  Thanks.

-- 
paul moore
linux security @ hp
--
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/

Re: 2.6.24-rc6-mm1 - git-lblnet.patch and networking horkage

[Paul Moore]

On Wednesday 26 December 2007 4:52:03 pm James Morris wrote:
 On Thu, 26 Dec 2007, Paul Moore wrote:
  As James said I'm away right now and computer access is limited.
  However, I'm stuck in the airport right now and spent some time looking
  at the code ... Based on what has been found so far I wonder if the
  problem isn't a race but a problem of skb-iif never being initialized
  correctly?  To my untrained eye it looks like __netdev_alloc_skb()
  should be setting skb-iif (like it does for skb-dev) but it currently
  doesn't.

 -iif will be zeroed during skb allocation, then set during
 netif_receive_skb().

I was able to reproduce this bug this morning by running avahi as James did 
and did a little more digging.  I don't have a fix yet, but thought I would 
pass along what I've found in case this triggers a moment of clarity to 
someone out there ...

The skb-iif value appears to be messed up as early as netif_receive_skb(), in 
my case it is set to 196611 (trust me, I don't have that many interfaces in 
my test machine) which causes the -iif initialization code in 
netif_receive_skb() to be skipped because -iif is greater than zero.  This 
particular packet is locally generated and locally consumed.

Hopefully I'll have a fix later this afternoon but if someone has a bright 
idea I'd love to hear it.  Backtrace is below:

WARNING: at security/selinux/hooks.c:3805 selinux_socket_sock_rcv_skb()
Pid: 1454, comm: avahi-daemon Not tainted 2.6.24-rc5 #4
 [c04aac4e] selinux_socket_sock_rcv_skb+0x96/0x3ac
 [c041bddf] printk+0x1b/0x1f
 [c04349c9] __print_symbol+0x21/0x2a
 [c04a5ae8] security_sock_rcv_skb+0xc/0xd
 [c05822c3] sock_queue_rcv_skb+0x29/0xce
 [d08f34e9] ipt_do_table+0x423/0x466 [ip_tables]
 [c05bf114] udp_queue_rcv_skb+0x199/0x201
 [c04caf24] vsnprintf+0x283/0x450
 [d08f93e8] nf_conntrack_in+0x307/0x3d7 [nf_conntrack]
 [c05bf56a] __udp4_lib_rcv+0x3ee/0x7a7
 [d08fc26f] nf_ct_deliver_cached_events+0x8/0x90 [nf_conntrack]
 [d0984158] ipv4_confirm+0x34/0x39 [nf_conntrack_ipv4]
 [c059e99a] nf_iterate+0x3a/0x6e
 [c05a38d3] ip_local_deliver_finish+0x0/0x191
 [c05a38d3] ip_local_deliver_finish+0x0/0x191
 [c05a39e5] ip_local_deliver_finish+0x112/0x191
 [c05a38b4] ip_rcv_finish+0x254/0x273
 [c05a3660] ip_rcv_finish+0x0/0x273
 [c05a3cd3] ip_rcv+0x1cc/0x1fb
 [c05a3660] ip_rcv_finish+0x0/0x273
 [c05a3b07] ip_rcv+0x0/0x1fb
 [c0587fd7] netif_receive_skb+0x37d/0x397
 [c058a111] process_backlog+0x60/0x92
 [c0589e16] net_rx_action+0x67/0x118
 [c041f164] __do_softirq+0x35/0x75
 [c0404f02] do_softirq+0x3e/0x8d
 [c041f06e] local_bh_enable+0x6b/0x79
 [d08fc26f] nf_ct_deliver_cached_events+0x8/0x90 [nf_conntrack]
 [d0984158] ipv4_confirm+0x34/0x39 [nf_conntrack_ipv4]
 [d0984124] ipv4_confirm+0x0/0x39 [nf_conntrack_ipv4]
 [c059e99a] nf_iterate+0x3a/0x6e
 [c05a6ca9] ip_finish_output+0x0/0x208
 [c059ea3f] nf_hook_slow+0x4d/0xb5
 [c05a6ca9] ip_finish_output+0x0/0x208
 [c05a7cb5] ip_mc_output+0x172/0x18b
 [c05a6ca9] ip_finish_output+0x0/0x208
 [c05a5b79] ip_push_pending_frames+0x2be/0x311
 [c05a5790] dst_output+0x0/0x7
 [c05bedb6] udp_push_pending_frames+0x298/0x2d7
 [c05bfd8b] udp_sendmsg+0x459/0x55c
 [c05c4bf9] inet_sendmsg+0x3b/0x45
 [c057eead] sock_sendmsg+0xc8/0xe3
 [c0429863] autoremove_wake_function+0x0/0x33
 [c057eead] sock_sendmsg+0xc8/0xe3
 [c0429863] autoremove_wake_function+0x0/0x33
 [c04cbb78] copy_from_user+0x32/0x5e
 [c04cbb78] copy_from_user+0x32/0x5e
 [c057f05a] sys_sendmsg+0x192/0x1f7
 [c041eb1b] current_fs_time+0x13/0x15
 [c0470b14] file_update_time+0x21/0x61
 [c04663f2] pipe_write+0x3cc/0x3d8
 [c0460e91] do_sync_write+0x0/0x109
 [c0460f57] do_sync_write+0xc6/0x109
 [c0429863] autoremove_wake_function+0x0/0x33
 [c058029c] sys_socketcall+0x240/0x261
 [c0403c72] syscall_call+0x7/0xb
 ===

-- 
paul moore
linux security @ hp
--
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/

Re: 2.6.24-rc6-mm1 - git-lblnet.patch and networking horkage

[Paul Moore]

On Monday 31 December 2007 12:13:32 pm Paul Moore wrote:
 On Wednesday 26 December 2007 4:52:03 pm James Morris wrote:
  On Thu, 26 Dec 2007, Paul Moore wrote:
   As James said I'm away right now and computer access is limited.
   However, I'm stuck in the airport right now and spent some time looking
   at the code ... Based on what has been found so far I wonder if the
   problem isn't a race but a problem of skb-iif never being initialized
   correctly?  To my untrained eye it looks like __netdev_alloc_skb()
   should be setting skb-iif (like it does for skb-dev) but it currently
   doesn't.
 
  -iif will be zeroed during skb allocation, then set during
  netif_receive_skb().

 I was able to reproduce this bug this morning by running avahi as James did
 and did a little more digging.  I don't have a fix yet, but thought I would
 pass along what I've found in case this triggers a moment of clarity to
 someone out there ...

 The skb-iif value appears to be messed up as early as netif_receive_skb(),
 in my case it is set to 196611 (trust me, I don't have that many interfaces
 in my test machine) which causes the -iif initialization code in
 netif_receive_skb() to be skipped because -iif is greater than zero.  This
 particular packet is locally generated and locally consumed.

 Hopefully I'll have a fix later this afternoon but if someone has a bright
 idea I'd love to hear it ...

[NOTE: I added netdev to this thread to gather some input.  @netdev folks, the 
problem is that the skb-iif field contains garbage in some cases which is 
causing problems for some new SELinux network code.  The exact problem 
probably isn't too important for this discussion, what is important is that 
the skb-iif field contains a non-zero garbage value some of the time on 
incoming packets.]

I'm pretty certain this is an uninitialized value problem now and not a 
use-after-free issue.  The invalid/garbage -iif value seems to only happen 
on packets that are generated locally and sent back into the stack for local 
consumption, e.g. loopback.  These local packets also need to have been 
cloned at some point, either on the output or input path.

The problem appears to be a skb_clone() function which does not clear the skb 
structure properly and fails to copy the -iif value from the original skb to 
the cloned skb.  From what I can tell, there are two possible solutions to 
this problem:

 1. Clear all of the cloned skb fields in skb_clone() via memset()
 2. Copy the -iif field in __copy_skb_header()

I don't have a good enough understanding of all the details involving skb 
memory management to know if option #1 is a Good Idea or not, but option #2 
seems much simpler and solves the problem of garbage in the -iif field.  My 
preference is to go with option #2 but before I submit a patch does anyone 
think this is the wrong solution?

-- 
paul moore
linux security @ hp
--
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/

Re: 2.6.24-rc6-mm1 - git-lblnet.patch and networking horkage

[Paul Moore]

On Monday 31 December 2007 4:46:09 pm James Morris wrote:
 On Mon, 31 Dec 2007, Paul Moore wrote:
  I'm pretty certain this is an uninitialized value problem now and not a
  use-after-free issue.  The invalid/garbage -iif value seems to only
  happen on packets that are generated locally and sent back into the stack
  for local consumption, e.g. loopback.  These local packets also need to
  have been cloned at some point, either on the output or input path.

 I think we need to find out exactly what's happening, first.

The more I've looked at the code this afternoon, I'm certain this is the case.  
I've also been running a patched kernel (using option #2 from below) and all 
of the skbs coming up the stack have valid -iif values.  Granted, I haven't 
examined the code from the avahi daemon or the tcl test cases and traced the 
entire code path through the kernel but I _am_ certain that at some point in 
that code path the packet is cloned and due to a problem in skb_clone() 
the -iif field is not copied correctly causing the problems we have all 
seen.

How much smoke needs to be coming from the gun? :)

  The problem appears to be a skb_clone() function which does not clear the
  skb structure properly and fails to copy the -iif value from the
  original skb to the cloned skb.  From what I can tell, there are two
  possible solutions to this problem:
 
   1. Clear all of the cloned skb fields in skb_clone() via memset()

 Sounds like it's not going to fly for performance reasons in any case.

That was my gut feeling.  I was also a little unsure where exactly the correct 
placement should be for the memset() call.

   2. Copy the -iif field in __copy_skb_header()

 Seems valid.

Okay, I'll stick with this approach.  I'll post a patch backed against 
net-2.6.25 tomorrow as an RFC to see if anyone on netdev has any strong 
feelings.  If no one complains, I'll add it to the lblnet git tree.

-- 
paul moore
linux security @ hp
--
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/

Re: [PATCH] [RFC] Smack: unlabeled outgoing ambient packets - v2

[Paul Moore]

;
 - int rc;

   if (sk == NULL)
   return;
 @@ -2212,7 +2212,7 @@ static void smack_sock_graft(struct sock
   ssp-smk_out = current-security;
   ssp-smk_packet[0] = '\0';

 - rc = smack_netlabel(sk);
 + smack_netlabel(sk);

Once more, but with feeling.

  }

  /**

-- 
paul moore
linux security @ hp
--
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/

Re: [2.6 patch] make secmark_tg_destroy() static

[Paul Moore]

On Wednesday 13 February 2008 4:29:40 pm Adrian Bunk wrote:
 This patch makes the needlessly global secmark_tg_destroy() static.

 Signed-off-by: Adrian Bunk [EMAIL PROTECTED]

Thanks for catching this.

Acked-by: Paul Moore [EMAIL PROTECTED]

 ---
 df66d8d74309b41298ae011532fd284aad3ed2ba
 diff --git a/net/netfilter/xt_SECMARK.c b/net/netfilter/xt_SECMARK.c
 index 7708e20..c028485 100644
 --- a/net/netfilter/xt_SECMARK.c
 +++ b/net/netfilter/xt_SECMARK.c
 @@ -111,7 +111,7 @@ secmark_tg_check(const char *tablename, const
 void *entry, return true;
  }

 -void secmark_tg_destroy(const struct xt_target *target, void
 *targinfo) +static void secmark_tg_destroy(const struct xt_target
 *target, void *targinfo) {
   switch (mode) {
   case SECMARK_MODE_SEL:

-- 
paul moore
linux security @ hp
--
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/

ANN: libseccomp 1.0.1 released

[Paul Moore]

I would like to announce a maintenance release for the libseccomp library, 
libseccomp version 1.0.1.  The libseccomp library provides an easy to use, 
platform independent, interface to Linux's enhanced syscall filtering 
mechanism.

 * http://sourceforge.net/projects/libseccomp
 * http://sf.net/projects/libseccomp/files/libseccomp-1.0.1.tar.gz/download

All users of libseccomp are strongly encourage to update to this latest 
release.  Changes in the 1.0.1 release include:

 * Fixes for the following:
 ** memory leaks
 ** small filters, e.g. filtering only a single syscall
 ** filters with syscall arguments
 * Documentation corrections
 * Support for C++ in the header file

Finally, thank you to everyone who has submitted suggestions, provided testing 
help, and contributed patches to the project.

-- 
paul moore
security and virtualization @ redhat

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] Version 3 (2.6.23-rc8) Smack: Simplified Mandatory Access Control Kernel

[Paul Moore]

On Sunday 30 September 2007 3:07:42 pm Theodore Tso wrote:
 There are different kinds of security.  Not all of them involve
 cryptography and IPSEC.  Some of them involve armed soldiers and air
 gap firewalls.  :-)

 Yes, normally the network is outside the Trusted Computing Base (TCB),
 but a cluster of Linux machines in a rack is roughly the same size of
 a huge Unix server tens year ago --- and it's not like Ethernet is any
 more secure than the PCI bus.  So why do we consider communications
 across a PCI bus secure even though they aren't encrypted?  Why,
 because normally we assume the PCI bus is inside the trust boundary,
 and so we don't worry about bad guys tapping communications between
 the CPU and the hard drive on the PCI bus.

 But these days, it is obviously possible to create clusters where
 certain network interfaces are only connected to machines contained
 completely inside the trust boundary, just like a PCI bus in a
 traditional server.  So don't be so quick to dismiss something like
 CIPSO out of hand, just because it doesn't use IPSEC.

Sorry I'm a bit late to the discussion (been busy doing weekend things), but 
I see that Casey, Josh, and Ted have already given a pretty good explanation 
of why CIPSO is not as evil as it appears at first glance.  I won't restate 
the points they have already made, but I think there are two other points 
worth mentioning:

The first is that CIPSO options are immutable, which means they work 
wonderfully with IPsec.  Label integrity can be provided through the use of 
AH and/or tunneled ESP, label confidentiality can be provided through 
tunneled ESP.  While the SELinux specific labeled IPsec implementation we 
currently have in the kernel is nice if you are talking to other SELinux 
machines, it has a very real handicap in that you can't use it to talk 
anything else.  CIPSO, or CIPSO in combination with standard, non-labeled 
IPsec, can be used to talk to pretty much any trusted OSs out there.  
Adherence to standards and interoperability with other OSs have always been a 
key factor of Linux's acceptance into new areas; support for CIPSO is just 
another part of this drive for greater interoperability.

The second point I wanted to make is that in the course of putting together 
the CIPSO implementation in the kernel I ended up talking with a few people 
who were involved in the original TSIG effort and the mess with the IETF.  
From what I could gather, the main technical complaint (other than a variety 
of political complaints which aren't relevant to our discussion here) was 
that CIPSO options are difficult to parse (they are, look at the format - 
it's an option within an option format - yuck) and the intermediate node 
vendors did not like it all (too much work to do in a fastpath ASIC).  After 
all, look at the [R]IPSO RFC, dated only eight months earlier, and there is 
no cryptographic special sauce in that protocol.

CIPSO isn't for everyone, I'll be the first to admit that.  However, if you 
look at the mailing list archive for the Linux LSPP effort, the SELinux list, 
and to a lesser extent the netdev and LSM lists you will see that there are a 
set of users who care very much about this functionality.  Our support of 
CIPSO is helping Linux operate in areas it wouldn't be able to elsewhere and 
I consider that a win.

-- 
paul moore
linux security @ hp
-
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/

Re: [PATCH] Version 3 (2.6.23-rc8) Smack: Simplified Mandatory Access Control Kernel

[Paul Moore]

On Sunday 30 September 2007 4:16:18 am Andrew Morton wrote:
 - hm, netlabels.  Who might be a suitable person to review that code?
   Seems that Paul Moore is the man.  Maybe he'd be interested in taking a
   look over it (please?)

Yep, I've been tracking Casey's work on this since the first patch and sending 
comments when appropriate.  I'm going to take a look at the latest rev of the 
patch and if anything looks awry I'll be sure to let Casey know.

The only real wart that still remains from the original patch is the code in 
smk_cipso_doi() which has a nice comment at the top saying that Paul and 
Casey need to work out an appropriate interface between NetLabel and SMACK.  
We punted on it before because SMACK's future was still a bit uncertain and 
SELinux has no need for an interface like this at present.  Now that SMACK 
looks to be queued up for 2.6.24 it's time to revisit this discussion.

-- 
paul moore
linux security @ hp
-
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/

Re: [PATCH] Version 4 (2.6.23-rc8-mm2) Smack: Simplified Mandatory Access Control Kernel

[Paul Moore]

On Wednesday 03 October 2007 12:45:42 am Casey Schaufler wrote:
 From: Casey Schaufler [EMAIL PROTECTED]

 Smack is the Simplified Mandatory Access Control Kernel.

 Smack implements mandatory access control (MAC) using labels
 attached to tasks and data containers, including files, SVIPC,
 and other tasks. Smack is a kernel based scheme that requires
 an absolute minimum of application support and a very small
 amount of configuration data.

 {snip}

 This patch includes changes made by Paul Moore [EMAIL PROTECTED]
 in support of a more comfortable interface to initialize the
 CIPSO code from within the kernel. The changes in the net directory
 are Pauls, as is the update to netlabel.h

My sign-off got lost when Casey smooshed the patch I sent him into the SMACK 
mega-patch so I'll throw it back in the thread for accounting purposes.

Signed-off-by: Paul Moore [EMAIL PROTECTED]

As for SMACK's use of NetLabel - it looks fine to me, especially now that 
there is better preservation of the NetLabel/LSM boundary.  As has been 
discussed on the various lists during earlier revisions of the patch I 
believe there are still some optimizations that can be made regarding how 
SMACK uses NetLabel but that is something we can always work on at a later 
date.

Acked-by: Paul Moore [EMAIL PROTECTED]

-- 
paul moore
linux security @ hp
-
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/

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

[Paul Moore]

On Monday 03 September 2007 9:15:27 am Tetsuo Handa wrote:
 Hello.

Hi.

 Paul Moore wrote:
  I apologize for not recognizing your approach from our earlier discussion
  on the LSM mailing list in July.  Unfortunately, I have the same
  objections to these changes that I did back then and from what I can
  recall of the discussion the rest of the kernel networking community
  agreed that these changes are not the preferred way of solving this
  problem.  We offered suggestions on how to accomplish your goals in a way
  that would be acceptable upstream and I would encourage you to
  investigate those options further.

 When I proposed a patch in July, I was patching at post-copy_to_user() step
 (i.e. after sock_recvmsg()).
 This approach messed up user-supplied buffer.

 This time, I'm patching at pre-copy_to_user() step
 (i.e. at skb_recv_datagram()).
 This approach doesn't mess up user-supplied buffer.
 I think this is a cleaner way than the previous patch.

It might be cleaner than your previous patch but it ignores some of the more 
important points that were brought up by the community in previous 
discussions.

 Although read() gets an error when select() said read ready,
 I can't find other place to use for accomplishing my goals.

 By the way, similar thing can happen when select() against
 a file descriptor said read ready but read() gets an error
 if security policy or security-id of the file has changed
 between select() and read(), isn't it?
 And such behavior is acceptable, isn't it?
 If such behavior can happen and is acceptable and *preferable*,
 I think checking permission at dequeue time (i.e. skb_recv_datagram())
 is *preferable* way than checking permission at enqueue time
 (i.e. socket_sock_rcv_skb()).

As mentioned before that problem with enforcing access control at dequeue 
time is that the system has already accepted the packet from the remote 
host - how do you plan to deal with these unacceptable/bad packets sitting on 
a socket, waiting to be read by a process which does not have access to them?  
What about connection oriented sockets where the remote host will assume 
everything is okay and continue blasting the machine with more, illegal 
packets?  If you aren't going to allow the socket/application to read the 
packet, never allow the system to accept it in the first place.

The *preferable* solution, as previously stated before by several people, is 
to investigate other access control methods like the netfilter userspace 
queue mechanism.  At the very least, please explain how the approaches we 
proposed will not accomplish what you require.

-- 
paul moore
linux security @ hp
-
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/

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

[Paul Moore]

On Tuesday 04 September 2007 10:02:46 am Tetsuo Handa wrote:
 According to Patrick McHardy's posting at
 http://www.mail-archive.com/[EMAIL PROTECTED]/msg00999.
html netfilter *socket filters* cannot know final recipient process.
 Can netfilter *userspace queue mechanism* know final recipient process?

Okay, I just went back and re-read the conversation from July as well as the 
description of your current patches and I think what is basically comes down 
to is that your design makes use of userspace intervention to allow/reject 
connections and/or packets based on the application's domain.  Unfortunately 
for TOMOYO, the current LSM network hooks are placed in such a way that you 
can not block and query a userspace agent for an access control decision.

Myself and some others have suggested using the netfilter userspace queue 
mechanism[1].  However, I understand this may cause you problems when you try 
to determine the incoming packet's destination/domain.  With these 
requirements I understand why you are pushing so hard to introduce these new 
LSM hooks, but for many reasons I would really prefer to try and find a way 
to utilize the existing hooks.  I've tried to think of a way to do this over 
the past day and have not been able to arrive at a clean solution.  
Personally, I still question the wisdom of receiving a packet/connection only 
to drop/reject it later when an application tries to read it but I might be 
the only one.

Based on some of the other discussion around this patch there appears to be 
other, larger issues which you still need to sort out (language parser in the 
kernel, /proc issues, etc.).  I would recommend addressing those concerns and 
including the netdev mailing list on your next patchset as they might have 
some thoughts on your network design.

[1]http://www.netfilter.org/projects/libnetfilter_queue/index.html

-- 
paul moore
linux security @ hp
-
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/

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

[Paul Moore]

On Thursday, September 6 2007 9:04:01 am Tetsuo Handa wrote:
 (1) It uses userspace intervention to allow/reject
 connections and/or packets based on the application's domain.
 Since existent hooks can't be used for this purpose,
 I inserted a new hook post_recv_datagram() at skb_recv_datagram()
 and I modified socket_post_accept() to return error so that
 I can drop/disconnect based on the application's domain.

 I think skb_recv_datagram() is the only place that can remove
 a message picked up with MSG_PEEK flags from the receive queue.
 To remove a message picked up with MSG_PEEK flags, I noticed that
 I have to do skb_kill_datagram()-like operation so that
 the head message that must not be delivered to the caller won't
 prevent picking up of the non-head message that should be delivered to the
 caller when the caller repeats only recv(MSG_PEEK) requests.
 Since skb_recv_datagram() can be called from interrupt context,
 I have to use spin_lock_irqsave() instead for spin_lock_bh(), am I
 right?

There are almost certainly better people to answer locking questions, but here 
is my take on it ... If you are accessing data both in a bottom half and 
elsewhere you need to make sure you disable bottom halfs from running before 
you access the data outside the bottom half (spin_lock_bh()).  If you are 
accessing data both in an interrupt handler and elsewhere you need to make 
sure you disable interrupts when accessing data outside the irq handler 
(spin_lock_irqsave()).

 By the way, why can't socket_post_accept() fail?
 Someone may wish to do memory allocation at socket_post_accept().
 socket_accept() is too early for memory allocation because
 there is no chance to free allocated memory
 when sock-ops-accept() failed.
 I think socket_post_accept() should be able to fail.

From my experience the community disapproves of approaches which go through 
the entire TCP handshake and then terminate the connection, which is what 
allowing security_socket_post_accept() to fail would do.

-- 
paul moore
linux security @ hp
-
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/

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

[Paul Moore]

On Friday, August 24 2007 8:58:28 am Kentaro Takeda wrote:
 LSM hooks for network accept and recv:
* socket_post_accept is modified to return int.

This has been discussed several times on various lists and is not considered 
an acceptable solution to blocking incoming stream connection attempts.  
Please take a look at the existing LSM stream connection request hooks as 
well as how SELinux makes use of them.

* post_recv_datagram is added in skb_recv_datagram.

Can you explain to me why this is not possible using the existing 
security_socket_sock_rcv_skb() LSM hook?

-- 
paul moore
linux security @ hp
-
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/

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

[Paul Moore]

On Tuesday, August 28 2007 6:39:13 am Tetsuo Handa wrote:
 Hello.

Hello.

 Paul Moore wrote:
  * post_recv_datagram is added in skb_recv_datagram.
 
  Can you explain to me why this is not possible using the existing
  security_socket_sock_rcv_skb() LSM hook?

 socket_sock_rcv_skb() is a hook for enqueue time.
 I want a hook for dequeue time, because what TOMOYO Linux is doing is
 not whether a socket created by foo is permitted to pick up
 an incoming packet from specific address/port
 but whether bar is permitted to pick up
 an incoming packet from specific address/port.
 At the time of enqueue, I can't know who will pick up that packet.

 Same reason for socket_post_accept(). What TOMOYO Linux is doing is
 not whether a socket created by foo is permitted to accept
 a connection request from specific address/port
 but whether bar is permitted to accept
 a connection request from specific address/port.
 At the time of enqueue, I can't know who will pick up that request.

I apologize for not recognizing your approach from our earlier discussion on 
the LSM mailing list in July.  Unfortunately, I have the same objections to 
these changes that I did back then and from what I can recall of the 
discussion the rest of the kernel networking community agreed that these 
changes are not the preferred way of solving this problem.  We offered 
suggestions on how to accomplish your goals in a way that would be acceptable 
upstream and I would encourage you to investigate those options further.

-- 
paul moore
linux security @ hp
-
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/

Re: [NET]: Mark Paul Moore as maintainer of labelled networking.

[Paul Moore]

On Tuesday, August 28 2007 2:46:19 am Joe Perches wrote:
 On Tue, 2007-08-28 at 00:01 +, Linux Kernel Mailing List wrote:
  +NETWORKING [LABELED] (NetLabel, CIPSO, Labeled IPsec, SECMARK)
  +P: Paul Moore
  +M: [EMAIL PROTECTED]
  +L: [EMAIL PROTECTED]
  +S: Maintained
  +

 Aren't there now 2 subsystems in MAINTAINERS for the same thing?

 NETLABEL
 P:Paul Moore
 M:[EMAIL PROTECTED]
 W:http://netlabel.sf.net
 L:[EMAIL PROTECTED]
 S:Supported

Yes and no.  Labeled networking consists of several different subsystems
because the term labeled networking can often mean several different
things.  I'll spare everyone the gory details, but if you are interested in
more information check out the SELinux mailing list archives from the past
month; there has been a lot of discussion about the different types of
labeled networking and the requirements/goals of each.

NetLabel is just one subsystem that provides labeled networking
functionality (CIPSO is provided through the NetLabel subsystem), Labeled
IPsec and SECMARK also provide labeled networking functionality.  Originally
I wrote/supported/maintained just NetLabel but over the past weekend James
Morris asked me to look after all of the different labeled networking
subsystems ... for better or worse I agreed :)

If having both a labeled networking and NetLabel maintainer entry is a
problem then how about the patch below?

Index: linux-2.6_maintainers/MAINTAINERS
===
--- linux-2.6_maintainers.orig/MAINTAINERS
+++ linux-2.6_maintainers/MAINTAINERS
@@ -2609,13 +2609,6 @@ W:   http://www.netfilter.org/
 W: http://www.iptables.org/
 S: Supported
 
-NETLABEL
-P: Paul Moore
-M: [EMAIL PROTECTED]
-W: http://netlabel.sf.net
-L: [EMAIL PROTECTED]
-S: Supported
-
 NETROM NETWORK LAYER
 P: Ralf Baechle
 M: [EMAIL PROTECTED]
@@ -2661,9 +2654,10 @@ L:   [EMAIL PROTECTED]
 T: git kernel.org:/pub/scm/linux/kernel/git/davem/net-2.6.git
 S: Maintained
 
-NETWORKING [LABELED] (NetLabel, CIPSO, Labeled IPsec, SECMARK)
+NETWORKING [LABELED] (NetLabel/CIPSO, Labeled IPsec, SECMARK)
 P: Paul Moore
 M: [EMAIL PROTECTED]
+W: http://netlabel.sf.net (NetLabel/CIPSO)
 L: [EMAIL PROTECTED]
 S: Maintained

-- 
paul moore
linux security @ hp

-
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/

Re: [NET]: Mark Paul Moore as maintainer of labelled networking.

[Paul Moore]

On Tuesday, August 28 2007 12:45:50 pm Joe Perches wrote:
 On Tue, 2007-08-28 at 08:46 -0400, Paul Moore wrote:
  If having both a labeled networking and NetLabel maintainer entry is a
  problem then how about the patch below?

 I don't think it is.

  -NETWORKING [LABELED] (NetLabel, CIPSO, Labeled IPsec, SECMARK)
  +NETWORKING [LABELED] (NetLabel/CIPSO, Labeled IPsec, SECMARK)
   P: Paul Moore
   M: [EMAIL PROTECTED]
  +W: http://netlabel.sf.net (NetLabel/CIPSO)
   L: [EMAIL PROTECTED]
   S: Maintained

 My preference would be for something like:

 NETLABEL and CIPSO
 P:Paul Moore
 M:[EMAIL PROTECTED]
 W:http://netlabel.sf.net
 L:[EMAIL PROTECTED]
 S:Maintained
 F:Documentation/netlabel/
 F:include/net/netlabel.h
 F:net/netlabel/

 Labeled IPsec and SECMARK
 P:Paul Moore
 M:[EMAIL PROTECTED]
 L:[EMAIL PROTECTED]
 S:Supported
 F:include/linux/netfilter/*SECMARK*
 F:net/netfilter/*SECMARK*

 I would like to add appropriate file patterns for each
 block.  Also, I'm not sure of the Supported/Maintained
 status of each block.

From the little bit of the discussion that I saw a few weeks ago the idea of 
file patterns in the MAINTAINERS file didn't go over very well.  I still 
don't see the F field specified/described at the top of the file.

As long as it is not a problem to have two maintainer entries, I think James' 
patch (what it currently in-tree) is pretty good right now - it fits with the 
rest of the NETWORKING [*] entries and looks correct to me.

 The distinction is supposed to be:

 Supported:Someone is actually paid to look after this.
 Maintained:   Someone actually looks after it.

 Could you please clarify those for me?

Sure.  HP is my current employer, i.e. they pay me, and both myself and HP 
have pledged to continue supporting NetLabel (see the patchset posting that 
was first accepted into the 2.6.19); I imagine this would fall under 
the Supported category as currently stated.  A few days ago I was asked, 
and agreed to, maintain all of the labeled networking code (in addition to 
NetLabel).  While it is extremely likely that HP will support this decision 
and allow me to work on all of the labeled networking infrastructure at work, 
it would be overstepping my role within the company to say that HP is 
pledging support for all of labeled networking.

I think the important thing here is that someone is looking after this, 
whether or not they are actually paid to do so is not quite as important in 
my mind.  If you feel strongly about the distinction please let me know and I 
will update the status when/if it changes.

-- 
paul moore
linux security @ hp
-
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/

Re: [PATCH] Version 7 (2.6.23) Smack: Simplified Mandatory Access Control Kernel

[Paul Moore]

On Sunday 14 October 2007 11:30:53 pm Casey Schaufler wrote:
 --- Ahmed S. Darwish [EMAIL PROTECTED] wrote:
  Hi Casey,
 
  On Sun, Oct 14, 2007 at 10:15:42AM -0700, Casey Schaufler wrote:
   +
   +CIPSO Configuration
   +
   +It is normally unnecessary to specify the CIPSO configuration. The
   default +values used by the system handle all internal cases. Smack
   will compose
 
  CIPSO
 
   +label values to match the Smack labels being used without
   administrative +intervention.
 
  I have two issues with CIPSO and Smack:
 
  1-
 
  Using default configuration (system startup script + smacfs fstab line),
  system
  can't access any service outside the Lan. ICMP parameter problem
  message always
  appear from the first Wan router (traceroute + tcpdump at [1]).
 
  Services inside the LAN can be accessed normally. System can connect to a
  Lan Windows share. It also connects to the gateway HTTP server easily.
 
  After some tweaking, I discovered that using CIPSOv6 solves all above
  problems:
  $ echo -n NLBL_CIPSOv6  /smack/nltype
 
  Is this a normal behaviour ?

 Well ... sort of. CIPSOv6 isn't actually implemented in the
 labeled networking code. What you're seeing is unlabeled packets.

 As far as CIPSOv4 and your WAN router, It is possible that it is
 configured either to reject CIPSO packets or to allow only CIPSO
 packets in a particular DOI or to enforce a CIPSO policy of its
 own.

The how/why of the packet rejection probably isn't all that important, but the 
most likely scenario based on the ICMP error code is that the router simply 
does not know about the CIPSO IP option type and is dropping the packet as a 
result.  I'd be very surprised to see a standard router in general use which 
has policy to perform packet level access control using CIPSO options/labels.

-- 
paul moore
linux security @ hp
-
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/

Re: [PATCH] x86: remove the x32 syscall bitmask from syscall_get_nr()

[Paul Moore]

On Monday, March 25, 2013 04:55:17 PM Paul Moore wrote:
 On Friday, March 15, 2013 03:18:12 PM H.J. Lu wrote:
  On Fri, Mar 15, 2013 at 2:56 PM, H. Peter Anvin h...@zytor.com wrote:
   On 03/15/2013 02:15 PM, Paul Moore wrote:
   On Tuesday, February 26, 2013 03:58:23 PM Paul Moore wrote:
   On Friday, February 15, 2013 12:21:43 PM Paul Moore wrote:
   Commit fca460f95e928bae373daa8295877b6905bc62b8 simplified the x32
   implementation by creating a syscall bitmask, equal to 0x4000,
   that
   could be applied to x32 syscalls such that the masked syscall number
   would be the same as a x86_64 syscall.  While that patch was a nice
   way to simplify the code, it went a bit too far by adding the mask to
   syscall_get_nr(); returning the masked syscall numbers can cause
   confusion with callers that expect syscall numbers matching the x32
   ABI, e.g. unmasked syscall numbers.
   
   This patch fixes this by simply removing the mask from
   syscall_get_nr()
   while preserving the other changes from the original commit.  While
   there are several syscall_get_nr() callers in the kernel, most simply
   check that the syscall number is greater than zero, in this case this
   patch will have no effect.  Of those remaining callers, they appear
   to be few, seccomp and ftrace, and from my testing of seccomp without
   this patch the original commit definitely breaks things; the seccomp
   filter does not correctly filter the syscalls due to the difference
   in
   syscall numbers in the BPF filter and the value from
   syscall_get_nr().
   Applying this patch restores the seccomp BPF filter functionality on
   x32.
   
   I've tested this patch with the seccomp BPF filters as well as ftrace
   and everything looks reasonable to me; needless to say general usage
   seemed fine as well.
   
   I just wanted to check and see where things stood with this patch. 
   I'm
   not
   overly concerned about how this problem is solved, just that it is
   solved.
   If someone else has a better approach that is fine with me; I'll even
   make
   the offer to do additional testing if needed.
   
   Anyone?  The seccomp filter bits are completely broken on x32 and I'd
   like to get this fixed, if not with this patch then something else -
   I'm
   more than happy to test/verify/etc whatever solution is deemed best ...
   
   Seems good to me -- H.J., do you seen any problem with this?
  
  It looks OK to me.
 
 Great, any chance of getting this fix merged for 3.9?

Just a ping to see where we stand on getting this patch merged.  Just a 
reminder that SECCOMP_FILTER is completely broken on x32 and either needs this 
patch, or another one, to fix the regression.

-- 
paul moore
security and virtualization @ redhat

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] x86: remove the x32 syscall bitmask from syscall_get_nr()

[Paul Moore]

On Tuesday, February 26, 2013 03:58:23 PM Paul Moore wrote:
 On Friday, February 15, 2013 12:21:43 PM Paul Moore wrote:
  Commit fca460f95e928bae373daa8295877b6905bc62b8 simplified the x32
  implementation by creating a syscall bitmask, equal to 0x4000, that
  could be applied to x32 syscalls such that the masked syscall number
  would be the same as a x86_64 syscall.  While that patch was a nice
  way to simplify the code, it went a bit too far by adding the mask to
  syscall_get_nr(); returning the masked syscall numbers can cause
  confusion with callers that expect syscall numbers matching the x32
  ABI, e.g. unmasked syscall numbers.
  
  This patch fixes this by simply removing the mask from syscall_get_nr()
  while preserving the other changes from the original commit.  While
  there are several syscall_get_nr() callers in the kernel, most simply
  check that the syscall number is greater than zero, in this case this
  patch will have no effect.  Of those remaining callers, they appear
  to be few, seccomp and ftrace, and from my testing of seccomp without
  this patch the original commit definitely breaks things; the seccomp
  filter does not correctly filter the syscalls due to the difference in
  syscall numbers in the BPF filter and the value from syscall_get_nr().
  Applying this patch restores the seccomp BPF filter functionality on
  x32.
  
  I've tested this patch with the seccomp BPF filters as well as ftrace
  and everything looks reasonable to me; needless to say general usage
  seemed fine as well.
 
 I just wanted to check and see where things stood with this patch.  I'm not
 overly concerned about how this problem is solved, just that it is solved. 
 If someone else has a better approach that is fine with me; I'll even make
 the offer to do additional testing if needed.

Anyone?  The seccomp filter bits are completely broken on x32 and I'd like to 
get this fixed, if not with this patch then something else - I'm more than 
happy to test/verify/etc whatever solution is deemed best ...

  Signed-off-by: Paul Moore pmo...@redhat.com
  Cc: sta...@vger.kernel.org
  Cc: Will Drewry w...@chromium.org
  Cc: H. Peter Anvin h...@zytor.com
  ---
  
   arch/x86/include/asm/syscall.h |4 ++--
   1 file changed, 2 insertions(+), 2 deletions(-)
  
  diff --git a/arch/x86/include/asm/syscall.h
  b/arch/x86/include/asm/syscall.h index 1ace47b..2e188d6 100644
  --- a/arch/x86/include/asm/syscall.h
  +++ b/arch/x86/include/asm/syscall.h
  @@ -29,13 +29,13 @@ extern const unsigned long sys_call_table[];
  
*/
   
   static inline int syscall_get_nr(struct task_struct *task, struct pt_regs
  
  *regs) {
  -   return regs-orig_ax  __SYSCALL_MASK;
  +   return regs-orig_ax;
  
   }
   
   static inline void syscall_rollback(struct task_struct *task,
   
  struct pt_regs *regs)
   
   {
  
  -   regs-ax = regs-orig_ax  __SYSCALL_MASK;
  +   regs-ax = regs-orig_ax;
  
   }
   
   static inline long syscall_get_error(struct task_struct *task,
-- 
paul moore
security and virtualization @ redhat

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] x86: remove the x32 syscall bitmask from syscall_get_nr()

[Paul Moore]

On Friday, March 15, 2013 03:18:12 PM H.J. Lu wrote:
 On Fri, Mar 15, 2013 at 2:56 PM, H. Peter Anvin h...@zytor.com wrote:
  On 03/15/2013 02:15 PM, Paul Moore wrote:
  On Tuesday, February 26, 2013 03:58:23 PM Paul Moore wrote:
  On Friday, February 15, 2013 12:21:43 PM Paul Moore wrote:
  Commit fca460f95e928bae373daa8295877b6905bc62b8 simplified the x32
  implementation by creating a syscall bitmask, equal to 0x4000, that
  could be applied to x32 syscalls such that the masked syscall number
  would be the same as a x86_64 syscall.  While that patch was a nice
  way to simplify the code, it went a bit too far by adding the mask to
  syscall_get_nr(); returning the masked syscall numbers can cause
  confusion with callers that expect syscall numbers matching the x32
  ABI, e.g. unmasked syscall numbers.
  
  This patch fixes this by simply removing the mask from syscall_get_nr()
  while preserving the other changes from the original commit.  While
  there are several syscall_get_nr() callers in the kernel, most simply
  check that the syscall number is greater than zero, in this case this
  patch will have no effect.  Of those remaining callers, they appear
  to be few, seccomp and ftrace, and from my testing of seccomp without
  this patch the original commit definitely breaks things; the seccomp
  filter does not correctly filter the syscalls due to the difference in
  syscall numbers in the BPF filter and the value from syscall_get_nr().
  Applying this patch restores the seccomp BPF filter functionality on
  x32.
  
  I've tested this patch with the seccomp BPF filters as well as ftrace
  and everything looks reasonable to me; needless to say general usage
  seemed fine as well.
  
  I just wanted to check and see where things stood with this patch.  I'm
  not
  overly concerned about how this problem is solved, just that it is
  solved.
  If someone else has a better approach that is fine with me; I'll even
  make
  the offer to do additional testing if needed.
  
  Anyone?  The seccomp filter bits are completely broken on x32 and I'd
  like to get this fixed, if not with this patch then something else - I'm
  more than happy to test/verify/etc whatever solution is deemed best ...
  
  Seems good to me -- H.J., do you seen any problem with this?
 
 It looks OK to me.

Great, any chance of getting this fix merged for 3.9?

-- 
paul moore
security and virtualization @ redhat

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: linux-next: Tree for Nov 29 (netlabel)

[Paul Moore]

On Thursday, November 29, 2012 04:05:26 PM Randy Dunlap wrote:
 On 11/28/2012 10:40 PM, Stephen Rothwell wrote:
  Hi all,
 
  Changes since 20121128:
 (on i386:)

If I had to guess it looks like CONFIG_NETLABEL needs to be dependent on 
CONFIG_INET.  While the net/ Kconfig only pulls in the net/netlabel Kconfig if 
CONFIG_INET is defined, I'm guessing that without the explicit dependency 
there is nothing preventing someone from arriving at a bad configuration as we 
see here.

Let me test this out to make sure my reasoning is right and if it is I'll post 
a patch to netdev later today.

Thanks for catching this.

 net/built-in.o: In function `netlbl_cfg_cipsov4_add':
 (.text+0x61757): undefined reference to `cipso_v4_doi_add'
 net/built-in.o: In function `netlbl_cfg_cipsov4_del':
 (.text+0x6177d): undefined reference to `cipso_v4_doi_remove'
 net/built-in.o: In function `netlbl_cfg_cipsov4_map_add':
 (.text+0x617ae): undefined reference to `cipso_v4_doi_getdef'
 net/built-in.o: In function `netlbl_cfg_cipsov4_map_add':
 (.text+0x61a49): undefined reference to `cipso_v4_doi_putdef'
 net/built-in.o: In function `netlbl_sock_setattr':
 (.text+0x6218c): undefined reference to `cipso_v4_sock_setattr'
 net/built-in.o: In function `netlbl_sock_delattr':
 (.text+0x6220b): undefined reference to `cipso_v4_sock_delattr'
 net/built-in.o: In function `netlbl_sock_getattr':
 (.text+0x62238): undefined reference to `cipso_v4_sock_getattr'
 net/built-in.o: In function `netlbl_conn_setattr':
 (.text+0x622de): undefined reference to `cipso_v4_sock_setattr'
 net/built-in.o: In function `netlbl_conn_setattr':
 (.text+0x62303): undefined reference to `cipso_v4_sock_delattr'
 net/built-in.o: In function `netlbl_req_setattr':
 (.text+0x62429): undefined reference to `cipso_v4_req_setattr'
 net/built-in.o: In function `netlbl_req_setattr':
 (.text+0x6244e): undefined reference to `cipso_v4_req_delattr'
 net/built-in.o: In function `netlbl_req_delattr':
 (.text+0x624ba): undefined reference to `cipso_v4_req_delattr'
 net/built-in.o: In function `netlbl_skbuff_setattr':
 (.text+0x62551): undefined reference to `cipso_v4_skbuff_setattr'
 net/built-in.o: In function `netlbl_skbuff_setattr':
 (.text+0x62576): undefined reference to `cipso_v4_skbuff_delattr'
 net/built-in.o: In function `netlbl_skbuff_getattr':
 (.text+0x62619): undefined reference to `cipso_v4_skbuff_getattr'
 net/built-in.o: In function `netlbl_skbuff_err':
 (.text+0x62685): undefined reference to `cipso_v4_error'
 net/built-in.o: In function `netlbl_cache_invalidate':
 (.text+0x626ab): undefined reference to `cipso_v4_cache_invalidate'
 net/built-in.o: In function `netlbl_cache_add':
 (.text+0x626ec): undefined reference to `cipso_v4_cache_add'
 net/built-in.o: In function `netlbl_domhsh_remove_entry':
 (.text+0x63294): undefined reference to `cipso_v4_doi_putdef'
 net/built-in.o: In function `netlbl_domhsh_remove_entry':
 (.text+0x632eb): undefined reference to `cipso_v4_doi_putdef'
 net/built-in.o: In function `netlbl_domhsh_remove_af4':
 (.text+0x6349b): undefined reference to `cipso_v4_doi_putdef'
 net/built-in.o: In function `netlbl_mgmt_add_common.clone.1':
 netlabel_mgmt.c:(.text+0x64a87): undefined reference to
 `cipso_v4_doi_getdef' netlabel_mgmt.c:(.text+0x64c83): undefined reference
 to `cipso_v4_doi_putdef' net/built-in.o: In function
 `netlbl_cipsov4_listall':
 netlabel_cipso_v4.c:(.text+0x66e52): undefined reference to
 `cipso_v4_doi_walk' net/built-in.o: In function `netlbl_cipsov4_list':
 netlabel_cipso_v4.c:(.text+0x67199): undefined reference to
 `cipso_v4_doi_getdef' net/built-in.o: In function `netlbl_cipsov4_remove':
 netlabel_cipso_v4.c:(.text+0x6771b): undefined reference to
 `cipso_v4_doi_remove' net/built-in.o: In function
 `netlbl_cipsov4_add_pass':
 netlabel_cipso_v4.c:(.text+0x67a4b): undefined reference to
 `cipso_v4_doi_add' netlabel_cipso_v4.c:(.text+0x67a76): undefined reference
 to `cipso_v4_doi_free' net/built-in.o: In function
 `netlbl_cipsov4_add_local':
 netlabel_cipso_v4.c:(.text+0x67b9a): undefined reference to
 `cipso_v4_doi_add' netlabel_cipso_v4.c:(.text+0x67bc5): undefined reference
 to `cipso_v4_doi_free' net/built-in.o: In function
 `netlbl_cipsov4_add_std':
 netlabel_cipso_v4.c:(.text+0x68535): undefined reference to
 `cipso_v4_doi_add' netlabel_cipso_v4.c:(.text+0x68575): undefined reference
 to `cipso_v4_doi_free'
 
 
 Full randconfig file is attached.
-- 
paul moore
www.paul-moore.com

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: linux-next: Tree for Nov 29 (netlabel)

[Paul Moore]

On Friday, November 30, 2012 10:19:16 AM Paul Moore wrote:
 On Thursday, November 29, 2012 04:05:26 PM Randy Dunlap wrote:
  On 11/28/2012 10:40 PM, Stephen Rothwell wrote:
   Hi all,
  
   Changes since 20121128:
  (on i386:)
 
 If I had to guess it looks like CONFIG_NETLABEL needs to be dependent on
 CONFIG_INET.  While the net/ Kconfig only pulls in the net/netlabel Kconfig
 if CONFIG_INET is defined, I'm guessing that without the explicit
 dependency there is nothing preventing someone from arriving at a bad
 configuration as we see here.
 
 Let me test this out to make sure my reasoning is right and if it is I'll
 post a patch to netdev later today.
 
 Thanks for catching this.

Hmmm.  The existing logic in net/Kconfig seems to disable CONFIG_NETLABEL at 
build time whenever CONFIG_INET is disabled in my .config file.  The only way 
I can recreate what you are seeing here is if I move the NetLabel include 
outside of the INET conditional in net/Kconfig.

Regardless, adding an explicit dependency on INET to NETLABEL shouldn't hurt 
anything so I'll go ahead and post the patch to netdev.  Hopefully someone who 
understands Kconfig better than I do can help shed some light on this.

  net/built-in.o: In function `netlbl_cfg_cipsov4_add':
  (.text+0x61757): undefined reference to `cipso_v4_doi_add'
  net/built-in.o: In function `netlbl_cfg_cipsov4_del':
  (.text+0x6177d): undefined reference to `cipso_v4_doi_remove'
  net/built-in.o: In function `netlbl_cfg_cipsov4_map_add':
  (.text+0x617ae): undefined reference to `cipso_v4_doi_getdef'
  net/built-in.o: In function `netlbl_cfg_cipsov4_map_add':
  (.text+0x61a49): undefined reference to `cipso_v4_doi_putdef'
  net/built-in.o: In function `netlbl_sock_setattr':
  (.text+0x6218c): undefined reference to `cipso_v4_sock_setattr'
  net/built-in.o: In function `netlbl_sock_delattr':
  (.text+0x6220b): undefined reference to `cipso_v4_sock_delattr'
  net/built-in.o: In function `netlbl_sock_getattr':
  (.text+0x62238): undefined reference to `cipso_v4_sock_getattr'
  net/built-in.o: In function `netlbl_conn_setattr':
  (.text+0x622de): undefined reference to `cipso_v4_sock_setattr'
  net/built-in.o: In function `netlbl_conn_setattr':
  (.text+0x62303): undefined reference to `cipso_v4_sock_delattr'
  net/built-in.o: In function `netlbl_req_setattr':
  (.text+0x62429): undefined reference to `cipso_v4_req_setattr'
  net/built-in.o: In function `netlbl_req_setattr':
  (.text+0x6244e): undefined reference to `cipso_v4_req_delattr'
  net/built-in.o: In function `netlbl_req_delattr':
  (.text+0x624ba): undefined reference to `cipso_v4_req_delattr'
  net/built-in.o: In function `netlbl_skbuff_setattr':
  (.text+0x62551): undefined reference to `cipso_v4_skbuff_setattr'
  net/built-in.o: In function `netlbl_skbuff_setattr':
  (.text+0x62576): undefined reference to `cipso_v4_skbuff_delattr'
  net/built-in.o: In function `netlbl_skbuff_getattr':
  (.text+0x62619): undefined reference to `cipso_v4_skbuff_getattr'
  net/built-in.o: In function `netlbl_skbuff_err':
  (.text+0x62685): undefined reference to `cipso_v4_error'
  net/built-in.o: In function `netlbl_cache_invalidate':
  (.text+0x626ab): undefined reference to `cipso_v4_cache_invalidate'
  net/built-in.o: In function `netlbl_cache_add':
  (.text+0x626ec): undefined reference to `cipso_v4_cache_add'
  net/built-in.o: In function `netlbl_domhsh_remove_entry':
  (.text+0x63294): undefined reference to `cipso_v4_doi_putdef'
  net/built-in.o: In function `netlbl_domhsh_remove_entry':
  (.text+0x632eb): undefined reference to `cipso_v4_doi_putdef'
  net/built-in.o: In function `netlbl_domhsh_remove_af4':
  (.text+0x6349b): undefined reference to `cipso_v4_doi_putdef'
  net/built-in.o: In function `netlbl_mgmt_add_common.clone.1':
  netlabel_mgmt.c:(.text+0x64a87): undefined reference to
  `cipso_v4_doi_getdef' netlabel_mgmt.c:(.text+0x64c83): undefined reference
  to `cipso_v4_doi_putdef' net/built-in.o: In function
  `netlbl_cipsov4_listall':
  netlabel_cipso_v4.c:(.text+0x66e52): undefined reference to
  `cipso_v4_doi_walk' net/built-in.o: In function `netlbl_cipsov4_list':
  netlabel_cipso_v4.c:(.text+0x67199): undefined reference to
  `cipso_v4_doi_getdef' net/built-in.o: In function `netlbl_cipsov4_remove':
  netlabel_cipso_v4.c:(.text+0x6771b): undefined reference to
  `cipso_v4_doi_remove' net/built-in.o: In function
  `netlbl_cipsov4_add_pass':
  netlabel_cipso_v4.c:(.text+0x67a4b): undefined reference to
  `cipso_v4_doi_add' netlabel_cipso_v4.c:(.text+0x67a76): undefined
  reference
  to `cipso_v4_doi_free' net/built-in.o: In function
  `netlbl_cipsov4_add_local':
  netlabel_cipso_v4.c:(.text+0x67b9a): undefined reference to
  `cipso_v4_doi_add' netlabel_cipso_v4.c:(.text+0x67bc5): undefined
  reference
  to `cipso_v4_doi_free' net/built-in.o: In function
  `netlbl_cipsov4_add_std':
  netlabel_cipso_v4.c:(.text+0x68535): undefined reference to
  `cipso_v4_doi_add' netlabel_cipso_v4.c:(.text+0x68575

Re: [PATCH] Smack: Add missing depends on INET in Kconfig

[Paul Moore]

On Friday, November 30, 2012 09:40:09 AM Randy Dunlap wrote:
 On 11/30/2012 09:28 AM, Casey Schaufler wrote:
  Because NETLABEL depends on INET SECURITY_SMACK
  has to explicitly call out the dependency.
  
  Signed-off-by: Casey Schaufler ca...@schaufler-ca.com
 
 Acked-by: Randy Dunlap rdun...@xenotime.net
 
 Thanks for the quick fix.

+1

Thanks Casey.

  ---
  
   security/smack/Kconfig |1 +
   1 file changed, 1 insertion(+)
  
  diff --git a/security/smack/Kconfig b/security/smack/Kconfig
  index 9fb14ef..1be1088 100644
  --- a/security/smack/Kconfig
  +++ b/security/smack/Kconfig
  @@ -1,5 +1,6 @@
  
   config SECURITY_SMACK
   
  bool Simplified Mandatory Access Control Kernel Support
  
  +   depends on INET
  
  depends on NET
  depends on SECURITY
  select NETLABEL
  
  --
-- 
paul moore
www.paul-moore.com

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] x86: remove the x32 syscall bitmask from syscall_get_nr()

[Paul Moore]

On Friday, February 15, 2013 12:21:43 PM Paul Moore wrote:
 Commit fca460f95e928bae373daa8295877b6905bc62b8 simplified the x32
 implementation by creating a syscall bitmask, equal to 0x4000, that
 could be applied to x32 syscalls such that the masked syscall number
 would be the same as a x86_64 syscall.  While that patch was a nice
 way to simplify the code, it went a bit too far by adding the mask to
 syscall_get_nr(); returning the masked syscall numbers can cause
 confusion with callers that expect syscall numbers matching the x32
 ABI, e.g. unmasked syscall numbers.
 
 This patch fixes this by simply removing the mask from syscall_get_nr()
 while preserving the other changes from the original commit.  While
 there are several syscall_get_nr() callers in the kernel, most simply
 check that the syscall number is greater than zero, in this case this
 patch will have no effect.  Of those remaining callers, they appear
 to be few, seccomp and ftrace, and from my testing of seccomp without
 this patch the original commit definitely breaks things; the seccomp
 filter does not correctly filter the syscalls due to the difference in
 syscall numbers in the BPF filter and the value from syscall_get_nr().
 Applying this patch restores the seccomp BPF filter functionality on
 x32.
 
 I've tested this patch with the seccomp BPF filters as well as ftrace
 and everything looks reasonable to me; needless to say general usage
 seemed fine as well.

I just wanted to check and see where things stood with this patch.  I'm not 
overly concerned about how this problem is solved, just that it is solved.  If 
someone else has a better approach that is fine with me; I'll even make the 
offer to do additional testing if needed.

-Paul

 Signed-off-by: Paul Moore pmo...@redhat.com
 Cc: sta...@vger.kernel.org
 Cc: Will Drewry w...@chromium.org
 Cc: H. Peter Anvin h...@zytor.com
 ---
  arch/x86/include/asm/syscall.h |4 ++--
  1 file changed, 2 insertions(+), 2 deletions(-)
 
 diff --git a/arch/x86/include/asm/syscall.h b/arch/x86/include/asm/syscall.h
 index 1ace47b..2e188d6 100644
 --- a/arch/x86/include/asm/syscall.h
 +++ b/arch/x86/include/asm/syscall.h
 @@ -29,13 +29,13 @@ extern const unsigned long sys_call_table[];
   */
  static inline int syscall_get_nr(struct task_struct *task, struct pt_regs
 *regs) {
 - return regs-orig_ax  __SYSCALL_MASK;
 + return regs-orig_ax;
  }
 
  static inline void syscall_rollback(struct task_struct *task,
   struct pt_regs *regs)
  {
 - regs-ax = regs-orig_ax  __SYSCALL_MASK;
 + regs-ax = regs-orig_ax;
  }
 
  static inline long syscall_get_error(struct task_struct *task,

-- 
paul moore
security and virtualization @ redhat

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

ANN: libseccomp 2.0.0 released

[Paul Moore]

I would like to announce a new major release for the libseccomp library, 
libseccomp version 2.0.0.  The libseccomp library provides an easy to use, 
platform independent, interface to the Linux enhanced syscall filtering 
mechanism that was first introduced in Linux 3.5.

 * http://sourceforge.net/projects/libseccomp
 * http://sf.net/projects/libseccomp/files/libseccomp-2.0.0.tar.gz/download

This new version of libseccomp is source compatible with version 1.0.0 and 
later of the library.  Both the libseccomp v2.x and libseccomp v1.x libraries 
should be able to coexist on the same system but all users are encouraged to 
upgrade to the new version at their earliest convenience.

Changes in the 2.0.0 release include:

 * Fixes for the x86 multiplexed syscalls
 * Additions to the API to better support non-native architectures
 * Additions to the API to support multiple architectures in one filter
 * Additions to the API to resolve syscall name/number mappings
 * Assorted minor bug fixes
 * Improved build messages regardless of build verbosity
 * More automated tests added as well as a number of improvements to the test
   harness

Finally, thank you to everyone who has submitted suggestions, provided testing 
help, and contributed patches to the project.

-- 
paul moore
security and virtualization @ redhat

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] x86: remove the x32 syscall bitmask from syscall_get_nr()

[Paul Moore]

Commit fca460f95e928bae373daa8295877b6905bc62b8 simplified the x32
implementation by creating a syscall bitmask, equal to 0x4000, that
could be applied to x32 syscalls such that the masked syscall number
would be the same as a x86_64 syscall.  While that patch was a nice
way to simplify the code, it went a bit too far by adding the mask to
syscall_get_nr(); returning the masked syscall numbers can cause
confusion with callers that expect syscall numbers matching the x32
ABI, e.g. unmasked syscall numbers.

This patch fixes this by simply removing the mask from syscall_get_nr()
while preserving the other changes from the original commit.  While
there are several syscall_get_nr() callers in the kernel, most simply
check that the syscall number is greater than zero, in this case this
patch will have no effect.  Of those remaining callers, they appear
to be few, seccomp and ftrace, and from my testing of seccomp without
this patch the original commit definitely breaks things; the seccomp
filter does not correctly filter the syscalls due to the difference in
syscall numbers in the BPF filter and the value from syscall_get_nr().
Applying this patch restores the seccomp BPF filter functionality on
x32.

I've tested this patch with the seccomp BPF filters as well as ftrace
and everything looks reasonable to me; needless to say general usage
seemed fine as well.

Signed-off-by: Paul Moore pmo...@redhat.com
Cc: sta...@vger.kernel.org
Cc: Will Drewry w...@chromium.org
Cc: H. Peter Anvin h...@zytor.com
---
 arch/x86/include/asm/syscall.h |4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/x86/include/asm/syscall.h b/arch/x86/include/asm/syscall.h
index 1ace47b..2e188d6 100644
--- a/arch/x86/include/asm/syscall.h
+++ b/arch/x86/include/asm/syscall.h
@@ -29,13 +29,13 @@ extern const unsigned long sys_call_table[];
  */
 static inline int syscall_get_nr(struct task_struct *task, struct pt_regs 
*regs)
 {
-   return regs-orig_ax  __SYSCALL_MASK;
+   return regs-orig_ax;
 }
 
 static inline void syscall_rollback(struct task_struct *task,
struct pt_regs *regs)
 {
-   regs-ax = regs-orig_ax  __SYSCALL_MASK;
+   regs-ax = regs-orig_ax;
 }
 
 static inline long syscall_get_error(struct task_struct *task,

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] x86: remove the x32 syscall bitmask from syscall_get_nr()

[Paul Moore]

On Friday, February 15, 2013 11:02:49 AM H. Peter Anvin wrote:
 On 02/15/2013 09:21 AM, Paul Moore wrote:
  Commit fca460f95e928bae373daa8295877b6905bc62b8 simplified the x32
  implementation by creating a syscall bitmask, equal to 0x4000, that
  could be applied to x32 syscalls such that the masked syscall number
  would be the same as a x86_64 syscall.  While that patch was a nice
  way to simplify the code, it went a bit too far by adding the mask to
  syscall_get_nr(); returning the masked syscall numbers can cause
  confusion with callers that expect syscall numbers matching the x32
  ABI, e.g. unmasked syscall numbers.
  
  This patch fixes this by simply removing the mask from syscall_get_nr()
  while preserving the other changes from the original commit.  While
  there are several syscall_get_nr() callers in the kernel, most simply
  check that the syscall number is greater than zero, in this case this
  patch will have no effect.  Of those remaining callers, they appear
  to be few, seccomp and ftrace, and from my testing of seccomp without
  this patch the original commit definitely breaks things; the seccomp
  filter does not correctly filter the syscalls due to the difference in
  syscall numbers in the BPF filter and the value from syscall_get_nr().
  Applying this patch restores the seccomp BPF filter functionality on
  x32.
  
  I've tested this patch with the seccomp BPF filters as well as ftrace
  and everything looks reasonable to me; needless to say general usage
  seemed fine as well.
 
 Hi... it isn't 100% clear from the description if you have audited *all*
 the callers?

I audited all of the syscall_get_nr() callers using the LXR at 
http://lxr.free-electrons.com with the 3.7 sources.  If you exclude all of the 
architecture dependent stuff that is non-x86 you arrive at the following list 
of callers:

* kernel/seccomp.c:seccomp_bpf_load()
This is where I noticed the problem, broken w/o the patch.

* lib/syscall.c:collect_syscall()/task_current_syscall()
The task_current_syscall() function is really only called by 
proc_pid_syscall() which displays the syscall number back to the user via a 
/proc entry, in which case this patch appears to correct a problem similar to 
what was seen with seccomp.

* kernel/trace/trace_syscalls.c:ftrace_syscall_enter()
* kernel/trace/trace_syscalls.c:ftrace_syscall_exit()
* kernel/trace/trace_syscalls.c:perf_syscall_enter()
* kernel/trace/trace_syscalls.c:perf_syscall_exit()
The ftrace/perf is the one user that I am least sure about, as noted above, I 
did some simple tests based on what I could find via Google but a quick review 
by someone who is more familiar with this code would be appreciated.  I'm most 
concerned about the syscall_metadata bits ...

* include/trace/events/syscall.h
Another, what I assume, is a ftrace user; I'm assuming the patch is reasonable 
based on my testing, but once again further review would be appreciated.

* arch/x86/kernel/ptrace.c:putreg32()
* arch/x86/kernel/signal.c:handle_signal()
* arch/x86/kernel/signal.c:do_signal()
Simple grater than zero checks.

-- 
paul moore
security and virtualization @ redhat

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: selinux networking: sleeping functin called from invalid context in 2.6.20-rc[12]

[Paul Moore]

On Tuesday, January 2 2007 2:58 am, Adam J. Richter wrote:
   I have not yet performed the 21 steps of
 linux-2.6.20-rc3/Documentation/SubmitChecklist, which I think is a
 great objectives list for future automation or some kind of community
 web site.  I hope to find time to make progress through that
 checklist, but, in the meantime, I think the world may nevertheless be
 infinitesmally better off if I post the patch that I'm currently
 using that seems to fix the problem, seeing as how rc3 has passed
 with no fix incorporated.

   I think the intent of the offending code was to avoid doing
 a lock_sock() in a presumably common case where there was no need to
 take the lock.  So, I have kept the presumably fast test to exit
 early.

   When it turns out to be necessary to take lock_sock(), RCU is
 unlocked, then lock_sock is taken, the RCU is locked again, and
 the test is repeated.

Hi Adam,

I'm sorry I just saw this mail (mail not sent directly to me get shuffled off 
to a folder).  I agree with your patch, I think dropping and then re-taking 
the RCU lock is the best way to go, although I'm curious to see what others 
have to say.

The only real comment I have with the patch is that there is some extra 
whitespace which could probably be removed, but that is more of a style nit 
than anything substantial.

   By the way, in a change not included in this patch,
 I also tried consolidating the RCU locking in this file into a macro
 IF_NLBL_REQUIRE(sksec, action), where action is the code
 fragment to be executed with rcu_read_lock() held, although this
 required splitting a couple of functions in half.

From your description above I'm not sure I like that approach so much, 
however, I could be misunderstanding something.  Do you have a small example 
you could send?

-- 
paul moore
linux security @ hp
-
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/

Re: selinux networking: sleeping functin called from invalid context in 2.6.20-rc[12]

[Paul Moore]

On Sunday, December 24 2006 7:25 pm, Andrew Morton wrote:
 On Mon, 25 Dec 2006 05:21:24 +0800

 Adam J. Richter [EMAIL PROTECTED] wrote:
  Under 2.6.20-rc1 and 2.6.20-rc2, I get the following complaint
  for several network programs running on my system:
 
  [  156.381868] BUG: sleeping function called from invalid context at
  net/core/sock.c:1523 [  156.381876] in_atomic():1, irqs_disabled():0
  [  156.381881] no locks held by kio_http/9693.
  [  156.381886]  [c01057a2] show_trace_log_lvl+0x1a/0x2f
  [  156.381900]  [c0105dab] show_trace+0x12/0x14
  [  156.381908]  [c0105e48] dump_stack+0x16/0x18
  [  156.381917]  [c011e30f] __might_sleep+0xe5/0xeb
  [  156.381926]  [c025942a] lock_sock_nested+0x1d/0xc4
  [  156.381937]  [c01cc570] selinux_netlbl_inode_permission+0x5a/0x8e
  [  156.381946]  [c01c2505] selinux_file_permission+0x96/0x9b
  [  156.381954]  [c0175a0a] vfs_write+0x8d/0x167
  [  156.381962]  [c017605a] sys_write+0x3f/0x63
  [  156.381971]  [c01040c0] syscall_call+0x7/0xb
  [  156.381980]  ===

 There's a glaring bug in selinux_netlbl_inode_permission() - taking
 lock_sock() inside rcu_read_lock().

Sorry for the delay, I'm finally back at a machine where I can look at the 
code.

I've been thinking about Parag Warudkar's and Ingo Molnar's patches as well as 
what the selinux_netlbl_inode_permission() function actually needs to do; I 
think the best answer isn't so much to change the socket locking calls, but 
to restructure the function a bit.

Currently the function does the following (in order):

 1. do some quick sanity checks (is the inode a socket, etc)
 2. rcu_read_lock()
 3. check the nlbl_state is set to NLBL_REQUIRE (otherwise return)
 4. lock_sock()
 5. netlabel magic
 6. release_sock()
 7. rcu_read_unlock()

I propose changing it to the following (in order):

  1. do some quick sanity checks (is the inode a socket, etc)
  2. rcu_read_lock()
  3. check the nlbl_state is set to NLBL_REQUIRE (otherwise return)
  4. rcu_read_unlock()
  5. lock_sock()
  6. rcu_read_lock()
  7. verify that nlbl_state is still set to NLBL_REQUIRE (otherwise return)
  8. netlabel magic
  9. rcu_read_unlock()
 10. release_sock()

This way we no longer need to worry about any special socket locking.  I 
realize this adds a bit of duplicated work but it is my understanding that 
RCU lock/unlock operations are *very* fast so the extra RCU lock operations 
shouldn't be too bad and the extra nlbl_state check should be of minimal 
cost.

However, I'm not the expert here, just a guy learning as he goes so any 
comments/feedback on the above proposal are welcome.  If it turns out this 
approach has some merit I'll put together a patch and send it out.

Once again, sorry for the regression.

-- 
paul moore
linux security @ hp
-
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/

Re: selinux networking: sleeping functin called from invalid context in 2.6.20-rc[12]

[Paul Moore]

-Original Message-
From: Andrew Morton [EMAIL PROTECTED]
Date: Sunday, Dec 24, 2006 7:25 pm
Subject: Re: selinux networking: sleeping functin called from invalid  context 
in 2.6.20-rc[12]

On Mon, 25 Dec 2006 05:21:24 +0800
Adam J. Richter [EMAIL PROTECTED] wrote:

  Under 2.6.20-rc1 and 2.6.20-rc2, I get the following complaint
 for several network programs running on my system:
 
 [  156.381868] BUG: sleeping function called from invalid context at 
 net/core/sock.c:1523
 [  156.381876] in_atomic():1, irqs_disabled():0
 [  156.381881] no locks held by kio_http/9693.
 [  156.381886]  [c01057a2] show_trace_log_lvl+0x1a/0x2f
 [  156.381900]  [c0105dab] show_trace+0x12/0x14
 [  156.381908]  [c0105e48] dump_stack+0x16/0x18
 [  156.381917]  [c011e30f] __might_sleep+0xe5/0xeb
 [  156.381926]  [c025942a] lock_sock_nested+0x1d/0xc4
 [  156.381937]  [c01cc570] selinux_netlbl_inode_permission+0x5a/0x8e
 [  156.381946]  [c01c2505] selinux_file_permission+0x96/0x9b
 [  156.381954]  [c0175a0a] vfs_write+0x8d/0x167
 [  156.381962]  [c017605a] sys_write+0x3f/0x63
 [  156.381971]  [c01040c0] syscall_call+0x7/0xb
 [  156.381980]  ===
 

There's a glaring bug in selinux_netlbl_inode_permission() - taking 
lock_sock() inside rcu_read_lock().

I would again draw attention to Documentation/SubmitChecklist.  In
particular please always always always enable all kernel debugging options 
when developing and testing new kernel code.  And everything else in that 
file, too.


I apologize for the mistake - I'm still trying to get a firm grasp on some of 
the finer points of Linux kernel development and I obviously missed something 
here.  Unfortunately, due to the holiday I won't be able to write/test/submit a 
patch until after the first of the year but I promise to do so as soon as I am 
able.

. paul moore
. linux security @ hp

-
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/

ANN: libseccomp 1.0.0 released

[Paul Moore]

I would like to announce the second release of the libseccomp library.  The 
libseccomp library provides an easy to use, platform independent, interface to 
Linux's enhanced syscall filtering mechanism.

 * http://sourceforge.net/projects/libseccomp
 * http://sf.net/projects/libseccomp/files/libseccomp-1.0.0.tar.gz/download

Significant changes in this release include:

 * The API is now context-aware; eliminating all internal state but breaking
   compatibility with the initial 0.1.0 release.  The major version number has
   been bumped with this release to allow both version to coexist on the same
   system.
 * Added support for multiple, simultaneous build jobs and verbose build
   output.  This should not affect individual developers, but it should make
   life easier for packagers.

Once again, thanks to everyone who has submitted suggestions, provided testing 
help, and contributed patches to the project.

-- 
paul moore
security and virtualization @ redhat

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: NULL pointer dereference in selinux_ip_postroute_compat

[Paul Moore]

On Tue, Aug 7, 2012 at 2:12 PM, John Stultz john.stu...@linaro.org wrote:
 Hi,
 With my kvm environment using 3.6-rc1+, I'm seeing NULL pointer
 dereferences in selinux_ip_postroute_compat(). It looks like the sksec value
 is null and we die in the following line:

 if (selinux_xfrm_postroute_last(sksec-sid, skb, ad, proto))

 This triggers every time I shutdown the machine, but has also triggered
 randomly after a few hours.

 This is on an ubuntu 12.04 image, not using selinux.

NOTE: Adding the SELinux list to the CC line

Hi,

I'm trying to understand this and I was hoping you could you clarify a
few things for me:

* Is the panic in the Ubuntu 12.04 guest, or the host?  If the host,
could you share what distribution you are using?
* When you say you are not using SELinux, could you be more specific?
It seems odd that you are not using SELinux but the panic is happening
in a SELinux hook.

Thanks.

 Running with the following kvm line:
 kvm -nographic -smp 4 -m 1G -hda disk.img -net user -net nic,model=virtio
 -redir tcp:4400::22 -kernel ./bzImage -initrd initrd.img-1-jstultz  -append
 root=UUID=b08aa86a-4b16-488f-a3de-33c2cf335bf0 ro console=ttyS0,115200n8

 Two different traces below. Config attached.

-- 
paul moore
www.paul-moore.com
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: NULL pointer dereference in selinux_ip_postroute_compat

[Paul Moore]

On Tue, Aug 7, 2012 at 5:58 PM, John Stultz john.stu...@linaro.org wrote:
 On 08/07/2012 02:50 PM, Paul Moore wrote:

 On Tue, Aug 7, 2012 at 2:12 PM, John Stultz john.stu...@linaro.org
 wrote:

 Hi,
  With my kvm environment using 3.6-rc1+, I'm seeing NULL pointer
 dereferences in selinux_ip_postroute_compat(). It looks like the sksec
 value
 is null and we die in the following line:

  if (selinux_xfrm_postroute_last(sksec-sid, skb, ad, proto))

 This triggers every time I shutdown the machine, but has also triggered
 randomly after a few hours.

 This is on an ubuntu 12.04 image, not using selinux.

 NOTE: Adding the SELinux list to the CC line

 Thanks!

 Hi,

 I'm trying to understand this and I was hoping you could you clarify a
 few things for me:

 * Is the panic in the Ubuntu 12.04 guest, or the host?  If the host,
 could you share what distribution you are using?

 Sorry, its a 12.04 guest.  I think the host is Ubuntu 12.04 as well.


 * When you say you are not using SELinux, could you be more specific?
 It seems odd that you are not using SELinux but the panic is happening
 in a SELinux hook.

 I just mean that, being Ubuntu,  the system (userland) isn't configured to
 use selinux.  SELinux is just enabled in the kernel config.

Thanks for the quick response, I'll setup an Ubuntu guest and see if I
can reproduce this ... something is odd.  Anything non-standard about
your guest install or anything else you think might be helpful?

-- 
paul moore
www.paul-moore.com
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: NULL pointer dereference in selinux_ip_postroute_compat

[Paul Moore]

On Tuesday, August 07, 2012 10:17:32 PM Serge E. Hallyn wrote:
 Quoting Paul Moore (p...@paul-moore.com):
  On Tue, Aug 7, 2012 at 5:58 PM, John Stultz john.stu...@linaro.org 
wrote:
   On 08/07/2012 02:50 PM, Paul Moore wrote:
   On Tue, Aug 7, 2012 at 2:12 PM, John Stultz john.stu...@linaro.org
   
   wrote:
   Hi,
   
With my kvm environment using 3.6-rc1+, I'm seeing NULL pointer
   
   dereferences in selinux_ip_postroute_compat(). It looks like the sksec
   value
   
   is null and we die in the following line:
if (selinux_xfrm_postroute_last(sksec-sid, skb, ad, proto))
   
   This triggers every time I shutdown the machine, but has also
   triggered
   randomly after a few hours.
   
   This is on an ubuntu 12.04 image, not using selinux.
   
   NOTE: Adding the SELinux list to the CC line
   
   Thanks!
   
   Hi,
   
   I'm trying to understand this and I was hoping you could you clarify a
   few things for me:
   
   * Is the panic in the Ubuntu 12.04 guest, or the host?  If the host,
   could you share what distribution you are using?
   
   Sorry, its a 12.04 guest.  I think the host is Ubuntu 12.04 as well.
   
   * When you say you are not using SELinux, could you be more specific?
   It seems odd that you are not using SELinux but the panic is happening
   in a SELinux hook.
   
   I just mean that, being Ubuntu,  the system (userland) isn't configured
   to
   use selinux.  SELinux is just enabled in the kernel config.
  
  Thanks for the quick response, I'll setup an Ubuntu guest and see if I
  can reproduce this ... something is odd.  Anything non-standard about
  your guest install or anything else you think might be helpful?
 
 The problem seems to be that selinux_nf_ip_init() was called, which
 registers the selinux_ipv4_ops (and ipv6).  Those should not get registered
 if selinux ends up not being loaded (as in, if apparmor is loaded first),
 since as you've found here the selinux lsm hooks won't be called to set
 call selinux_sk_alloc_security().
 
 I assume what's happening is that CONFIG_SECURITY_SELINUX_BOOTPARAM_VALUE
 was set to 1, but selinux ended up being set to disabled after the
 __initcall(selinux_nf_ip_init) ran?  Weird.

Yeah, nothing obvious is jumping out at me in the code except for some weird 
race condition like you mention above.  I'm downloading an Ubuntu ISO right 
now, it should be ready to play with tomorrow morning.

-- 
paul moore
www.paul-moore.com

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: NULL pointer dereference in selinux_ip_postroute_compat

[Paul Moore]

On Wednesday, August 08, 2012 12:14:42 PM John Stultz wrote:
 So I bisected this down and it seems to be the following commit:
 
 commit be9f4a44e7d41cee50ddb5f038fc2391cbbb4046
 Author: Eric Dumazet eduma...@google.com
 Date:   Thu Jul 19 07:34:03 2012 +
 
  ipv4: tcp: remove per net tcp_sock
 
 
 It doesn't revert totally cleanly, but after fixing up the rejections
 and booting with this patch removed on top of Linus' head the oops on
 shutdown goes away.

Thanks!

It looks the like there is a bug in ip_send_unicast_reply() which uses a 
inet_sock/sock struct which does not have the LSM data properly initialized. 

I'll put together a patch shortly.

-- 
paul moore
www.paul-moore.com

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: NULL pointer dereference in selinux_ip_postroute_compat

[Paul Moore]

On Wednesday, August 08, 2012 09:38:21 PM Eric Dumazet wrote:
 On Wed, 2012-08-08 at 15:26 -0400, Paul Moore wrote:
  On Wednesday, August 08, 2012 12:14:42 PM John Stultz wrote:
   So I bisected this down and it seems to be the following commit:
   
   commit be9f4a44e7d41cee50ddb5f038fc2391cbbb4046
   Author: Eric Dumazet eduma...@google.com
   Date:   Thu Jul 19 07:34:03 2012 +
   
ipv4: tcp: remove per net tcp_sock
   
   It doesn't revert totally cleanly, but after fixing up the rejections
   and booting with this patch removed on top of Linus' head the oops on
   shutdown goes away.
  
  Thanks!
  
  It looks the like there is a bug in ip_send_unicast_reply() which uses a
  inet_sock/sock struct which does not have the LSM data properly
  initialized.
  
  I'll put together a patch shortly.
 
 Something like this ?

Yep.  I was just trying to see if there was a way we could avoid having to 
make it conditional on CONFIG_SECURITY, but I think this is a better approach 
than the alternatives.

I'm also looking into making sure we get a sane LSM label on the per-cpu sock 
as security_sk_alloc() just allocates and initializes the LSM blob to a basic 
starting value (unlabeled_t in the case of SELinux) ... that is likely to be 
the tricky bit.

Regardless, I'm okay with us merging the patch below now to fix the panic and 
I'll supply a follow-up patch to fix the labeling once I figure out a solution 
that seems reasonable.  Does that work for you?  David?

Acked-by: Paul Moore p...@paul-moore.com

 diff --git a/net/ipv4/ip_output.c b/net/ipv4/ip_output.c
 index ba39a52..027a331 100644
 --- a/net/ipv4/ip_output.c
 +++ b/net/ipv4/ip_output.c
 @@ -1524,6 +1524,10 @@ void ip_send_unicast_reply(struct net *net, struct
 sk_buff *skb, __be32 daddr, sk-sk_priority = skb-priority;
   sk-sk_protocol = ip_hdr(skb)-protocol;
   sk-sk_bound_dev_if = arg-bound_dev_if;
 +#ifdef CONFIG_SECURITY
 + if (!sk-sk_security  security_sk_alloc(sk, PF_INET, GFP_ATOMIC))
 + goto out;
 +#endif
   sock_net_set(sk, net);
   __skb_queue_head_init(sk-sk_write_queue);
   sk-sk_sndbuf = sysctl_wmem_default;
 @@ -1539,7 +1543,7 @@ void ip_send_unicast_reply(struct net *net, struct
 sk_buff *skb, __be32 daddr, skb_set_queue_mapping(nskb,
 skb_get_queue_mapping(skb));
   ip_push_pending_frames(sk, fl4);
   }
 -
 +out:
   put_cpu_var(unicast_sock);
 
   ip_rt_put(rt);

-- 
paul moore
www.paul-moore.com

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: NULL pointer dereference in selinux_ip_postroute_compat

[Paul Moore]

On Wednesday, August 08, 2012 10:09:38 PM Eric Dumazet wrote:
 On Wed, 2012-08-08 at 15:59 -0400, Eric Paris wrote:
  Seems wrong.  We shouldn't ever need ifdef CONFIG_SECURITY in core
  code.
 
 Sure but it seems include file misses an accessor for this.
 
 We could add it on a future cleanup patch, as Paul mentioned.

Actually, the issue is that the shared socket doesn't have an init/alloc 
function to do the LSM allocation like we do with other sockets so Eric's 
patch does it as part of ip_send_unicast_reply().

If we look at the relevant part of Eric's patch:

 +#ifdef CONFIG_SECURITY
 +   if (!sk-sk_security  security_sk_alloc(sk, PF_INET, GFP_ATOMIC))
 +   goto out;
 +#endif

... if we were to remove the CONFIG_SECURITY conditional we would end up 
calling security_sk_alloc() each time through in the CONFIG_SECURITY=n case as 
sk-sk_security would never be initialized to a non-NULL value.  In the 
CONFIG_SECURITY=y case it should only be called once as security_sk_alloc() 
should set sk-sk_security to a LSM blob.

   Ifndef CONF_SECURITY then security_sk_alloc() is a static
  
  inline return 0;   I guess the question is Where did the sk come
  from?  Why wasn't security_sk_alloc() called when it was allocated?
  Should it have been updated at some time and that wasn't done either?
  Seems wrong to be putting packets on the queue for a socket where the
  security data was never allocated and was never set to its proper
  state.
 
 IMHO it seems wrong to even care about security for internal sockets.

 They are per cpu, shared for all users on the machine.

The issue, from a security point of view, is that these sockets are sending 
network traffic; even if it is just resets and timewait ACKs, it is still 
network traffic and the LSMs need to be able to enforce security policy on 
this traffic.  After all, what would you say if your firewall let these same 
packets pass without any filtering?

The issue I'm struggling with at present is how should we handle this traffic 
from a LSM perspective.  The label based LSMs, e.g. SELinux and Smack, use the 
LSM blob assigned to locally generated outbound traffic to identify the 
traffic and apply the security policy, so not only do we have to resolve the 
issue of ensuring the traffic is labeled correctly, we have to do it with a 
shared socket (although the patch didn't change the shared nature of the 
socket).

For those who are interested, I think the reasonable labeling solution here is 
to go with SECINITSID_KERNEL/kernel_t for SELinux and likely the ambient label 
for Smack as in both the TCP reset and timewait ACK there shouldn't be any 
actual user data present.

-- 
paul moore
www.paul-moore.com

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: NULL pointer dereference in selinux_ip_postroute_compat

[Paul Moore]

On Wednesday, August 08, 2012 10:32:52 PM Eric Dumazet wrote:
 On Wed, 2012-08-08 at 22:09 +0200, Eric Dumazet wrote:
  On Wed, 2012-08-08 at 15:59 -0400, Eric Paris wrote:
   Seems wrong.  We shouldn't ever need ifdef CONFIG_SECURITY in core
   code.
  
  Sure but it seems include file misses an accessor for this.
  
  We could add it on a future cleanup patch, as Paul mentioned.
 
 I cooked following patch.
 But smack/smack_lsm.c makes a reference to
 smk_of_current()... so it seems we are in a hole...
 
 It makes little sense to me to have any kind of security on this
 internal sockets.
 
 Maybe selinux should not crash if sk-sk_security is NULL ?

I realize our last emails probably passed each other mid-flight, but hopefully 
it explains why we can't just pass packets when sk-sk_security is NULL.

Regardless, some quick comments below ...

 diff --git a/security/selinux/hooks.c b/security/selinux/hooks.c
 index 6c77f63..459eca6 100644
 --- a/security/selinux/hooks.c
 +++ b/security/selinux/hooks.c
 @@ -4289,10 +4289,13 @@ out:
   return 0;
  }
 
 -static int selinux_sk_alloc_security(struct sock *sk, int family, ...
 +static int selinux_sk_alloc_security(struct sock *sk, int family, ...
  {
   struct sk_security_struct *sksec;
 
 + if (check  sk-sk_security)
 + return 0;
 +
   sksec = kzalloc(sizeof(*sksec), priority);
   if (!sksec)
   return -ENOMEM;

I think I might replace the check boolean with a kern/kernel boolean so 
that in addition to the allocation we can also initialize the socket to 
SECINITSID_KERNEL/kernel_t here in the case when the boolean is set.  The only 
place that would set the boolean to true would be ip_send_unicast_reply(), all 
other callers would set it to false.

 diff --git a/security/smack/smack_lsm.c b/security/smack/smack_lsm.c
 index 8221514..8965cf1 100644
 --- a/security/smack/smack_lsm.c
 +++ b/security/smack/smack_lsm.c
 @@ -1754,11 +1754,14 @@ static void smack_task_to_inode(struct task_struct
 *p, struct inode *inode) *
   * Returns 0 on success, -ENOMEM is there's no memory
   */
 -static int smack_sk_alloc_security(struct sock *sk, int family, gfp_t
 gfp_flags) +static int smack_sk_alloc_security(struct sock *sk, int family,
 gfp_t gfp_flags, bool check) {
   char *csp = smk_of_current();
   struct socket_smack *ssp;
 
 + if (check  sk-sk_security)
 + return 0;
 +
   ssp = kzalloc(sizeof(struct socket_smack), gfp_flags);
   if (ssp == NULL)
   return -ENOMEM;

In the case of Smack, when the kernel boolean is true I think the right 
solution is to use smack_net_ambient.

-- 
paul moore
www.paul-moore.com

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: NULL pointer dereference in selinux_ip_postroute_compat

[Paul Moore]

On Wednesday, August 08, 2012 04:51:56 PM Eric Paris wrote:
 On Wed, Aug 8, 2012 at 4:35 PM, Paul Moore p...@paul-moore.com wrote:
  On Wednesday, August 08, 2012 10:09:38 PM Eric Dumazet wrote:
  
  Actually, the issue is that the shared socket doesn't have an init/alloc
  function to do the LSM allocation like we do with other sockets so Eric's
  patch does it as part of ip_send_unicast_reply().
  
  If we look at the relevant part of Eric's patch:
   +#ifdef CONFIG_SECURITY
   +   if (!sk-sk_security  security_sk_alloc(sk, PF_INET,
   GFP_ATOMIC))
   +   goto out;
   +#endif
  
  ... if we were to remove the CONFIG_SECURITY conditional we would end up
  calling security_sk_alloc() each time through in the CONFIG_SECURITY=n
  case as sk-sk_security would never be initialized to a non-NULL value. 
  In the CONFIG_SECURITY=y case it should only be called once as
  security_sk_alloc() should set sk-sk_security to a LSM blob.
 
 Ifndef SECURITY this turns into (because security_sk_alloc is a static
 inline in that case)
 
 if (!sk-sk_security  0)
 goto out;
 
 Which I'd hope the compiler would optimize.  So that only leaves us
 caring about the case there CONFIG_SECURITY is true.  In that case if
 we need code which does if !alloc'd then alloc it seems we broke the
 model of everything else in the code and added a branch needlessly.
 
 Could we add a __init function which does the security_sk_alloc() in
 the same file where we declared them?

Is it safe to call security_sk_alloc() from inside another __init function?  I 
think in both the case of SELinux and Smack it shouldn't be a problem, but I'm 
concerned about the more general case of calling a LSM hook potentially before 
the LSM has been initialized.

If that isn't an issue we could probably do something in ip_init().

  The issue I'm struggling with at present is how should we handle this
  traffic from a LSM perspective.  The label based LSMs, e.g. SELinux and
  Smack, use the LSM blob assigned to locally generated outbound traffic to
  identify the traffic and apply the security policy, so not only do we
  have to resolve the issue of ensuring the traffic is labeled correctly,
  we have to do it with a shared socket (although the patch didn't change
  the shared nature of the socket).
  
  For those who are interested, I think the reasonable labeling solution
  here is to go with SECINITSID_KERNEL/kernel_t for SELinux and likely the
  ambient label for Smack as in both the TCP reset and timewait ACK there
  shouldn't be any actual user data present.
 
 I'm willing to accept that argument from an SELinux perspective.  I'd
 also accept the argument that it is private and do something similar
 to what we do with IS_PRIVATE on inodes.  Although sockets probably
 don't have a good field to use...

I'm not aware of one.  See my comments on Eric's last patch posting (the other 
Eric, not you).

-- 
paul moore
www.paul-moore.com

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: NULL pointer dereference in selinux_ip_postroute_compat

[Paul Moore]

On Wednesday, August 08, 2012 05:00:26 PM Casey Schaufler wrote:
 On 8/8/2012 2:54 PM, Eric Dumazet wrote:

 By the way, once this proved to be an issue that involved
 more than just SELinux it needed to go onto the LSM list as
 well.

Yes, you're right.

  On Wed, 2012-08-08 at 16:46 -0400, Paul Moore wrote:
  On Wednesday, August 08, 2012 10:32:52 PM Eric Dumazet wrote:
  On Wed, 2012-08-08 at 22:09 +0200, Eric Dumazet wrote:
  +static int smack_sk_alloc_security(struct sock *sk, int ...
   {
char *csp = smk_of_current();
struct socket_smack *ssp;
  
  + if (check  sk-sk_security)
  + return 0;
  +
  
ssp = kzalloc(sizeof(struct socket_smack), gfp_flags);
if (ssp == NULL)

return -ENOMEM;
  
  In the case of Smack, when the kernel boolean is true I think the right
  solution is to use smack_net_ambient.
 
 I confess that my understanding of unicast is limited.
 If the intention is to send an unlabeled packet then
 indeed smack_net_ambient is the way to go.

Well, the intention isn't necessarily to send an unlabeled packet, although 
that may be the end result.

In the case of a TCP reset the kernel/ambient label it is hard to argue that 
the kernel/ambient label is not the correct solution; in this case there was 
never an associated socket so the kernel itself needs to respond.

In the case of a TCP syn-recv and timewait ACK things are a little less clear.  
Eric (Dumazet), it looks like we have a socket in tcp_v4_reqsk_send_ack() and 
tcp_v4_timewait_ack(), any reason why we can't propagate the socket down to 
ip_send_unicast_reply()?

-- 
paul moore
www.paul-moore.com

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: NULL pointer dereference in selinux_ip_postroute_compat

[Paul Moore]

On Thu, Aug 9, 2012 at 10:27 AM, Eric Dumazet eric.duma...@gmail.com wrote:
 On Thu, 2012-08-09 at 09:30 -0400, Paul Moore wrote:

 In the case of a TCP syn-recv and timewait ACK things are a little less 
 clear.
 Eric (Dumazet), it looks like we have a socket in tcp_v4_reqsk_send_ack() and
 tcp_v4_timewait_ack(), any reason why we can't propagate the socket down to
 ip_send_unicast_reply()?


 timewait 'sockets' are not full blown sockets.

 We need a socket (well, a good part of it) to build the IP frame and
 send it.

Yes, of course you're right.

Ideally we need a better solution here from a LSM perspective, but I
don't think this should hold up the fix as the labeling was broken
even before the postroute_compat() code broke.

-- 
paul moore
www.paul-moore.com
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] ipv4: tcp: security_sk_alloc() needed for unicast_sock

[Paul Moore]

On Thursday, August 09, 2012 04:50:33 PM Eric Dumazet wrote:
 From: Eric Dumazet eduma...@google.com
 
 commit be9f4a44e7d41cee (ipv4: tcp: remove per net tcp_sock) added a
 selinux regression, reported and bisected by John Stultz
 
 selinux_ip_postroute_compat() expect to find a valid sk-sk_security
 pointer, but this field is NULL for unicast_sock
 
 Fix this by adding a new 'kernel' parameter to security_sk_alloc(),
 set to true if socket might already have a valid sk-sk_security
 pointer. ip_send_unicast_reply() uses a percpu fake socket, so the first
 call to security_sk_alloc() will populate sk-sk_security pointer,
 subsequent ones will reuse existing context.
 
 Reported-by: John Stultz johns...@us.ibm.com
 Bisected-by: John Stultz johns...@us.ibm.com
 Signed-off-by: Eric Dumazet eduma...@google.com
 Cc: Paul Moore p...@paul-moore.com
 Cc: Eric Paris epa...@parisplace.org
 Cc: Serge E. Hallyn se...@hallyn.com

...

 diff --git a/net/ipv4/ip_output.c b/net/ipv4/ip_output.c
 index 76dde25..b233d6e 100644
 --- a/net/ipv4/ip_output.c
 +++ b/net/ipv4/ip_output.c
 @@ -1524,6 +1524,8 @@ void ip_send_unicast_reply(struct net *net, struct
 sk_buff *skb, __be32 daddr, sk-sk_priority = skb-priority;
   sk-sk_protocol = ip_hdr(skb)-protocol;
   sk-sk_bound_dev_if = arg-bound_dev_if;
 + if (security_sk_alloc(sk, PF_INET, GFP_ATOMIC, true))
 + goto out;
   sock_net_set(sk, net);
   __skb_queue_head_init(sk-sk_write_queue);
   sk-sk_sndbuf = sysctl_wmem_default;

Is is possible to do the call to security_sk_alloc() in the ip_init() function 
or does the per-cpu nature of the socket make this a pain?

-- 
paul moore
www.paul-moore.com

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] ipv4: tcp: security_sk_alloc() needed for unicast_sock

[Paul Moore]

On Thu, Aug 9, 2012 at 11:36 AM, Eric Dumazet eric.duma...@gmail.com wrote:
 On Thu, 2012-08-09 at 11:07 -0400, Paul Moore wrote:

 Is is possible to do the call to security_sk_alloc() in the ip_init() 
 function
 or does the per-cpu nature of the socket make this a pain?


 Its a pain, if we want NUMA affinity.

 Here, each cpu should get memory from its closest node.

Okay, makes sense.

Acked-by: Paul Moore p...@paul-moore.com

-- 
paul moore
www.paul-moore.com
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] ipv4: tcp: security_sk_alloc() needed for unicast_sock

[Paul Moore]

On Thu, Aug 9, 2012 at 12:05 PM, Eric Paris epa...@parisplace.org wrote:
 Paul, are you looking into this?  This is a bandaide, not a fix

Yep, I mentioned this a few times in the other thread.  The problem is
there is not going to be an easy fix for the labeling so I'd rather we
see this patch, or something like it, go in now to resolve the kernel
panic, and fix the labeling later.

-- 
paul moore
www.paul-moore.com
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] ipv4: tcp: security_sk_alloc() needed for unicast_sock

[Paul Moore]

On Thu, Aug 9, 2012 at 4:06 PM, Eric Paris epa...@parisplace.org wrote:
 I'm going to work right now on exposing the equivalent struct sock LSM
 interface so we can call that as well.  But it's going to take me a
 bit.

Before you go too far down this path, can you elaborate on what
exactly you mean by the above?

I'm asking because I'm not convinced the labeling, either the old way
or the new way, was 100% correct and I think we're going to need to
change things regardless.  I'm just not sure what the right solution
is just yet.

-- 
paul moore
www.paul-moore.com
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Fix sel_netnode_insert suspicious rcu dereference.

[Paul Moore]

On Mon, Aug 6, 2012 at 12:49 PM, Dave Jones da...@redhat.com wrote:
 On Tue, Jun 05, 2012 at 01:12:39AM -0400, Dave Jones wrote:
   I reported this a year ago (https://lkml.org/lkml/2011/4/20/308).
   It's still a problem apparently ...

 And another two months pass in silence.

 This is happening to other people too.
 https://bugzilla.redhat.com/show_bug.cgi?id=846037

 Can someone please apply this patch, or at least point out what's wrong with 
 it ?

I thought Eric had applied it a few months ago, but I just checked and
I don't see it in Linus' tree for some reason?  I know multiple
patches have been posted from different authors, all fixing the same
thing ...

Acked-by: Paul Moore p...@paul-moore.com

-- 
paul moore
www.paul-moore.com
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: + smack-unlabeled-outgoing-ambient-packets.patch added to -mm tree

[Paul Moore]

On Thursday 07 February 2008 3:04:59 pm Andrew Morton wrote:
 On Thu, 7 Feb 2008 14:50:41 -0500

 Paul Moore [EMAIL PROTECTED] wrote:
  On Thursday 07 February 2008 2:02:06 pm [EMAIL PROTECTED] wrote:
   The patch titled
Smack: unlabeled outgoing ambient packets
   has been added to the -mm tree.  Its filename is
smack-unlabeled-outgoing-ambient-packets.patch
  
   Before you just go and hit reply, please:
  a) Consider who else should be cc'ed
  b) Prefer to cc a suitable mailing list as well
  c) Ideally: find the original patch on the mailing list and do a
 reply-to-all to that, adding suitable additional cc's
 
  I didn't see this patch hit any of the relevant mailing lists (am I
  missing one somewhere?) so I'm just CC'ing everyone on the To/CC line,
  minus mm-commits.

 It was on linux-kernel and netdev.  I've restored those cc's.

My apologies, those mailing list postings there haven't hit my inbox yet.

-- 
paul moore
linux security @ hp
--
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/

Re: + smack-unlabeled-outgoing-ambient-packets.patch added to -mm tree

[Paul Moore]

On Thursday 07 February 2008 8:34:02 pm David Miller wrote:
 From: Paul Moore [EMAIL PROTECTED]
 Date: Thu, 7 Feb 2008 15:14:34 -0500

  My apologies, those mailing list postings there haven't hit my inbox yet.

 I had to remove you a few days ago, see my other reply to
 Andrew.

 You are back on the lists now, so I hope that bounce problem
 has been solved.

Yeah, that discussion with Andrew made me look a bit deeper at my mail folders 
and I realized the last message I received from any of the vger.kernel.org 
mailing lists was late Tuesday night ... I thought Wednesday was awfully 
quiet :/

I have no idea what was causing the mail problem, probably somebody in our IT 
department playing around with some new knobs, oh well.  I resubscribed this 
afternoon with both fingers crossed.

-- 
paul moore
linux security @ hp
--
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/

Re: + smack-unlabeled-outgoing-ambient-packets.patch added to -mm tree

[Paul Moore]

On Thursday 07 February 2008 9:15:19 pm David Miller wrote:
 From: Paul Moore [EMAIL PROTECTED]
 Date: Thu, 7 Feb 2008 20:54:56 -0500

  I have no idea what was causing the mail problem, probably somebody
  in our IT department playing around with some new knobs, oh well.  I
  resubscribed this afternoon with both fingers crossed.

 In the future please contact [EMAIL PROTECTED] when you
 notice you have been unsubscribed so we can work on fixing the
 issue.

 Blind resubscriptions are severely frowned upon, we remove you for
 good reason and if the problem isn't solved you'll just soil up my
 inbox further with bounces

Both points noted for future reference.  While the end result is the same, I 
can promise you my actions are not maliciously stupid, just ignorantly 
stupid ;)

-- 
paul moore
linux security @ hp
--
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/

Re: + smack-unlabeled-outgoing-ambient-packets.patch added to -mm tree

[Paul Moore]

   --
   Subject: Smack: unlabeled outgoing ambient packets
   From: Casey Schaufler [EMAIL PROTECTED]
  
   Smack uses CIPSO labeling, but allows for unlabeled packets by
   specifying an ambient label that is applied to incoming
   unlabeled packets.  Because the other end of the connection may
   dislike IP options, and ssh is one know application that behaves
   thus ...

I forgot to mention this earlier, but RHEL/Fedora/Rawhide has a patched 
version of SSH (see RH bugzilla #202856 for the discussion/patch) that 
fixes the problem of IPv4 options causing SSH to reject the connection.  
It turns out that SSH is being a bit overzealous (rejecting all IPv4 
options) in trying to reject source-routed packets.

-- 
paul moore
linux security @ hp
--
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/

Re: [2.6 patch] security/selinux/netlabel.c: fix double free

[Paul Moore]

On Monday 28 January 2008 5:09:38 pm Adrian Bunk wrote:
 This patch fixes a double free (security_netlbl_sid_to_secattr()
 already calls netlbl_secattr_destroy() when it returns !0) introduced
 by commit 45c950e0f839fded922ebc0bfd59b1081cc71b70 and spotted by the
 Coverity checker.

Hi Adrian,

Thanks for finding this mistake, however, I'd rather see it fixed by 
removing the netlbl_secattr_destroy() call in 
security_netlbl_sid_to_secattr() as it really shouldn't be there 
anymore.  We moved the matching _init() call into 
selinux_netlbl_sock_setsid() and I'd like to see the _init() and 
_destroy() calls done in the same function.  I can push a revised patch 
for this if you would prefer, otherwise I'll be happy to ack an updated 
version ...

 Signed-off-by: Adrian Bunk [EMAIL PROTECTED]

 ---
 --- linux-2.6/security/selinux/netlabel.c.old 2008-01-23
 00:38:19.0 +0200 +++
 linux-2.6/security/selinux/netlabel.c 2008-01-23 00:39:09.0
 +0200 @@ -58,22 +58,22 @@ static int selinux_netlbl_sock_setsid(st rc
 = security_netlbl_sid_to_secattr(sid, secattr);
   if (rc != 0)
   goto sock_setsid_return;
   rc = netlbl_sock_setattr(sk, secattr);
   if (rc == 0) {
   spin_lock_bh(sksec-nlbl_lock);
   sksec-nlbl_state = NLBL_LABELED;
   spin_unlock_bh(sksec-nlbl_lock);
   }

 -sock_setsid_return:
   netlbl_secattr_destroy(secattr);
 +sock_setsid_return:
   return rc;
  }

  /**
   * selinux_netlbl_cache_invalidate - Invalidate the NetLabel cache
   *
   * Description:
   * Invalidate the NetLabel security attribute mapping cache.
   *
   */



-- 
paul moore
linux security @ hp
--
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/

Re: [2.6 patch] security/selinux/netlabel.c: fix double free

[Paul Moore]

On Monday 28 January 2008 5:35:40 pm Adrian Bunk wrote:
 On Mon, Jan 28, 2008 at 05:23:46PM -0500, Paul Moore wrote:
  Thanks for finding this mistake, however, I'd rather see it fixed
  by removing the netlbl_secattr_destroy() call in
  security_netlbl_sid_to_secattr() as it really shouldn't be there
  anymore.  We moved the matching _init() call into
  selinux_netlbl_sock_setsid() and I'd like to see the _init() and
  _destroy() calls done in the same function.  I can push a revised
  patch for this if you would prefer, otherwise I'll be happy to ack
  an updated version ...

 doing the patch is trivial but you are able to write a better
 changelog for it - just push a revised patch.

Will do, thanks.

-- 
paul moore
linux security @ hp
--
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/

[PATCH] SELinux: Fix double free in selinux_netlbl_sock_setsid()

[Paul Moore]

As pointed out by Adrian Bunk, commit 45c950e0f839fded922ebc0bfd59b1081cc71b70
caused a double-free when security_netlbl_sid_to_secattr() fails.  This patch
fixes this by removing the netlbl_secattr_destroy() call from that function
since we are already releasing the secattr memory in
selinux_netlbl_sock_setsid().

Signed-off-by: Paul Moore [EMAIL PROTECTED]
---

 security/selinux/ss/services.c |1 -
 1 files changed, 0 insertions(+), 1 deletions(-)

diff --git a/security/selinux/ss/services.c b/security/selinux/ss/services.c
index 4bf715d..3a16aba 100644
--- a/security/selinux/ss/services.c
+++ b/security/selinux/ss/services.c
@@ -2629,7 +2629,6 @@ int security_netlbl_sid_to_secattr(u32 sid, struct 
netlbl_lsm_secattr *secattr)
 
 netlbl_sid_to_secattr_failure:
POLICY_RDUNLOCK;
-   netlbl_secattr_destroy(secattr);
return rc;
 }
 #endif /* CONFIG_NETLABEL */

--
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/

Re: [PATCH] SELinux: Fix double free in selinux_netlbl_sock_setsid()

[Paul Moore]

On Monday 28 January 2008 10:51:24 pm David Miller wrote:
 From: Paul Moore [EMAIL PROTECTED]
 Date: Mon, 28 Jan 2008 21:20:26 -0500

  As pointed out by Adrian Bunk, commit
  45c950e0f839fded922ebc0bfd59b1081cc71b70 caused a double-free when
  security_netlbl_sid_to_secattr() fails.  This patch fixes this by
  removing the netlbl_secattr_destroy() call from that function since we
  are already releasing the secattr memory in
  selinux_netlbl_sock_setsid().
 
  Signed-off-by: Paul Moore [EMAIL PROTECTED]

 Applied, and I'll queue this up for -stable too.

Thanks.  Sorry for not catching this in the first place.

 Please, when mentioning specific commits please also provide
 the changelog headline along with the SHA1 hash.

 The reason is that when this fix is moved over to another
 tree where the SHA1 of the causing change is different people
 studying your fix won't be able to find it without more stable
 contextual information.

Noted, I'll make sure to include the patch description in the future.  I 
wasn't aware that the hash took into account anything other than the 
individual commit it represented.  However, now that I think about it, since 
order is so critical it only makes sense to have the hash take into account 
at least the previous commit.

-- 
paul moore
linux security @ hp
--
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/

Re: [PATCH 08/26] Add a secctx_to_secid() LSM hook to go along with the existing

[Paul Moore]

On Tuesday 15 January 2008 8:05:27 pm James Morris wrote:
 On Tue, 15 Jan 2008, David Howells wrote:
  secid_to_secctx() LSM hook.  This patch also includes the SELinux
  implementation for this hook.
 
  Signed-off-by: Paul Moore [EMAIL PROTECTED]
  Acked-by: Stephen Smalley [EMAIL PROTECTED]

 This is useful in its own right, and I would like to push it upstream for
 2.6.24 unless there are any objections.

Isn't it a bit late in 2.6.24 to add new functionality, especially when there 
isn't an in-tree user for it in 2.6.24?

You are right, there are several users of this function currently under 
development but I'm pretty sure all of them are targeting 2.6.25 or greater.  
With that in mind, I think the prudent thing to is to wait and push this 
upstream for 2.6.25.

-- 
paul moore
linux security @ hp
--
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/

Re: [PATCH 08/26] Add a secctx_to_secid() LSM hook to go along with the existing

[Paul Moore]

On Wednesday 16 January 2008 5:13:53 pm James Morris wrote:
 On Wed, 16 Jan 2008, Paul Moore wrote:
  On Tuesday 15 January 2008 8:05:27 pm James Morris wrote:
   On Tue, 15 Jan 2008, David Howells wrote:
secid_to_secctx() LSM hook.  This patch also includes the SELinux
implementation for this hook.
   
Signed-off-by: Paul Moore [EMAIL PROTECTED]
Acked-by: Stephen Smalley [EMAIL PROTECTED]
  
   This is useful in its own right, and I would like to push it upstream
   for 2.6.24 unless there are any objections.
 
  Isn't it a bit late in 2.6.24 to add new functionality, especially when
  there isn't an in-tree user for it in 2.6.24?

 Actually, I meant to go into 2.6.24 after the merge window opens.

I'm assuming you meant 2.6.25 in the sentence above?

-- 
paul moore
linux security @ hp
--
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/

Re: [PATCH] (2.6.24-rc8-mm1) -mm v2 Smack socket label setting fix

[Paul Moore]

On Saturday 19 January 2008 6:04:52 pm Casey Schaufler wrote:
 From: Casey Schaufler [EMAIL PROTECTED]

 Correct the checks in smack_inode_setxattr to include the
 socket labeling attributes. Simplify and correct
 smack_sock_graft, while the values it was setting were
 safe they were not correct and the job was not being
 done efficiently. smack_inode_setsecurity wasn't
 invoking the required netlabel function in the case
 where smk_ipout was set. It does now, but that change
 required the hook to be moved in the file. This
 movement accounts for the bulk of the patch.


 Signed-off-by: Casey Schaufler [EMAIL PROTECTED]

...

 +/**
   * smack_socket_post_create - finish socket setup
   * @sock: the socket
   * @family: protocol family
 @@ -2192,33 +2199,20 @@ static int smack_socket_getpeersec_dgram
  static void smack_sock_graft(struct sock *sk, struct socket *parent)
  {
   struct socket_smack *ssp;
 - struct netlbl_lsm_secattr secattr;
 - char smack[SMK_LABELLEN];
   int rc;

I don't think you need 'rc'.

 - if (sk == NULL || parent == NULL || parent-sk == NULL)
 + if (sk == NULL)
   return;

I'm pretty sure you don't need to check 'sk' to ensure it is non-NULL; 
SELinux assumes 'sk' is non-NULL and it hasn't caused any problems.

   if (sk-sk_family != PF_INET  sk-sk_family != PF_INET6)
   return;

 - ssp = parent-sk-sk_security;
 -
 - memset(smack, '\0', SMK_LABELLEN);
 - netlbl_secattr_init(secattr);
 - rc = netlbl_sock_getattr(sk, secattr);
 - if (rc == 0)
 - smack_from_secattr(secattr, smack);
 - else
 - strncpy(smack, smack_known_huh.smk_known, SMK_MAXLEN);
 - netlbl_secattr_destroy(secattr);
 -
 - netlbl_secattr_init(secattr);
 + ssp = sk-sk_security;
 + ssp-smk_in = current-security;
 + ssp-smk_out = current-security;
 + ssp-smk_packet[0] = '\0';

 - smack_to_secattr(smack, secattr);
 - if (secattr.flags != NETLBL_SECATTR_NONE)
 - rc = netlbl_sock_setattr(parent-sk, secattr);
 - netlbl_secattr_destroy(secattr);
 + rc = smack_netlabel(sk);

I haven't checked the latest SMACK bits, but I'm pretty sure you don't 
need to assign the return value of 'smack_netlabel()' to anything here 
since the function doesn't return a value.

  }

  /**



-- 
paul moore
linux security @ hp
--
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/

Re: [PATCH] (02/14/08 Linus git) Smack unlabeled outgoing ambient packets - v3

[Paul Moore]

On Friday 15 February 2008 12:38:49 am Casey Schaufler wrote:
 From: Casey Schaufler [EMAIL PROTECTED]

 Smack uses CIPSO labeling, but allows for unlabeled packets
 by specifying an ambient label that is applied to incoming
 unlabeled packets. Because the other end of the connection
 may dislike IP options, and ssh is one know application that
 behaves thus, it is prudent to respond in kind. This patch
 changes the network labeling behavior such that an outgoing
 packet that would be given a CIPSO label that matches the
 ambient label is left unlabeled. An unlbl domain is added
 and the netlabel defaulting mechanism invoked rather than
 assuming that everything is CIPSO. Locking has been added
 around changes to the ambient label as the mechanisms used
 to do so are more involved.

 Cleaned up some issues noted in review.
 Make smk_cipso_doi() static.
 Create a hook for the new security_secctx_to_secid()
 using existing underlying code.
 Fill in audit data for netlbl domain calls.
 Collapse unnecessary multiple assignments.

 Signed-off-by: Casey Schaufler [EMAIL PROTECTED]

Hi Casey,

Thanks for the update, it's much improved.  I'd ack it except for one 
last thing which popped up in this revision ... (and don't worry, it's 
kinda my fault - not yours) ...

 @@ -1282,15 +1281,21 @@ static int smack_netlabel(struct sock *s
  {
   struct socket_smack *ssp;
   struct netlbl_lsm_secattr secattr;
 - int rc = 0;
 + int rc;

   ssp = sk-sk_security;
   netlbl_secattr_init(secattr);
   smack_to_secattr(ssp-smk_out, secattr);
 - if (secattr.flags != NETLBL_SECATTR_NONE)
 - rc = netlbl_sock_setattr(sk, secattr);
 -
 + rc = netlbl_sock_setattr(sk, secattr);
   netlbl_secattr_destroy(secattr);
 +
 + /*
 +  * A return of -ENOENT from netlbl_sock_setattr
 +  * indicates that the domain was not found, but that's
 +  * not an issue because of the defaulting behavior.
 +  */
 + if (rc == -ENOENT)
 + rc = 0;
   return rc;
  }

... you shouldn't fix-up the return value from netlbl_sock_setattr().  
It only returns an error when there really is an error, if there are no 
matching domain mappings and the default catches the domain then the 
function will return 0 (assuming no other failures).

The fact that you ran into this problem isn't your fault, it's mine, but 
thankfully for both of us Pavel Emelyanov found this bug and fixed 
it[1].  It hasn't hit Linus' tree yet but it's in the net-2.6 tree.  If 
you can't wait for it to hit Linus' tree you can always apply the fix 
by hand, it's pretty minor.

Sorry about that.

[1]http://git.kernel.org/?p=linux/kernel/git/davem/net-2.6.git;a=commit;h=4c3a0a254e5d706d3fe01bf42261534858d05586

-- 
paul moore
linux security @ hp
--
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/

Re: [PATCH] (02/14/08 Linus git) Smack unlabeled outgoing ambient packets - v3

[Paul Moore]

On Friday 15 February 2008 4:00:26 pm Casey Schaufler wrote:
 --- Paul Moore [EMAIL PROTECTED] wrote:
  On Friday 15 February 2008 12:38:49 am Casey Schaufler wrote:
   From: Casey Schaufler [EMAIL PROTECTED]
  
   Smack uses CIPSO labeling, but allows for unlabeled packets
   by specifying an ambient label that is applied to incoming
   unlabeled packets. Because the other end of the connection
   may dislike IP options, and ssh is one know application that
   behaves thus, it is prudent to respond in kind. This patch
   changes the network labeling behavior such that an outgoing
   packet that would be given a CIPSO label that matches the
   ambient label is left unlabeled. An unlbl domain is added
   and the netlabel defaulting mechanism invoked rather than
   assuming that everything is CIPSO. Locking has been added
   around changes to the ambient label as the mechanisms used
   to do so are more involved.
  
   Cleaned up some issues noted in review.
   Make smk_cipso_doi() static.
   Create a hook for the new security_secctx_to_secid()
   using existing underlying code.
   Fill in audit data for netlbl domain calls.
   Collapse unnecessary multiple assignments.
  
   Signed-off-by: Casey Schaufler [EMAIL PROTECTED]
 
  Hi Casey,
 
  Thanks for the update, it's much improved.  I'd ack it except for
  one last thing which popped up in this revision ... (and don't
  worry, it's kinda my fault - not yours) ...
 
   @@ -1282,15 +1281,21 @@ static int smack_netlabel(struct sock *s
{
 struct socket_smack *ssp;
 struct netlbl_lsm_secattr secattr;
   - int rc = 0;
   + int rc;
  
 ssp = sk-sk_security;
 netlbl_secattr_init(secattr);
 smack_to_secattr(ssp-smk_out, secattr);
   - if (secattr.flags != NETLBL_SECATTR_NONE)
   - rc = netlbl_sock_setattr(sk, secattr);
   -
   + rc = netlbl_sock_setattr(sk, secattr);
 netlbl_secattr_destroy(secattr);
   +
   + /*
   +  * A return of -ENOENT from netlbl_sock_setattr
   +  * indicates that the domain was not found, but that's
   +  * not an issue because of the defaulting behavior.
   +  */
   + if (rc == -ENOENT)
   + rc = 0;
 return rc;
}
 
  ... you shouldn't fix-up the return value from
  netlbl_sock_setattr(). It only returns an error when there really
  is an error, if there are no matching domain mappings and the
  default catches the domain then the function will return 0
  (assuming no other failures).
 
  The fact that you ran into this problem isn't your fault, it's
  mine, but thankfully for both of us Pavel Emelyanov found this bug
  and fixed it[1].  It hasn't hit Linus' tree yet but it's in the
  net-2.6 tree.  If you can't wait for it to hit Linus' tree you can
  always apply the fix by hand, it's pretty minor.
 
  Sorry about that.

 [1]http://git.kernel.org/?p=linux/kernel/git/davem/net-2.6.git;a=comm
it;h=4c3a0a254e5d706d3fe01bf42261534858d05586

 Yerk. I can put that fix into my tree, but my patch without
 the correction makes sockets behave very badly. I can't have
 people using it without Pavel's fix. Any notion on the plans to
 get that in?

FYI, it looks like Linus just tagged -rc2 and it does have the fix you 
need.

-- 
paul moore
linux security @ hp
--
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/

Re: [PATCH] (02/14/08 Linus git) Smack unlabeled outgoing ambient packets - v3

[Paul Moore]

On Friday 15 February 2008 4:00:26 pm Casey Schaufler wrote:
 --- Paul Moore [EMAIL PROTECTED] wrote:
  On Friday 15 February 2008 12:38:49 am Casey Schaufler wrote:
  ... you shouldn't fix-up the return value from
  netlbl_sock_setattr(). It only returns an error when there really
  is an error, if there are no matching domain mappings and the
  default catches the domain then the function will return 0
  (assuming no other failures).
 
  The fact that you ran into this problem isn't your fault, it's
  mine, but thankfully for both of us Pavel Emelyanov found this bug
  and fixed it[1].  It hasn't hit Linus' tree yet but it's in the
  net-2.6 tree.  If you can't wait for it to hit Linus' tree you can
  always apply the fix by hand, it's pretty minor.
 
  Sorry about that.

 [1]http://git.kernel.org/?p=linux/kernel/git/davem/net-2.6.git;a=comm
it;h=4c3a0a254e5d706d3fe01bf42261534858d05586

 Yerk. I can put that fix into my tree, but my patch without
 the correction makes sockets behave very badly. I can't have
 people using it without Pavel's fix. Any notion on the plans to
 get that in?

It is already in, it just hasn't percolated up to Linus' tree yet.  In 
the past I've always dealt with similar issues by just waiting until 
the patch I need has hit Linus' tree then submitted my patch.  If you 
can't wait, you can always rebase your patch against the net-2.6 tree 
(should be no work at all) and if DaveM doesn't have a problem pulling 
your patch into the net-2.6 tree you can always send it up that way.

-- 
paul moore
linux security @ hp
--
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/

Re: [PATCH] (02/15/08 Linus git) Smack unlabeled outgoing ambient packets - v4

[Paul Moore]

On Friday 15 February 2008 6:24:25 pm Casey Schaufler wrote:
 From: Casey Schaufler [EMAIL PROTECTED]

 Smack uses CIPSO labeling, but allows for unlabeled packets
 by specifying an ambient label that is applied to incoming
 unlabeled packets. Because the other end of the connection
 may dislike IP options, and ssh is one know application that
 behaves thus, it is prudent to respond in kind. This patch
 changes the network labeling behavior such that an outgoing
 packet that would be given a CIPSO label that matches the
 ambient label is left unlabeled. An unlbl domain is added
 and the netlabel defaulting mechanism invoked rather than
 assuming that everything is CIPSO. Locking has been added
 around changes to the ambient label as the mechanisms used
 to do so are more involved.

 Cleaned up some issues noted in review.
 Make smk_cipso_doi() static.
 Create a hook for the new security_secctx_to_secid()
 using existing underlying code.
 Fill in audit data for netlbl domain calls.
 Collapse unnecessary multiple assignments.

 Signed-off-by: Casey Schaufler [EMAIL PROTECTED]

Looks good to me, thanks for making those changes.

Acked-by: Paul Moore [EMAIL PROTECTED]

 ---

  security/smack/smack_lsm.c |   36 
  security/smack/smackfs.c   |   61 ++-
  2 files changed, 74 insertions(+), 23 deletions(-)

 diff -uprN -X linux-2.6.25-g0215-base//Documentation/dontdiff
 linux-2.6.25-g0215-base/security/smack/smackfs.c
 linux-2.6.25-g0215/security/smack/smackfs.c ---
 linux-2.6.25-g0215-base/security/smack/smackfs.c  2008-02-15
 14:25:37.0 -0800 +++
 linux-2.6.25-g0215/security/smack/smackfs.c   2008-02-15 14:30:36.0
 -0800 @@ -24,6 +24,7 @@
  #include net/cipso_ipv4.h
  #include linux/seq_file.h
  #include linux/ctype.h
 +#include linux/audit.h
  #include smack.h

  /*
 @@ -45,6 +46,7 @@ enum smk_inos {
   */
  static DEFINE_MUTEX(smack_list_lock);
  static DEFINE_MUTEX(smack_cipso_lock);
 +static DEFINE_MUTEX(smack_ambient_lock);

  /*
   * This is the ambient label for network traffic.
 @@ -342,6 +344,9 @@ void smk_cipso_doi(void)
   struct cipso_v4_doi *doip;
   struct netlbl_audit audit_info;

 + audit_info.loginuid = audit_get_loginuid(current);
 + audit_info.secid = smack_to_secid(current-security);
 +
   rc = netlbl_cfg_map_del(NULL, audit_info);
   if (rc != 0)
   printk(KERN_WARNING %s:%d remove rc = %d\n,
 @@ -363,6 +368,30 @@ void smk_cipso_doi(void)
  __func__, __LINE__, rc);
  }

 +/**
 + * smk_unlbl_ambient - initialize the unlabeled domain
 + */
 +void smk_unlbl_ambient(char *oldambient)
 +{
 + int rc;
 + struct netlbl_audit audit_info;
 +
 + audit_info.loginuid = audit_get_loginuid(current);
 + audit_info.secid = smack_to_secid(current-security);
 +
 + if (oldambient != NULL) {
 + rc = netlbl_cfg_map_del(oldambient, audit_info);
 + if (rc != 0)
 + printk(KERN_WARNING %s:%d remove rc = %d\n,
 +__func__, __LINE__, rc);
 + }
 +
 + rc = netlbl_cfg_unlbl_add_map(smack_net_ambient, audit_info);
 + if (rc != 0)
 + printk(KERN_WARNING %s:%d add rc = %d\n,
 +__func__, __LINE__, rc);
 +}
 +
  /*
   * Seq_file read operations for /smack/cipso
   */
 @@ -709,7 +738,6 @@ static ssize_t smk_read_ambient(struct f
   size_t cn, loff_t *ppos)
  {
   ssize_t rc;
 - char out[SMK_LABELLEN];
   int asize;

   if (*ppos != 0)
 @@ -717,23 +745,18 @@ static ssize_t smk_read_ambient(struct f
   /*
* Being careful to avoid a problem in the case where
* smack_net_ambient gets changed in midstream.
 -  * Since smack_net_ambient is always set with a value
 -  * from the label list, including initially, and those
 -  * never get freed, the worst case is that the pointer
 -  * gets changed just after this strncpy, in which case
 -  * the value passed up is incorrect. Locking around
 -  * smack_net_ambient wouldn't be any better than this
 -  * copy scheme as by the time the caller got to look
 -  * at the ambient value it would have cleared the lock
 -  * and been changed.
*/
 - strncpy(out, smack_net_ambient, SMK_LABELLEN);
 - asize = strlen(out) + 1;
 + mutex_lock(smack_ambient_lock);

 - if (cn  asize)
 - return -EINVAL;
 + asize = strlen(smack_net_ambient) + 1;
 +
 + if (cn = asize)
 + rc = simple_read_from_buffer(buf, cn, ppos,
 +  smack_net_ambient, asize);
 + else
 + rc = -EINVAL;

 - rc = simple_read_from_buffer(buf, cn, ppos, out, asize);
 + mutex_unlock(smack_ambient_lock);

   return rc;
  }
 @@ -751,6 +774,7 @@ static ssize_t smk_write_ambient(struct
size_t count, loff_t *ppos)
  {
   char

Re: [2.6 patch] make smackfs.c:smk_unlbl_ambient() static

[Paul Moore]

On Friday 22 February 2008 2:58:07 pm Adrian Bunk wrote:
 This patch makes the needlessly global smk_unlbl_ambient() static.

 Signed-off-by: Adrian Bunk [EMAIL PROTECTED]

Fine with me.

Acked-by: Paul Moore [EMAIL PROTECTED]

 ---
 60c7072cb922cdecdb8a4f08e5710c014e0e8a8c diff --git
 a/security/smack/smackfs.c b/security/smack/smackfs.c index
 358c92c..7c6e671 100644
 --- a/security/smack/smackfs.c
 +++ b/security/smack/smackfs.c
 @@ -371,7 +371,7 @@ void smk_cipso_doi(void)
  /**
   * smk_unlbl_ambient - initialize the unlabeled domain
   */
 -void smk_unlbl_ambient(char *oldambient)
 +static void smk_unlbl_ambient(char *oldambient)
  {
   int rc;
   struct netlbl_audit audit_info;



-- 
paul moore
linux security @ hp
--
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/

Re: [PATCH net-next 04/15] security: Add Linux Security Modules hook for AF_BUS sockets

[Paul Moore]

On Friday, June 29, 2012 05:45:43 PM Vincent Sanders wrote:
 From: Javier Martinez Canillas javier.marti...@collabora.co.uk
 
 AF_BUS implements a security hook bus_connect() to be used by LSM to
 enforce connectivity security policies.
 
 Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
 Signed-off-by: Vincent Sanders vincent.sand...@collabora.co.uk

In future postings, please reorder the patchset so that this patch (and the 
LSM specific patches) are applied after the actual AF_BUS implementation 
(patch 08/15 in this patchset).  This makes it easier to quickly understand 
how the LSM hooks/implementation interacts with the AF_BUS code.

A good rule of thumb that I try to follow when submitting large patchsets is 
that each patch should contain code that won't be optimized away during the 
build because there is no caller.  Sometimes that isn't possible without 
making things overly awkward, but in this particular case it shouldn't cause a 
problem.

 ---
  include/linux/security.h |   11 +++
  security/capability.c|7 +++
  security/security.c  |7 +++
  3 files changed, 25 insertions(+)
 
 diff --git a/include/linux/security.h b/include/linux/security.h
 index 4e5a73c..d30dc4a 100644
 --- a/include/linux/security.h
 +++ b/include/linux/security.h

...

 +static inline int security_bus_connect(struct socket *sock,
 +struct sock *other,
 +struct sock *newsk)
 +{
 + return 0;
 +}
 +

Other than the AF_UNIX specific name, is there a reason why you chose not to 
reuse the unix_stream_connect() LSM hook?  The arguments are the same, and 
based on an initial quick review of the SELinux hook implementations they 
appear to do almost identical things; the permissions are different but it 
should be trivial to make that conditional on the parent socket's address 
family (SELinux does similar things with other socket operations).  Looking at 
the Smack implementation, I don't think it would be a problem there either 
(CC'd Casey for his thoughts).

I'm still reviewing the rest of the AF_BUS patches but wanted to ask this now 
in case I was missing something.

-- 
paul moore
www.paul-moore.com

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH net-next 05/15] security: selinux: Add AF_BUS socket SELinux hooks

[Paul Moore]

On Friday, June 29, 2012 05:45:44 PM Vincent Sanders wrote:
 From: Javier Martinez Canillas javier.marti...@collabora.co.uk
 
 Add Security-Enhanced Linux (SELinux) hook for AF_BUS socket address family.
 
 Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
 Signed-off-by: Vincent Sanders vincent.sand...@collabora.co.uk

It would be very helpful to include a description of how the access controls 
would work.

From looking at the other patches, it would appear that when a new socket 
tries to connect to the AF_BUS bus it is checked against the security label of 
the bus master, yes?  Further, if no bus master is present, the connect() is 
denied at the AF_BUS level in the bus_connect() function, yes?

Have you considered the socket_getpeersec_dgram() hook?  Since AF_BUS does not 
appear to be stream oriented I think you can safely ignore 
socket_getpeersec_stream().

Have you considered the unix_may_send() hook?  Ignoring the AF_UNIX specific 
name, it seems like a reasonable hook for AF_BUS; unless you don't expect to 
have any read-only AF_BUS clients in which case the connect() hook should be 
enough (it would implicitly grant read/write access to each socket in that 
case).

Finally, as others have said, you need to ensure that you CC the LSM and 
SELinux lists on the relevant patches as well as provide LSM hook 
implementations for LSMs other than SELinux where it makes sense (not all LSMs 
will require implementations for the new hooks). 

 ---
  security/selinux/hooks.c |   35 +++
  1 file changed, 35 insertions(+)
 
 diff --git a/security/selinux/hooks.c b/security/selinux/hooks.c
 index 4ee6f23..5bacbe2 100644
 --- a/security/selinux/hooks.c
 +++ b/security/selinux/hooks.c
 @@ -67,6 +67,7 @@
  #include linux/quota.h
  #include linux/un.h/* for Unix socket types */
  #include net/af_unix.h /* for Unix socket types */
 +#include net/af_bus.h  /* for Bus socket types */
  #include linux/parser.h
  #include linux/nfs_mount.h
  #include net/ipv6.h
 @@ -4101,6 +4102,39 @@ static int selinux_socket_unix_may_send(struct socket
 *sock, ad);
  }
 
 +static int selinux_socket_bus_connect(struct sock *sock, struct sock
 *other, +   struct sock *newsk)
 +{
 + struct sk_security_struct *sksec_sock = sock-sk_security;
 + struct sk_security_struct *sksec_other = other-sk_security;
 + struct sk_security_struct *sksec_new = newsk-sk_security;
 + struct common_audit_data ad;
 + struct lsm_network_audit net = {0,};
 + int err;
 +
 + ad.type = LSM_AUDIT_DATA_NET;
 + ad.u.net = net;
 + ad.u.net-sk = other;
 +
 + err = avc_has_perm(sksec_sock-sid, sksec_other-sid,
 +sksec_other-sclass,
 +UNIX_STREAM_SOCKET__CONNECTTO, ad);

See my earlier comments about the similarities between this new hook and the 
existing AF_UNIX hook.  The fact that you are reusing the 
UNIX_STREAM_SOCKET__CONNECTTO permission (which is likely a no-no BTW) only 
reinforces the similarities between the two.

 + if (err)
 + return err;
 +
 + /* server child socket */
 + sksec_new-peer_sid = sksec_sock-sid;
 + err = security_sid_mls_copy(sksec_other-sid, sksec_sock-sid,
 + sksec_new-sid);
 + if (err)
 + return err;
 +
 + /* connecting socket */
 + sksec_sock-peer_sid = sksec_new-sid;
 +
 + return 0;
 +}
 +
  static int selinux_inet_sys_rcv_skb(int ifindex, char *addrp, u16 family,
   u32 peer_sid,
   struct common_audit_data *ad)
 @@ -5643,6 +5677,7 @@ static struct security_operations selinux_ops = {
 
   .unix_stream_connect =  selinux_socket_unix_stream_connect,
   .unix_may_send =selinux_socket_unix_may_send,
 + .bus_connect =  selinux_socket_bus_connect,
 
   .socket_create =selinux_socket_create,
   .socket_post_create =   selinux_socket_post_create,

-- 
paul moore
www.paul-moore.com

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 1/3] seccomp: Add SECCOMP_RET_INFO return value

[Paul Moore]

On Wednesday, December 19, 2012 09:56:13 AM Corey Bryant wrote:
 On 12/18/2012 05:22 PM, Will Drewry wrote:
  while others I've spoken with have been using the audit path to track
  denied values -- not so great for soft-failures :)
 
 The audit path would work too but if I understand I think you can only
 learn one syscall per execution.  The nice thing about SECCOMP_RET_INFO
 is that you can easily learn all the syscalls in one execution.

Another quick point about the audit log: on some systems, e.g. tightly secured 
SELinux systems, the audit log is only accessible via a very privileged user 
(Will hints at this below).  Normal users do not have access to, and therefore 
can't make use of, the seccomp related audit records.

  That aside, I worry that pr_info is the wrong place for a random user
  on the machine to log to for this, but I may be wrong, rather than a
  dedicated ringbufffer, etc.  So if this is for a user with privs, then
  a SECCOMP_RET_AUDIT might make sense.  Feedback to a local user seems
  tricky in general. I don't know :)  I just decided to deal with it in
  userland even if it is slightly painful.
 
 That's a good point.  I don't know which option is better either so if
 anyone else could weigh in on the better approach I'd appreciate it.

I agree with Will's statement about better to deal with the problem in 
userspace when possible, but as Corey pointed out, our experiences with QEMU 
have demonstrated that dealing with the problem exclusively in userspace just 
isn't practical in every case.

Syslog might not be the answer, but RET_TRAP and the audit log aren't very 
good answers either.

-- 
paul moore
security and virtualization @ redhat

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] tuntap: fix ambigious multiqueue API

[Paul Moore]

On Friday, December 14, 2012 05:53:30 PM Jason Wang wrote:
 The current multiqueue API is ambigious which may confuse both user and LSM
 to do things correctly:
 
 - Both TUNSETIFF and TUNSETQUEUE could be used to create the queues of a
 tuntap device.
 - TUNSETQUEUE were used to disable and enable a specific queue of the
   device. But since the state of tuntap were completely removed from the
 queue, it could be used to attach to another device (there's no such kind
 of requirement currently, and it needs new kind of LSM policy.
 - TUNSETQUEUE could be used to attach to a persistent device without any
   queues. This kind of attching bypass the necessary checking during
 TUNSETIFF and may lead unexpected result.
 
 So this patch tries to make a cleaner and simpler API by:
 
 - Only allow TUNSETIFF to create queues.
 - TUNSETQUEUE could be only used to disable and enabled the queues of a
 device, and the state of the tuntap device were not detachd from the queues
 when it was disabled, so TUNSETQUEUE could be only used after TUNSETIFF and
 with the same device.
 
 This is done by introducing a list which keeps track of all queues which
 were disabled. The queue would be moved between this list and tfiles[]
 array when it was enabled/disabled. A pointer of the tun_struct were also
 introdued to track the device it belongs to when it was disabled.
 
 After the change, the isolation between management and application could be
 done through: TUNSETIFF were only called by management software and
 TUNSETQUEUE were only called by application.For LSM/SELinux, the things
 left is to do proper check during tun_set_queue() if needed.
 
 Signed-off-by: Jason Wang jasow...@redhat.com

Let me digest these changes and I'll respin the LSM/SELinux multiqueue fixes 
and send them back out for re-discussion/review.

-- 
paul moore
security and virtualization @ redhat

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v2 1/3] seccomp: Add SECCOMP_RET_INFO return value

[Paul Moore]

On Monday, January 07, 2013 12:09:03 PM Corey Bryant wrote:
 Adds a new return value to seccomp filters that causes an
 informational kernel message to be printed.  The message
 includes the system call number and architecture.
 
 This can be used to learn the system calls that a process
 is using.
 
 Signed-off-by: Corey Bryant cor...@linux.vnet.ibm.com

Were do things currently stand with this patchset?  It still seems like a 
reasonable addition to me.

-- 
paul moore
security and virtualization @ redhat

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [GIT] SELinux changes for 2.6.23 (updated)

[Paul Moore]

-Original Message-
From: James Morris [EMAIL PROTECTED]
Date: Thursday, Jul 12, 2007 10:50 pm
Subject: Re: [GIT] SELinux changes for 2.6.23 (updated)
To: Michal Piotrowski [EMAIL PROTECTED]
CC: Linus Torvalds [EMAIL PROTECTED], linux-kernel@vger.kernel.org, Stephen 
Smalley [EMAIL PROTECTED],  Paul Moore [EMAIL PROTECTED]

On Fri, 13 Jul 2007, Michal Piotrowski wrote:

 
 My system is too secure, I can not login :)

Do you have CONFIG_NETLABEL=y ?

If so, please try disabling it.

Disabling NetLabel should solve the problem.  The recommended solution to this 
problem, as discussed on the SELinux list and mentioned in the patch 
description, is to upgrade your SELinux policy to the latest Reference Policy 
sources.  For those with custom SELinux policy, the patch description explains 
the changes to the SELinux policy required. 

If needed I can post more instructions later, let me know, but right now I'm 
tapping this out on my phone while at the airport.

. paul moore
. linux security @ hp


-
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/

Re: [bug] very high non-preempt latency in context_struct_compute_av()

[Paul Moore]

On Monday, June 4 2007 7:27:45 am Ingo Molnar wrote:
 a simple ssh login triggers a ~130 msecs non-preemptible latency even
 with CONFIG_PREEMPT enabled, on a fast Core2Duo CPU (!).

 the latency is caused by a _very_ long loop in the SELinux code:

 sshd-4828  0.N.. 465894us : avtab_search_node
 (context_struct_compute_av) sshd-4828  0.N.. 465895us : cond_compute_av
 (context_struct_compute_av) sshd-4828  0.N.. 465895us : avtab_search_node
 (cond_compute_av) sshd-4828  0.N.. 465895us : avtab_search_node
 (context_struct_compute_av) sshd-4828  0.N.. 465896us : cond_compute_av
 (context_struct_compute_av) sshd-4828  0.N.. 465896us : avtab_search_node
 (cond_compute_av) sshd-4828  0.N.. 465896us : avtab_search_node
 (context_struct_compute_av) sshd-4828  0.N.. 465896us : cond_compute_av
 (context_struct_compute_av) sshd-4828  0.N.. 465896us : avtab_search_node
 (cond_compute_av)

 it is triggered like this:

 sshd-4828  0..s. 462986us : tasklet_action (__do_softirq)
 sshd-4828  0..s. 462986us : rcu_process_callbacks (tasklet_action)
 sshd-4828  0..s. 462986us : __rcu_process_callbacks
 (rcu_process_callbacks) sshd-4828  0..s. 462987us : __rcu_process_callbacks
 (rcu_process_callbacks) sshd-4828  0D.s. 462987us : _local_bh_enable
 (__do_softirq)
 sshd-4828  0DN.. 462987us : idle_cpu (irq_exit)
 sshd-4828  0.N.. 462988us : avtab_search_node
 (context_struct_compute_av) sshd-4828  0.N.. 462989us : cond_compute_av
 (context_struct_compute_av)

 {snip}

 The distribution is Fedora 7, v2.6.21 (but also happens in recent -git)
 and a simple 'ssh localhost' login is enough to trigger this. It
 triggers every time and this is causing audio skipping in certain apps.
 It is even visible in glxgears smoothness: a small 'bump' is visible in
 the otherwise smooth rotation of glxgears. Enabling CONFIG_PREEMPT does
 not fix this issue as the function runs under spinlocks. (enabling
 CONFIG_PREEMPT_RT in -rt fixes the issue - but that still leaves us with
 the huge 130 msecs cost of that function.)

I'm not an expert on the SELinux security server guts like the other people on 
the To/CC line of this thread, but here are my two cents on the issue above.

From what I can tell the nasty loop that is taking so long is the actual 
access vector lookup which determines if the subject has access to the object 
(i.e. can user/application X access resource Y on the system).  While it may 
be possible to optimize this code I wonder if a quicker/easier solution would 
be to refactor the lock.  At present SELinux uses a read/write spinlock to 
protect the policy stored in the kernel with macros to take and release the 
lock, POLICY_{RD,WR}LOCK and POLICY_{RD,WR}UNLOCK.  From personal 
observations as well as a quick check of the code, it appears that most of 
the time we only want to read lock the policy and not write lock the policy - 
a spinlock, even a read/write spinlock, seems a bit expensive here.

If we were to convert from a read/write spinlock to a RCU locking mechanism 
would this solve the preemption problem (I'm not a lock expert either)?  If 
so, can anyone think of any reasons why converting the policy lock to RCU is 
a bad idea (James, Stephen, the other James)?

-- 
paul moore
linux security @ hp
-
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/

Re: [bug] very high non-preempt latency in context_struct_compute_av()

[Paul Moore]

On Monday 04 June 2007 5:39:00 pm Stephen Smalley wrote:
 On Mon, 2007-06-04 at 17:11 -0400, Paul Moore wrote:
  I'm not an expert on the SELinux security server guts like the other
  people on the To/CC line of this thread, but here are my two cents on the
  issue above.
 
  From what I can tell the nasty loop that is taking so long is the actual
  access vector lookup which determines if the subject has access to the
  object (i.e. can user/application X access resource Y on the system). 
  While it may be possible to optimize this code I wonder if a
  quicker/easier solution would be to refactor the lock.  At present
  SELinux uses a read/write spinlock to protect the policy stored in the
  kernel with macros to take and release the lock, POLICY_{RD,WR}LOCK and
  POLICY_{RD,WR}UNLOCK.  From personal observations as well as a quick
  check of the code, it appears that most of the time we only want to read
  lock the policy and not write lock the policy - a spinlock, even a
  read/write spinlock, seems a bit expensive here.
 
  If we were to convert from a read/write spinlock to a RCU locking
  mechanism would this solve the preemption problem (I'm not a lock expert
  either)?  If so, can anyone think of any reasons why converting the
  policy lock to RCU is a bad idea (James, Stephen, the other James)?

 rcu_read_lock disables preemption in mainline (see rcupdate.h).
 Conversion to RCU is also complicated by conditional policy support
 (changing of policy boolean states via selinuxfs).  However, there were
 experimental patches to do that a while ago by KaiGai Kohei.

Okay, for some reason I thought someone had found a way to make 
RCU preemptable through the real-time work, maybe I'm just confused 
again :)  Regardless, it looks like there are better solutions possible.

Thanks.

-- 
paul moore
linux security @ hp
-
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/

Re: The art of breaking userspace (was Re: [GIT] SELinux changes for 2.6.23 (updated))

[Paul Moore]

-Original Message-
From: Stephen Smalley [EMAIL PROTECTED]
Date: Friday, Jul 13, 2007 3:30 pm
Subject: Re: The art of breaking userspace (was Re: [GIT] SELinux changes   
for 2.6.23 (updated))
To: Michal Piotrowski [EMAIL PROTECTED]
CC: Paul Moore [EMAIL PROTECTED], [EMAIL PROTECTED],  [EMAIL PROTECTED], 
linux-kernel@vger.kernel.org

On Fri, 2007-07-13 at 21:08 +0200, Michal Piotrowski wrote:
 Paul Moore pisze:
 [..]
  On Fri, 13 Jul 2007, Michal Piotrowski wrote:
  My system is too secure, I can not login :)
 
  Do you have CONFIG_NETLABEL=y ?
 
  If so, please try disabling it.
  
  Disabling NetLabel should solve the problem.
 
 Disabling NetLabel solves the problem.
 
   The recommended solution to this problem, as discussed on the SELinux list 
  and mentioned in the patch description, is to upgrade your SELinux policy 
  to the latest Reference Policy sources.  For those with custom SELinux 
  policy, the patch description explains the changes to the SELinux policy 
  required. 
 
 I'm sorry to say this, but this kind of patches should not be accepted.
 
 Patch
 
 commit 9faf65fb6ee2b4e08325ba2d69e5ccf0c46453d0
 Author: Paul Moore [EMAIL PROTECTED]
 Date:   Fri Jun 29 11:48:16 2007 -0400
 
 SELinux: use SECINITSID_NETMSG instead of SECINITSID_UNLABELED for 
 NetLabel
 
 These changes will make NetLabel behave like labeled IPsec where there is 
 an
 access check for both labeled and unlabeled packets as well as providing 
 the
 ability to restrict domains to receiving only labeled packets when 
 NetLabel
 is in use.  The changes to the policy are straight forward with the
 following necessary to receive labeled traffic (with SECINITSID_NETMSG
 defined as netlabel_peer_t):
 
  allow mydom_t netlabel_peer_t:{ tcp_socket udp_socket rawip_socket } 
 recvfrom;
 
 The policy for unlabeled traffic would be:
 
  allow mydom_t unlabeled_t:{ tcp_socket udp_socket rawip_socket } 
 recvfrom;
 
 These policy changes, as well as more general NetLabel support, are 
 included
 in the SELinux Reference Policy SVN tree, r2352 or later.  Users who 
 enable
 NetLabel support in the kernel are strongly encouraged to upgrade their
 policy to avoid network problems.
 
 Signed-off-by: Paul Moore [EMAIL PROTECTED]
 Signed-off-by: James Morris [EMAIL PROTECTED]
 
 
 breaks systems with recent selinux policy.
 
 (rpm -qa selinux-policy-*
 selinux-policy-devel-2.6.4-25.fc7
 selinux-policy-targeted-2.6.4-25.fc7)
 
 I will add this as a regression unless Linus says Fsck it! We don't care 
 about compatibility

Agreed, it needs to be fixed in the netlabel code.

I'm stuck in the airport right now but I will send a patch out later tonight.

. paul moore
. linux security @ hp


-
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/

Re: The art of breaking userspace (was Re: [GIT] SELinux changes for 2.6.23 (updated))

[Paul Moore]

On Friday, July 13 2007 3:29:23 pm Stephen Smalley wrote:
 Agreed, it needs to be fixed in the netlabel code.

For anyone interested, and for the sake of completeness, an updated patch[set] 
has been posted to the SELinux mailing list for review.  The new patchset is 
designed to fix the problem that Michal reported.

-- 
paul moore
linux security @ hp
-
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/

Re: [PATCH 0/2] SELinux Netlabel updates

[Paul Moore]

On Tuesday 17 July 2007 8:24:55 pm Linus Torvalds wrote:
 On Tue, 17 Jul 2007, James Morris wrote:
  These are updated Netlabel/SELinux changes from Paul, reworked so that
  they don't break userspace.  Michal says they work for him.  Please apply
  for 2.6.23.

 They don't work AT ALL for me:

   security/selinux/ss/sidtab.o: In function `netlbl_enabled':
   sidtab.c:(.text+0x0): multiple definition of `netlbl_enabled'
   security/selinux/ss/ebitmap.o:ebitmap.c:(.text+0x0): first defined here

 Tssk.

 That dummy netlbl_enabled() should be static inline, methinks.

 Also, that net/netlabel.h file has two blocks after each other of

   #ifdef CONFIG_NETLABEL
   ..
   #else
   ..
   #endif

   #ifdef CONFIG_NETLABEL
   ..
   #else
   ..
   #endif

 which might as well be cleaned up at the same time (and might have avoided
 this bug, since then the people involved would have seen the _correct_
 example in the first version)

Oh my.  I'll fix this and get another version out to James and Michal tomorrow 
morning; I have to spend the rest of the night smacking myself in the 
forehead.

-- 
paul moore
linux security @ hp
-
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/

[PATCH v3 1/2] NetLabel: enable dynamic activation/deactivation of NetLabel/SELinux enforcement

[Paul Moore]

Create a new NetLabel KAPI interface, netlbl_enabled(), which reports on the
current runtime status of NetLabel based on the existing configuration.  LSMs
that make use of NetLabel, i.e. SELinux, can use this new function to determine
if they should perform NetLabel access checks.  This patch changes the
NetLabel/SELinux glue code such that SELinux only enforces NetLabel related
access checks when netlbl_enabled() returns true.

At present NetLabel is considered to be enabled when there is at least one
labeled protocol configuration present.  The result is that by default NetLabel
is considered to be disabled, however, as soon as an administrator configured
a CIPSO DOI definition NetLabel is enabled and SELinux starts enforcing
NetLabel related access controls - including unlabeled packet controls.

This patch also tries to consolidate the multiple #ifdef CONFIG_NETLABEL
blocks into a single block to ease future review as recommended by Linus.

Signed-off-by: Paul Moore [EMAIL PROTECTED]
---
 include/net/netlabel.h   |   62 -
 net/netlabel/netlabel_cipso_v4.c |5 +++
 net/netlabel/netlabel_kapi.c |   21 
 net/netlabel/netlabel_mgmt.c |   65 +++
 net/netlabel/netlabel_mgmt.h |5 +++
 security/selinux/netlabel.c  |8 
 6 files changed, 131 insertions(+), 35 deletions(-)

Index: linux-2.6_netmsg_3/include/net/netlabel.h
===
--- linux-2.6_netmsg_3.orig/include/net/netlabel.h
+++ linux-2.6_netmsg_3/include/net/netlabel.h
@@ -144,10 +144,9 @@ struct netlbl_lsm_secattr {
 };
 
 /*
- * LSM security attribute operations
+ * LSM security attribute operations (inline)
  */
 
-
 /**
  * netlbl_secattr_cache_alloc - Allocate and initialize a secattr cache
  * @flags: the memory allocation flags
@@ -283,6 +282,9 @@ static inline void netlbl_secattr_free(s
 }
 
 #ifdef CONFIG_NETLABEL
+/*
+ * LSM security attribute operations
+ */
 int netlbl_secattr_catmap_walk(struct netlbl_lsm_secattr_catmap *catmap,
   u32 offset);
 int netlbl_secattr_catmap_walk_rng(struct netlbl_lsm_secattr_catmap *catmap,
@@ -294,6 +296,25 @@ int netlbl_secattr_catmap_setrng(struct 
 u32 start,
 u32 end,
 gfp_t flags);
+
+/*
+ * LSM protocol operations
+ */
+int netlbl_enabled(void);
+int netlbl_sock_setattr(struct sock *sk,
+   const struct netlbl_lsm_secattr *secattr);
+int netlbl_sock_getattr(struct sock *sk,
+   struct netlbl_lsm_secattr *secattr);
+int netlbl_skbuff_getattr(const struct sk_buff *skb,
+ struct netlbl_lsm_secattr *secattr);
+void netlbl_skbuff_err(struct sk_buff *skb, int error);
+
+/*
+ * LSM label mapping cache operations
+ */
+void netlbl_cache_invalidate(void);
+int netlbl_cache_add(const struct sk_buff *skb,
+const struct netlbl_lsm_secattr *secattr);
 #else
 static inline int netlbl_secattr_catmap_walk(
  struct netlbl_lsm_secattr_catmap *catmap,
@@ -301,14 +322,12 @@ static inline int netlbl_secattr_catmap_
 {
return -ENOENT;
 }
-
 static inline int netlbl_secattr_catmap_walk_rng(
  struct netlbl_lsm_secattr_catmap *catmap,
  u32 offset)
 {
return -ENOENT;
 }
-
 static inline int netlbl_secattr_catmap_setbit(
  struct netlbl_lsm_secattr_catmap *catmap,
  u32 bit,
@@ -316,7 +335,6 @@ static inline int netlbl_secattr_catmap_
 {
return 0;
 }
-
 static inline int netlbl_secattr_catmap_setrng(
  struct netlbl_lsm_secattr_catmap *catmap,
  u32 start,
@@ -325,59 +343,33 @@ static inline int netlbl_secattr_catmap_
 {
return 0;
 }
-#endif
-
-/*
- * LSM protocol operations
- */
-
-#ifdef CONFIG_NETLABEL
-int netlbl_sock_setattr(struct sock *sk,
-   const struct netlbl_lsm_secattr *secattr);
-int netlbl_sock_getattr(struct sock *sk,
-   struct netlbl_lsm_secattr *secattr);
-int netlbl_skbuff_getattr(const struct sk_buff *skb,
- struct netlbl_lsm_secattr *secattr);
-void netlbl_skbuff_err(struct sk_buff *skb, int error);
-#else
+static inline int netlbl_enabled(void)
+{
+   return 0;
+}
 static inline int netlbl_sock_setattr(struct sock *sk,
 const struct netlbl_lsm_secattr *secattr)
 {
return -ENOSYS;
 }
-
 static inline int netlbl_sock_getattr(struct sock *sk,
  struct netlbl_lsm_secattr *secattr)
 {
return -ENOSYS;
 }
-
 static inline int netlbl_skbuff_getattr(const struct sk_buff *skb

[PATCH v3 0/2] The comedy of errors patchset (was: SELinux NetLabel updates)

[Paul Moore]

This rev of the patchset solves both the original problem that Michal posted
involving backwards compatibility with old SELinux policy as well as the
problem Linus posted about the fix not working correctly when CONFIG_NETLABEL
was not set.  I also tried to fixup the #ifdefs in include/net/netlabel.h as
suggested.

I've tested both of these patches, in order, and neither have caused problems
(i.e. there shouldn't be any git bisect breakage issues if only the first
patch is applied).  I've also compiled both patches with and without
CONFIG_NETLABEL and have not seen any problems.

Once again, thank you all for your patience.

-- 
paul moore
linux security @ hp
-
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/

[PATCH v3 2/2] SELinux: use SECINITSID_NETMSG instead of SECINITSID_UNLABELED for NetLabel

[Paul Moore]

These changes will make NetLabel behave like labeled IPsec where there is an
access check for both labeled and unlabeled packets as well as providing the
ability to restrict domains to receiving only labeled packets when NetLabel is
in use.  The changes to the policy are straight forward with the following
necessary to receive labeled traffic (with SECINITSID_NETMSG defined as
netlabel_peer_t):

 allow mydom_t netlabel_peer_t:{ tcp_socket udp_socket rawip_socket } recvfrom;

The policy for unlabeled traffic would be:

 allow mydom_t unlabeled_t:{ tcp_socket udp_socket rawip_socket } recvfrom;

These policy changes, as well as more general NetLabel support, are included in
the latest SELinux Reference Policy release 20070629 or later.  Users who make
use of NetLabel are strongly encouraged to upgrade their policy to avoid
network problems.  Users who do not make use of NetLabel will not notice any
difference.

Signed-off-by: Paul Moore [EMAIL PROTECTED]
---
 security/selinux/hooks.c|   21 +++--
 security/selinux/netlabel.c |   41 -
 2 files changed, 31 insertions(+), 31 deletions(-)

Index: linux-2.6_netmsg_3/security/selinux/hooks.c
===
--- linux-2.6_netmsg_3.orig/security/selinux/hooks.c
+++ linux-2.6_netmsg_3/security/selinux/hooks.c
@@ -3129,17 +3129,19 @@ static int selinux_parse_skb(struct sk_b
 /**
  * selinux_skb_extlbl_sid - Determine the external label of a packet
  * @skb: the packet
- * @base_sid: the SELinux SID to use as a context for MLS only external labels
  * @sid: the packet's SID
  *
  * Description:
  * Check the various different forms of external packet labeling and determine
- * the external SID for the packet.
+ * the external SID for the packet.  If only one form of external labeling is
+ * present then it is used, if both labeled IPsec and NetLabel labels are
+ * present then the SELinux type information is taken from the labeled IPsec
+ * SA and the MLS sensitivity label information is taken from the NetLabel
+ * security attributes.  This bit of magic is done in the call to
+ * selinux_netlbl_skbuff_getsid().
  *
  */
-static void selinux_skb_extlbl_sid(struct sk_buff *skb,
-  u32 base_sid,
-  u32 *sid)
+static void selinux_skb_extlbl_sid(struct sk_buff *skb, u32 *sid)
 {
u32 xfrm_sid;
u32 nlbl_sid;
@@ -3147,10 +3149,9 @@ static void selinux_skb_extlbl_sid(struc
selinux_skb_xfrm_sid(skb, xfrm_sid);
if (selinux_netlbl_skbuff_getsid(skb,
 (xfrm_sid == SECSID_NULL ?
- base_sid : xfrm_sid),
+ SECINITSID_NETMSG : xfrm_sid),
 nlbl_sid) != 0)
nlbl_sid = SECSID_NULL;
-
*sid = (nlbl_sid == SECSID_NULL ? xfrm_sid : nlbl_sid);
 }
 
@@ -3695,7 +3696,7 @@ static int selinux_socket_getpeersec_dgr
if (sock  sock-sk-sk_family == PF_UNIX)
selinux_get_inode_sid(SOCK_INODE(sock), peer_secid);
else if (skb)
-   selinux_skb_extlbl_sid(skb, SECINITSID_UNLABELED, peer_secid);
+   selinux_skb_extlbl_sid(skb, peer_secid);
 
if (peer_secid == SECSID_NULL)
err = -EINVAL;
@@ -3756,7 +3757,7 @@ static int selinux_inet_conn_request(str
u32 newsid;
u32 peersid;
 
-   selinux_skb_extlbl_sid(skb, SECINITSID_UNLABELED, peersid);
+   selinux_skb_extlbl_sid(skb, peersid);
if (peersid == SECSID_NULL) {
req-secid = sksec-sid;
req-peer_secid = SECSID_NULL;
@@ -3794,7 +3795,7 @@ static void selinux_inet_conn_establishe
 {
struct sk_security_struct *sksec = sk-sk_security;
 
-   selinux_skb_extlbl_sid(skb, SECINITSID_UNLABELED, sksec-peer_sid);
+   selinux_skb_extlbl_sid(skb, sksec-peer_sid);
 }
 
 static void selinux_req_classify_flow(const struct request_sock *req,
Index: linux-2.6_netmsg_3/security/selinux/netlabel.c
===
--- linux-2.6_netmsg_3.orig/security/selinux/netlabel.c
+++ linux-2.6_netmsg_3/security/selinux/netlabel.c
@@ -163,9 +163,7 @@ int selinux_netlbl_skbuff_getsid(struct 
netlbl_secattr_init(secattr);
rc = netlbl_skbuff_getattr(skb, secattr);
if (rc == 0  secattr.flags != NETLBL_SECATTR_NONE)
-   rc = security_netlbl_secattr_to_sid(secattr,
-   base_sid,
-   sid);
+   rc = security_netlbl_secattr_to_sid(secattr, base_sid, sid);
else
*sid = SECSID_NULL;
netlbl_secattr_destroy(secattr);
@@ -203,7 +201,7 @@ void selinux_netlbl_sock_graft(struct so
if (netlbl_sock_getattr(sk, secattr) == 0

Re: [Patch net-next v2 8/8] selinux: use generic union inet_addr

[Paul Moore]

On Friday, August 02, 2013 03:14:34 PM Cong Wang wrote:
 From: Cong Wang amw...@redhat.com
 
 selinux has some similar definition like union inet_addr,
 it can re-use the generic union inet_addr too.
 
 Cc: James Morris james.l.mor...@oracle.com
 Cc: Stephen Smalley s...@tycho.nsa.gov
 Cc: Eric Paris epa...@parisplace.org
 Cc: Paul Moore pmo...@redhat.com
 Cc: linux-kernel@vger.kernel.org
 Cc: linux-security-mod...@vger.kernel.org
 Signed-off-by: Cong Wang amw...@redhat.com

Perhaps I'm confusing this with another patch but I though DaveM said he 
wasn't going to merge these patches?

-- 
paul moore
security and virtualization @ redhat

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: linux-next: build failure after merge of the lblnet tree

[Paul Moore]

On Friday, July 26, 2013 02:06:17 PM Stephen Rothwell wrote:
 Hi Paul,
 
 After merging the lblnet tree, today's linux-next build (x86_64
 allmodconfig) failed like this:
 
 security/selinux/hooks.c: In function 'sb_finish_set_opts':
 security/selinux/hooks.c:448:19: error: 'SE_SBLABELSUPP' undeclared (first
 use in this function) sbsec-flags |= SE_SBLABELSUPP;
^
 Caused by commit 8cf9124a324f (SELinux: Enable setting security contexts
 on rootfs inodes) interacting with commit 12f348b9dcf6 (SELinux: rename
 SE_SBLABELSUPP to SBLABEL_MNT) from the selinux tree.
 
 This is not helped by the fact that there are a lot of commits in the
 lblnet tree (including 8cf9124a324f) that have been cherry-picked
 (instead of being merged) into the selinux tree.  :-(

The problem should be fixed now.

The issue was that I was temporarily holding a lot of these SELinux patches in 
the lblnet-next tree so they could get some linux-next exposure while Eric was 
busy an unable to update the SELinux tree.  Unfortunately, there was some 
miscommunication between Eric and I yesterday and the trees got a bit out of 
sync.  All the lblnet-next patches have now been included in the SELinux tree 
so I've pruned them from the lblnet-next tree.

Thanks for your understanding,
-Paul

-- 
paul moore
www.paul-moore.com

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v2 2/2] SELinux: Increase ebitmap_node size for 64-bit configuration

[Paul Moore]

On Wednesday, July 10, 2013 02:33:04 PM Stephen Smalley wrote:
 On 06/05/2013 05:15 PM, Waiman Long wrote:
  Currently, the ebitmap_node structure has a fixed size of 32 bytes. On
  a 32-bit system, the overhead is 8 bytes, leaving 24 bytes for being
  used as bitmaps. The overhead ratio is 1/4.
  
  On a 64-bit system, the overhead is 16 bytes. Therefore, only 16 bytes
  are left for bitmap purpose and the overhead ratio is 1/2. With a
  3.8.2 kernel, a boot-up operation will cause the ebitmap_get_bit()
  function to be called about 9 million times. The average number of
  ebitmap_node traversal is about 3.7.
  
  This patch increases the size of the ebitmap_node structure to 64
  bytes for 64-bit system to keep the overhead ratio at 1/4. This may
  also improve performance a little bit by making node to node traversal
  less frequent ( 2) as more bits are available in each node.
  
  Signed-off-by: Waiman Long waiman.l...@hp.com
 
 Acked-by:  Stephen Smalley s...@tycho.nsa.gov

Looks good to me too.  Merged, built, and tested okay too.

 * git://git.infradead.org/users/pcmoore/lblnet-2.6_next

  ---
  
security/selinux/ss/ebitmap.h |8 +++-
1 files changed, 7 insertions(+), 1 deletions(-)
  
  diff --git a/security/selinux/ss/ebitmap.h b/security/selinux/ss/ebitmap.h
  index e7eb3a9..712c8a7 100644
  --- a/security/selinux/ss/ebitmap.h
  +++ b/security/selinux/ss/ebitmap.h
  @@ -16,7 +16,13 @@
  
#include net/netlabel.h
  
  -#define EBITMAP_UNIT_NUMS  ((32 - sizeof(void *) - sizeof(u32))\
  +#ifdef CONFIG_64BIT
  +#defineEBITMAP_NODE_SIZE   64
  +#else
  +#defineEBITMAP_NODE_SIZE   32
  +#endif
  +
  +#define EBITMAP_UNIT_NUMS  ((EBITMAP_NODE_SIZE-sizeof(void
  *)-sizeof(u32))\
  
  / sizeof(unsigned long))

#define EBITMAP_UNIT_SIZE BITS_PER_LONG
#define EBITMAP_SIZE  (EBITMAP_UNIT_NUMS * EBITMAP_UNIT_SIZE)
 
 --
 To unsubscribe from this list: send the line unsubscribe
 linux-security-module in the body of a message to
 majord...@vger.kernel.org
 More majordomo info at  http://vger.kernel.org/majordomo-info.html
-- 
paul moore
www.paul-moore.com

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: linux-next: rebase of lblnet tree

[Paul Moore]

On Thursday, July 11, 2013 10:01:17 AM Stephen Rothwell wrote:
 Hi Paul,

Hi Stephen,

I know you already emailed me privately about my @hp.com email address, but 
for the sake of everyone else on the list, my @hp.com address no longer works, 
it hasn't for some time now.  Please check my entry in the MAINTAINERS file 
for my correct contact information (this email address).  That said, I 
established this current email address to avoid problems when changing 
employers so hopefully this confusion won't happen again in the future.

 Why have you just rebased the lblnet tree
 (git://git.infradead.org/users/pcmoore/lblnet-2.6_next#master)?  You have
 just invalidated your testing and made it likely that Linus will blast
 you if you ask him to pull your tree.  Your whole tree was already based
 after v3.10 (i.e. released or rebased after the merge window opened), so
 why move it again?

[NOTE: I get the impression that the above is a form letter email, but just 
in case ...]

When I added two additional patches to the labeled networking tree today, I 
rebased the tree to verify that there were no merge conflicts and that 
everything worked as expected on a booted system.  I also occasionally rebase 
the tree when there are pending patches and I'm not adding anything new for 
the same reason: I believe that testing changes against the latest upstream 
code is a Good Thing.  If there is a patch with my sign-off in a tree I am 
responsible for, I do my best to make sure it builds, boots, and passes some 
basic sanity tests.  I can't say I'm perfect, but I do try to not push crap 
upwards.

Also, just to be clear, the labeled networking tree usually goes into Linus' 
tree via the netdev or security tree (and then it hits the security tree 
usually via the SELinux tree).  I can't ever think of a time when I asked 
Linus' to pull a tree of mine directly.

If this approach doesn't work for you, please let me know and preferably 
suggest an alternative.

-Paul

-- 
paul moore
www.paul-moore.com

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v14 5/6] LSM: SO_PEERSEC configuration options

[Paul Moore]

On Thursday, July 25, 2013 11:32:23 AM Casey Schaufler wrote:
 Subject: [PATCH v14 5/6] LSM: SO_PEERSEC configuration options
 
 Refine the handling of SO_PEERSEC to enable legacy
 user space runtimes, Fedora in particular, when running
 with multiple LSMs that are capable of providing information
 using getsockopt(). This introduces an additional configuration
 option, and requires that the default be the legacy behavior.
 
 Signed-off-by: Casey Schaufler ca...@schaufler-ca.com

...

 --- a/security/Kconfig
 +++ b/security/Kconfig
 @@ -157,17 +157,49 @@ config SECMARK_LSM
   help
 The name of the LSM to use with the networking secmark
 
 -config SECURITY_PLAIN_CONTEXT
 - bool Backward compatable contexts without lsm='value' formatting
 - depends on SECURITY_SELINUX || SECURITY_SMACK
 - default y
 +choice
 + depends on SECURITY  (SECURITY_SELINUX || SECURITY_SMACK)
 + prompt Peersec LSM
 + default PEERSEC_SECURITY_FIRST
 +
   help
 -   Without this value set security context strings will
 -   include the name of the lsm with which they are associated
 -   even if there is only one LSM that uses security contexts.
 -   This matches the way contexts were handled before it was
 -   possible to have multiple concurrent security modules.
 -   If you are unsure how to answer this question, answer Y.
 +   Select the security module that will send attribute
 +   information in IP header options.
 +   Most SELinux configurations do not take advantage
 +   of Netlabel, while all Smack configurations do. Unless
 +   there is a need to do otherwise chose Smack in preference
 +   to SELinux.

I'm not hugely in love with the help text; the first sentence seems to be all 
that is needed, the second seems unnecessary and not exactly fair to the LSMs.

 + config PEERSEC_SECURITY_FIRST
 + bool First LSM providing for SO_PEERSEC
 + help
 +   Provide the first available LSM's information with SO_PEERSEC
 +
 + config PEERSEC_SECURITY_ALL
 + bool Use lsm='value'lsm='value' format
 + help
 +   Provide all available security information in SO_PEERSEC
 +
 + config PEERSEC_SECURITY_SELINUX
 + bool SELinux if SECURITY_SELINUX=y
 + help
 +   Provide SELinux context with SO_PEERSEC
 +
 + config PEERSEC_SECURITY_SMACK
 + bool Smack if SECURITY_SMACK=y
 + help
 +   Provide Smack labels with SO_PEERSEC
 +
 +endchoice
 +
 +config PEERSEC_LSM
 + string
 + default smack if PEERSEC_SECURITY_SMACK
 + default selinux if PEERSEC_SECURITY_SELINUX
 + default (all) if PEERSEC_SECURITY_ALL
 + default (first)
 + help
 +   The name of the LSM to use with Netlabel
 
  config SECURITY_PATH
   bool Security hooks for pathname based access control

-- 
paul moore
www.paul-moore.com

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v14 3/6] LSM: Explicit individual LSM associations

[Paul Moore]

 netlbl_lsm_secattr_catmap *catmap, * be disabled.
   *
   */
 -int netlbl_enabled(void)
 +int netlbl_enabled(struct security_operations *lsm)
  {
 + if (lsm_netlbl_ops() == NULL)
 + return 0;
 + if (lsm_netlbl_ops() != lsm)
 + return 0;

How about some simplification in the above?

struct security_operations *sops = lsm_netlbl_ops();

if (sops == NULL || sops != lsm)
return 0;

   /* At some point we probably want to expose this mechanism to the user
* as well so that admins can toggle NetLabel regardless of the
* configuration */

...

 diff --git a/net/netlabel/netlabel_unlabeled.c
 b/net/netlabel/netlabel_unlabeled.c index 3e9064a..be4e083 100644
 --- a/net/netlabel/netlabel_unlabeled.c
 +++ b/net/netlabel/netlabel_unlabeled.c
 @@ -263,7 +263,7 @@ static int netlbl_unlhsh_add_addr4(struct
 netlbl_unlhsh_iface *iface, entry-list.addr = addr-s_addr  mask-s_addr;
   entry-list.mask = mask-s_addr;
   entry-list.valid = 1;
 - lsm_init_secid(entry-secid, secid, 0);
 + lsm_init_secid(entry-secid, secid, lsm_netlbl_order());

See my above comments in the CIPSO code.

   spin_lock(netlbl_unlhsh_lock);
   ret_val = netlbl_af4list_add(entry-list, iface-addr4_list);
 @@ -307,7 +307,7 @@ static int netlbl_unlhsh_add_addr6(struct
 netlbl_unlhsh_iface *iface, entry-list.addr.s6_addr32[3] =
 mask-s6_addr32[3];
   entry-list.mask = *mask;
   entry-list.valid = 1;
 - lsm_init_secid(entry-secid, secid, 0);
 + lsm_init_secid(entry-secid, secid, lsm_netlbl_order());

Same.  You get the idea ...

-- 
paul moore
www.paul-moore.com

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v14 5/6] LSM: SO_PEERSEC configuration options

[Paul Moore]

On Wednesday, July 31, 2013 08:45:52 AM Casey Schaufler wrote:
 On 7/30/2013 2:47 PM, Paul Moore wrote:
  On Thursday, July 25, 2013 11:32:23 AM Casey Schaufler wrote:
  Subject: [PATCH v14 5/6] LSM: SO_PEERSEC configuration options
  
  Refine the handling of SO_PEERSEC to enable legacy
  user space runtimes, Fedora in particular, when running
  with multiple LSMs that are capable of providing information
  using getsockopt(). This introduces an additional configuration
  option, and requires that the default be the legacy behavior.
  
  Signed-off-by: Casey Schaufler ca...@schaufler-ca.com
  
  ...
  
  --- a/security/Kconfig
  +++ b/security/Kconfig
  @@ -157,17 +157,49 @@ config SECMARK_LSM
  
 help
 
   The name of the LSM to use with the networking secmark
  
  -config SECURITY_PLAIN_CONTEXT
  -  bool Backward compatable contexts without lsm='value' formatting
  -  depends on SECURITY_SELINUX || SECURITY_SMACK
  -  default y
  +choice
  +  depends on SECURITY  (SECURITY_SELINUX || SECURITY_SMACK)
  +  prompt Peersec LSM
  +  default PEERSEC_SECURITY_FIRST
  +
  
 help
  
  -Without this value set security context strings will
  -include the name of the lsm with which they are associated
  -even if there is only one LSM that uses security contexts.
  -This matches the way contexts were handled before it was
  -possible to have multiple concurrent security modules.
  -If you are unsure how to answer this question, answer Y.
  +Select the security module that will send attribute
  +information in IP header options.
  +Most SELinux configurations do not take advantage
  +of Netlabel, while all Smack configurations do. Unless
  +there is a need to do otherwise chose Smack in preference
  +to SELinux.
  
  I'm not hugely in love with the help text; the first sentence seems to be
  all that is needed, the second seems unnecessary and not exactly fair to
  the LSMs.

 I can take out the friendly advice. What it really should say
 is more on the lines of:
 
   If you have gotten to the point where you have to make
   this decision you should probably call it a work day, go
   home, have a nice drink and spend some time with a loved
   one. In the morning take a good hard look at your network
   configuration. You may end up with a different security
   policies being enforced with IPv4 and IPv6 communications.

Perfect ;)

-- 
paul moore
www.paul-moore.com

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v14 3/6] LSM: Explicit individual LSM associations

[Paul Moore]

On Wednesday, July 31, 2013 09:22:23 AM Casey Schaufler wrote:
 On 7/30/2013 3:08 PM, Paul Moore wrote:
  On Thursday, July 25, 2013 11:32:11 AM Casey Schaufler wrote:
  Subject: [PATCH v14 3/6] LSM: Explicit individual LSM associations
  
  Expand the /proc/.../attr interface set to help include
  LSM specific entries as well as the traditional shared
  current, prev and exec entries. Each LSM that uses
  one of the traditional interfaces gets it's own interface
  prefixed with the LSM name for the ones it cares about.
  Thus, we have smack.current, selinux.current and
  apparmor.current in addition to current.
  
  Add two new interfaces under /sys/kernel/security.
  The lsm interface displays the comma seperated list of
  active LSMs. The present interface displays the name
  of the LSM providing the traditional /proc/.../attr
  interfaces. User space code should no longer have to
  grub around in odd places to determine what LSM is
  being used and thus what data is available to it.
  
  Introduce feature specific security operation vectors
  for NetLabel, XFRM, secmark and presentation in the
  traditional /proc/.../attr interfaces. This allows
  proper handling of secids.
  
  Maybe I missed something, can you elaborate on this, perhaps even provide
  an example for us simple minded folk?
 
 There are a set of facilities that (currently, at least)
 can't be shared by multiple LSMs ...

I should have been more specific.

Thanks for the explanation, but that I understand the problems of stacking 
LSM/secids, we've had that conversation a few times now.  The explanation I 
was hoping for had to do with this sentence:

 Introduce feature specific security operation vectors for
  NetLabel, XFRM, secmark and presentation in the traditional
  /proc/.../attr interfaces.

Can you explain this a bit more?  When I looked at the patch - and maybe I'm 
missing something - I didn't see anything in /proc that dealt with NetLabel, 
XFRM, and/or Secmark.

  Add NetLabel interfaces that allow an LSM to request
  ownership of the NetLabel subsystem and to determine
  whether or not it has that ownership. These interfaces
  are intended to allow a future in which NetLabel can
  support multiple LSMs at the same time, although they
  do not do so now.
  
  Signed-off-by: Casey Schaufler ca...@schaufler-ca.com
  
  ...
  
  --- a/include/net/netlabel.h
  +++ b/include/net/netlabel.h
  @@ -407,7 +407,9 @@ int netlbl_secattr_catmap_setrng(struct
  netlbl_lsm_secattr_catmap *catmap, /*
  
* LSM protocol operations (NetLabel LSM/kernel API)
*/
  
  -int netlbl_enabled(void);
  +int netlbl_enabled(struct security_operations *lsm);
  +int netlbl_lsm_owner(struct security_operations *lsm);
  +int netlbl_lsm_register(struct security_operations *lsm);
  
   int netlbl_sock_setattr(struct sock *sk,
   
 u16 family,
 const struct netlbl_lsm_secattr *secattr);
  
  @@ -521,7 +523,11 @@ static inline int netlbl_secattr_catmap_setrng(
  
   {
   
 return 0;
   
   }
  
  -static inline int netlbl_enabled(void)
  +static inline int netlbl_lsm_register(struct security_operations *lsm)
  +{
  +  return 0;
  +}
  +static inline int netlbl_enabled(struct security_operations *lsm)
  
   {
   
 return 0;
   
   }
  
  Is it worth including a static inline for netlabel_lsm_owner() for the
  sake of completeness?  I haven't looked closely enough yet to know if it
  is strictly necessary or not.
 
 I don't think it ever comes up, which would imply we don't need
 netlbl_enabled(), either.

Probably not, but I like the safety of having it defined.  I guess that is why 
I would prefer having netlabel_lsm_owner() defined here as well.

  diff --git a/net/ipv4/cipso_ipv4.c b/net/ipv4/cipso_ipv4.c
  index 00a2b2b..5ca352b 100644
  --- a/net/ipv4/cipso_ipv4.c
  +++ b/net/ipv4/cipso_ipv4.c
  @@ -1594,7 +1594,7 @@ static int cipso_v4_parsetag_loc(const struct
  cipso_v4_doi *doi_def, u32 secid;
  
 secid = *(u32 *)tag[2];
  
  -  lsm_init_secid(secattr-attr.secid, secid, 0);
  +  lsm_init_secid(secattr-attr.secid, secid, lsm_netlbl_order());
  
 secattr-flags |= NETLBL_SECATTR_SECID;
  
  I still need to wrap my head around all the changes, but I *think* this
  change may not be necessary since NetLabel isn't multi-LSM aware at the
  moment.  If this change is necessary, then there are likely other changes
  that need to be made as well, the NetLabel LSM cache would be my main
  concern.
 
 Using the NetLabel secid slot is necessary because when we get into
 the auditing code the secid needs to be in the right place to associate
 it with the right LSM.

Fair enough.

-- 
paul moore
www.paul-moore.com

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v14 3/6] LSM: Explicit individual LSM associations

[Paul Moore]

On Wednesday, July 31, 2013 02:21:54 PM Casey Schaufler wrote:
 On 7/31/2013 12:39 PM, Paul Moore wrote:
  On Wednesday, July 31, 2013 09:22:23 AM Casey Schaufler wrote:
  On 7/30/2013 3:08 PM, Paul Moore wrote:
  On Thursday, July 25, 2013 11:32:11 AM Casey Schaufler wrote:
  Subject: [PATCH v14 3/6] LSM: Explicit individual LSM associations
  
  Expand the /proc/.../attr interface set to help include
  LSM specific entries as well as the traditional shared
  current, prev and exec entries. Each LSM that uses
  one of the traditional interfaces gets it's own interface
  prefixed with the LSM name for the ones it cares about.
  Thus, we have smack.current, selinux.current and
  apparmor.current in addition to current.
  
  Add two new interfaces under /sys/kernel/security.
  The lsm interface displays the comma seperated list of
  active LSMs. The present interface displays the name
  of the LSM providing the traditional /proc/.../attr
  interfaces. User space code should no longer have to
  grub around in odd places to determine what LSM is
  being used and thus what data is available to it.
  
  Introduce feature specific security operation vectors
  for NetLabel, XFRM, secmark and presentation in the
  traditional /proc/.../attr interfaces. This allows
  proper handling of secids.
  
  Maybe I missed something, can you elaborate on this, perhaps even
  provide an example for us simple minded folk?
  
  There are a set of facilities that (currently, at least)
  can't be shared by multiple LSMs ...
  
  I should have been more specific.
  
  Thanks for the explanation, but that I understand the problems of stacking
  LSM/secids, we've had that conversation a few times now.  The explanation
  I was hoping for had to do with this sentence:
 
   Introduce feature specific security operation vectors for
NetLabel, XFRM, secmark and presentation in the traditional
/proc/.../attr interfaces.
  
  Can you explain this a bit more?  When I looked at the patch - and maybe
  I'm missing something - I didn't see anything in /proc that dealt with
  NetLabel, XFRM, and/or Secmark.
 
 Just so. I have failed to communicate clearly.
 
   Each feature that requires support by a single, selected LSM
is identified by a global pointer to that LSM's security_operations
structure.
 
 NetLabel, XFRM and secmark are networking interfaces that can
 send the security information from a single LSM along with the
 packets of data.
 
 /proc/.../attr/current and SO_PEERSEC are interfaces that could
 send information from multiple LSMs, but in most cases you have
 to choose one LSM to placate your user space tools.
 
 In all of these cases it is necessary to identify the LSM to use.
 Even though the end use is quite different the mechanism to support
 the identification is the same.

Okay, so if I understand everything correctly, there are no new entries in 
/proc relating specifically to NetLabel, XFRM, or Secmark; although there are 
new LSM specific entries for the general /proc entries that exist now.  Yes?

-- 
paul moore
www.paul-moore.com

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v14 3/6] LSM: Explicit individual LSM associations

[Paul Moore]

On Thursday, August 01, 2013 11:52:14 AM Casey Schaufler wrote:
 On 8/1/2013 11:35 AM, Paul Moore wrote:
  Okay, so if I understand everything correctly, there are no new entries in
  /proc relating specifically to NetLabel, XFRM, or Secmark; although there
  are new LSM specific entries for the general /proc entries that exist
  now.  Yes?

 That's correct.
 
 There is /sys/kernel/security/present, which tells you which LSM is going to
 show up in /proc/.../attr/current.
 
 Should we have /sys/kernel/security/XFRM, /sys/kernel/security/secmark,
 /sys/kernel/security/NetLabel and /sys/kernel/security/SO_PEERCRED?

Maybe.

While they might be helpful, I'm not 100% certain they are needed and further 
I'm not sure they are the right solution at this point.  Any thoughts, both 
for and against, are welcome.

-- 
paul moore
www.paul-moore.com

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v14 3/6] LSM: Explicit individual LSM associations

[Paul Moore]

On Thursday, August 01, 2013 03:15:00 PM Casey Schaufler wrote:
 On 8/1/2013 2:30 PM, Paul Moore wrote:
  On Thursday, August 01, 2013 11:52:14 AM Casey Schaufler wrote:
  On 8/1/2013 11:35 AM, Paul Moore wrote:
  Okay, so if I understand everything correctly, there are no new entries
  in
  /proc relating specifically to NetLabel, XFRM, or Secmark; although
  there
  are new LSM specific entries for the general /proc entries that exist
  now.  Yes?
  
  That's correct.
  
  There is /sys/kernel/security/present, which tells you which LSM is going
  to show up in /proc/.../attr/current.
  
  Should we have /sys/kernel/security/XFRM, /sys/kernel/security/secmark,
  /sys/kernel/security/NetLabel and /sys/kernel/security/SO_PEERCRED?
  
  Maybe.
  
  While they might be helpful, I'm not 100% certain they are needed and
  further I'm not sure they are the right solution at this point.  Any
  thoughts, both for and against, are welcome.
 
 What might be a more correct solution? Assuming, of course, that there's
 a real problem.

Well, like I said, I'm not sure they are needed in the first place, in other 
words, I'm not sure there is a problem.  As for the correct solution, I think 
we need to understand the problem, if there is one, before we can understand 
the solution.

How is that for an answer? :)

In short, I think we are best leaving them out until something comes along 
which requires that we add the /proc entries.

-- 
paul moore
www.paul-moore.com

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: linux-next: error when fetching the selinux tree

[Paul Moore]

On Thursday, November 07, 2013 09:27:09 AM Stephen Rothwell wrote:
 Hi Paul,
 
 Fetching the selinux tree
 (git://git.infradead.org/users/pcmoore/selinux#master) produces this
 error:
 
 fatal: Couldn't find remote ref refs/heads/master

Sorry about that, a case of bad timing.  I'm doing some cleanup right now, it 
should be back up shortly.  That said, it should be empty today so no worries 
if you want to skip it today.

-Paul

-- 
paul moore
www.paul-moore.com

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/