[GIT] Security updates for 3.3: SELinux
James Morris
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(-)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majo...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Linus Torvalds
>
> �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
James Morris
> 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
<jmo...@namei.org>
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
Eric Paris
> 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