[GIT] Security updates for 3.3: SELinux

[GIT] Security updates for 3.3: SELinux

[James Morris]

Hi Linus,

Due to a mixup, the SELinux tree wasn't merged into mine before the merge 
window, however, it has been in -next separately all along.

Please pull.

The following changes since commit 51be08419dc86c72486ac556aa39bc01026a403d:
  Linus Torvalds (1):
        Merge branch 'fbdev-next' of git://github.com/schandinat/linux-2.6

are available in the git repository at:

  git://selinuxproject.org/~jmorris/linux-security for-linus

David Howells (1):
      SELinux: Fix RCU deref check warning in sel_netport_insert()

Eric Paris (12):
      capabilities: remove the task from capable LSM hook entirely
      capabilities: reverse arguments to security_capable
      capabilities: introduce security_capable_noaudit
      capabilities: remove all _real_ interfaces
      capabilities: call has_ns_capability from has_capability
      capabilites: introduce new has_ns_capabilities_noaudit
      capabilities: style only - move capable below ns_capable
      capabitlies: ns_capable can use the cap helpers rather than lsm call
      capabilities: remove task_ns_* functions
      ptrace: do not audit capability check when outputing /proc/pid/stat
      security: remove the security_netlink_recv hook as it is equivalent to capable()
      capabilities: remove __cap_full_set definition

James Morris (7):
      selinux: sparse fix: make selinux_secmark_refcount static
      selinux: sparse fix: move selinux_complete_init
      selinux: sparse fix: declare selinux_disable() in security.h
      selinux: sparse fix: eliminate warnings for selinuxfs
      selinux: sparse fix: fix warnings in netlink code
      selinux: sparse fix: fix several warnings in the security server cod
      Merge branch 'eparis-master' into for-linus

 crypto/crypto_user.c            |    2 +-
 drivers/pci/pci-sysfs.c         |    2 +-
 drivers/scsi/scsi_netlink.c     |    2 +-
 fs/proc/array.c                 |    2 +-
 include/linux/capability.h      |    4 +-
 include/linux/cred.h            |    6 ++-
 include/linux/ptrace.h          |    5 +-
 include/linux/security.h        |   60 ++++++-----------------------
 kernel/audit.c                  |    4 +-
 kernel/capability.c             |   80 ++++++++++++++++++++++----------------
 kernel/ptrace.c                 |   14 +++++-
 kernel/sched/core.c             |    2 +-
 net/core/rtnetlink.c            |    2 +-
 net/decnet/netfilter/dn_rtmsg.c |    2 +-
 net/ipv4/netfilter/ip_queue.c   |    2 +-
 net/ipv6/netfilter/ip6_queue.c  |    2 +-
 net/netfilter/nfnetlink.c       |    2 +-
 net/netlink/genetlink.c         |    2 +-
 net/xfrm/xfrm_user.c            |    2 +-
 security/apparmor/lsm.c         |    8 ++--
 security/capability.c           |    1 -
 security/commoncap.c            |   24 +++--------
 security/security.c             |   35 ++--------------
 security/selinux/hooks.c        |   44 +++++----------------
 24 files changed, 120 insertions(+), 189 deletions(-)

Re: [GIT] Security updates for 3.3: SELinux

[Linus Torvalds]

On Sat, Jan 14, 2012 at 6:25 PM, James Morris <jmorris@namei.org> wrote:
>
>  git://selinuxproject.org/~jmorris/linux-security for-linus

Ugh. I dislike how you had an "evil merge" with no explanation about
*why* it was there. I just see the merge, and wonder what was going
on.

So I removed the merge, and tried it myself to see what the conflicts
were and what was going on. Because that's exactly the kind of thing I
do want to know about.

Please, if you do merges like this, please explain them. At the *very*
least, explain them in the merge message itself if you do them
yourself, but I actually prefer that you not do the merge at all, and
instead explain what is going on so that I can see it and react to it.

Now, if it's a trivial merge, it needs no explanation (although I also
prefer that it not be done, so that I can see even those), but
something like this where you actually need to resolve a semantic
conflict that doesn't cause any real physical conflict at all I really
prefer to be explained.

                         Linus

Re: [GIT] Security updates for 3.3: SELinux

[James Morris]

On Sat, 14 Jan 2012, Linus Torvalds wrote:

> Now, if it's a trivial merge, it needs no explanation (although I also
> prefer that it not be done, so that I can see even those), but
> something like this where you actually need to resolve a semantic
> conflict that doesn't cause any real physical conflict at all I really
> prefer to be explained.

Sorry, yep, I should have explained it.

It was an odd situation in that it hadn't been in my tree at all thus far, 
so I wanted to do my own testing before requesting a pull to your tree.



- James
-- 
James Morris
<jmorris@namei.org>

Re: [GIT] Security updates for 3.3: SELinux

[J. R. Okajima]

James Morris:
> Eric Paris (12):
	:::
>       capabitlies: ns_capable can use the cap helpers rather than lsm call

After this commit, I am afraid access(2) on NFS may not work correctly.
The scenario based upon my guess.
- access(2) overrides the credentials.
- calls inode_permission() -- ... -- generic_permission() --
  ns_capable().
- while the old ns_capable() calls security_capable(current_cred()), the
  new ns_capable() calls has_ns_capability(current) --
  security_capable(__task_cred(t)).

current_cred() returns current->cred which is effective (overridden)
credentials, but __task_cred(current) returns current->real_cred (the
NFSD's credential). And the overridden credentials by access(2) lost.

Is my guess correct?


J. R. Okajima

Re: [GIT] Security updates for 3.3: SELinux

[Eric Paris]

On Tue, 2012-01-17 at 23:28 +0900, J. R. Okajima wrote:
> James Morris:
> > Eric Paris (12):
> 	:::
> >       capabitlies: ns_capable can use the cap helpers rather than lsm call
> 
> After this commit, I am afraid access(2) on NFS may not work correctly.
> The scenario based upon my guess.
> - access(2) overrides the credentials.
> - calls inode_permission() -- ... -- generic_permission() --
>   ns_capable().
> - while the old ns_capable() calls security_capable(current_cred()), the
>   new ns_capable() calls has_ns_capability(current) --
>   security_capable(__task_cred(t)).
> 
> current_cred() returns current->cred which is effective (overridden)
> credentials, but __task_cred(current) returns current->real_cred (the
> NFSD's credential). And the overridden credentials by access(2) lost.
> 
> Is my guess correct?

Linus please revert d2a7009f0bb03fa22ad08dd25472efa0568126b9

Your explanation seems plausible.  I will review the rest and make sure
a similar problem was not introduced elsewhere.

-Eric