linux.git/security, branch v4.4.122

selinux: skip bounded transition processing if the policy isn't loaded

2018-02-25T10:03:36+00:00

commit 4b14752ec4e0d87126e636384cf37c8dd9df157c upstream.

We can't do anything reasonable in security_bounded_transition() if we
don't have a policy loaded, and in fact we could run into problems
with some of the code inside expecting a policy.  Fix these problems
like we do many others in security/selinux/ss/services.c by checking
to see if the policy is loaded (ss_initialized) and returning quickly
if it isn't.

Reported-by: syzbot 
Signed-off-by: Paul Moore 
Acked-by: Stephen Smalley 
Reviewed-by: James Morris 
Signed-off-by: Greg Kroah-Hartman

selinux: ensure the context is NUL terminated in security_context_to_sid_core()

2018-02-25T10:03:36+00:00

commit ef28df55ac27e1e5cd122e19fa311d886d47a756 upstream.

The syzbot/syzkaller automated tests found a problem in
security_context_to_sid_core() during early boot (before we load the
SELinux policy) where we could potentially feed context strings without
NUL terminators into the strcmp() function.

We already guard against this during normal operation (after the SELinux
policy has been loaded) by making a copy of the context strings and
explicitly adding a NUL terminator to the end.  The patch extends this
protection to the early boot case (no loaded policy) by moving the context
copy earlier in security_context_to_sid_core().

Reported-by: syzbot 
Signed-off-by: Paul Moore 
Reviewed-By: William Roberts 
Signed-off-by: Greg Kroah-Hartman

KEYS: encrypted: fix buffer overread in valid_master_desc()

2018-02-16T19:09:38+00:00

commit 794b4bc292f5d31739d89c0202c54e7dc9bc3add upstream.

With the 'encrypted' key type it was possible for userspace to provide a
data blob ending with a master key description shorter than expected,
e.g. 'keyctl add encrypted desc "new x" @s'.  When validating such a
master key description, validate_master_desc() could read beyond the end
of the buffer.  Fix this by using strncmp() instead of memcmp().  [Also
clean up the code to deduplicate some logic.]

Cc: Mimi Zohar 
Signed-off-by: Eric Biggers 
Signed-off-by: David Howells 
Signed-off-by: James Morris 
Signed-off-by: Jin Qian 
Signed-off-by: Greg Kroah-Hartman

selinux: general protection fault in sock_has_perm

2018-02-03T16:04:30+00:00

In the absence of commit a4298e4522d6 ("net: add SOCK_RCU_FREE socket
flag") and all the associated infrastructure changes to take advantage
of a RCU grace period before freeing, there is a heightened
possibility that a security check is performed while an ill-timed
setsockopt call races in from user space.  It then is prudent to null
check sk_security, and if the case, reject the permissions.

Because of the nature of this problem, hard to duplicate, no clear
path, this patch is a simplified band-aid for stable trees lacking the
infrastructure for the series of commits leading up to providing a
suitable RCU grace period.  This adjustment is orthogonal to
infrastructure improvements that may nullify the needed check, but
could be added as good code hygiene in all trees.

general protection fault: 0000 [#1] PREEMPT SMP KASAN
CPU: 1 PID: 14233 Comm: syz-executor2 Not tainted 4.4.112-g5f6325b #28
task: ffff8801d1095f00 task.stack: ffff8800b5950000
RIP: 0010:[]  [] sock_has_perm+0x1fe/0x3e0 security/selinux/hooks.c:4069
RSP: 0018:ffff8800b5957ce0  EFLAGS: 00010202
RAX: dffffc0000000000 RBX: 1ffff10016b2af9f RCX: ffffffff81b69b51
RDX: 0000000000000002 RSI: 0000000000000000 RDI: 0000000000000010
RBP: ffff8800b5957de0 R08: 0000000000000001 R09: 0000000000000001
R10: 0000000000000000 R11: 1ffff10016b2af68 R12: ffff8800b5957db8
R13: 0000000000000000 R14: ffff8800b7259f40 R15: 00000000000000d7
FS:  00007f72f5ae2700(0000) GS:ffff8801db300000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000000a2fa38 CR3: 00000001d7980000 CR4: 0000000000160670
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Stack:
 ffffffff81b69a1f ffff8800b5957d58 00008000b5957d30 0000000041b58ab3
 ffffffff83fc82f2 ffffffff81b69980 0000000000000246 ffff8801d1096770
 ffff8801d3165668 ffffffff8157844b ffff8801d1095f00
 ffff880000000001
Call Trace:
[] selinux_socket_setsockopt+0x4d/0x80 security/selinux/hooks.c:4338
[] security_socket_setsockopt+0x7d/0xb0 security/security.c:1257
[] SYSC_setsockopt net/socket.c:1757 [inline]
[] SyS_setsockopt+0xe8/0x250 net/socket.c:1746
[] entry_SYSCALL_64_fastpath+0x16/0x92
Code: c2 42 9b b6 81 be 01 00 00 00 48 c7 c7 a0 cb 2b 84 e8
f7 2f 6d ff 49 8d 7d 10 48 b8 00 00 00 00 00 fc ff df 48 89
fa 48 c1 ea 03 <0f> b6 04 02 84 c0 74 08 3c 03 0f 8e 83 01 00
00 41 8b 75 10 31
RIP  [] sock_has_perm+0x1fe/0x3e0 security/selinux/hooks.c:4069
RSP 
---[ end trace 7b5aaf788fef6174 ]---

Signed-off-by: Mark Salyzyn 
Acked-by: Paul Moore 
Cc: Eric Dumazet 
Cc: Stephen Smalley 
Cc: selinux@tycho.nsa.gov
Cc: linux-security-module@vger.kernel.org
Cc: Eric Paris 
Cc: Serge E. Hallyn 
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman

KPTI: Rename to PAGE_TABLE_ISOLATION

2018-01-05T14:44:26+00:00

This renames CONFIG_KAISER to CONFIG_PAGE_TABLE_ISOLATION.

Signed-off-by: Kees Cook 
Signed-off-by: Greg Kroah-Hartman

x86/kaiser: Reenable PARAVIRT

2018-01-05T14:44:26+00:00

Now that the required bits have been addressed, reenable
PARAVIRT.

Signed-off-by: Borislav Petkov 
Signed-off-by: Greg Kroah-Hartman

kaiser: delete KAISER_REAL_SWITCH option

2018-01-05T14:44:24+00:00

We fail to see what CONFIG_KAISER_REAL_SWITCH is for: it seems to be
left over from early development, and now just obscures tricky parts
of the code.  Delete it before adding PCIDs, or nokaiser boot option.

(Or if there is some good reason to keep the option, then it needs
a help text - and a "depends on KAISER", so that all those without
KAISER are not asked the question.)

Signed-off-by: Hugh Dickins 
Acked-by: Jiri Kosina 
Signed-off-by: Greg Kroah-Hartman

kaiser: KAISER depends on SMP

2018-01-05T14:44:23+00:00

It is absurd that KAISER should depend on SMP, but apparently nobody
has tried a UP build before: which breaks on implicit declaration of
function 'per_cpu_offset' in arch/x86/mm/kaiser.c.

Now, you would expect that to be trivially fixed up; but looking at
the System.map when that block is #ifdef'ed out of kaiser_init(),
I see that in a UP build __per_cpu_user_mapped_end is precisely at
__per_cpu_user_mapped_start, and the items carefully gathered into
that section for user-mapping on SMP, dispersed elsewhere on UP.

So, some other kind of section assignment will be needed on UP,
but implementing that is not a priority: just make KAISER depend
on SMP for now.

Also inserted a blank line before the option, tidied up the
brief Kconfig help message, and added an "If unsure, Y".

Signed-off-by: Hugh Dickins 
Acked-by: Jiri Kosina 
Signed-off-by: Greg Kroah-Hartman

kaiser: merged update

2018-01-05T14:44:23+00:00

Merged fixes and cleanups, rebased to 4.4.89 tree (no 5-level paging).

Signed-off-by: Dave Hansen 
Signed-off-by: Hugh Dickins 
Acked-by: Jiri Kosina 
Signed-off-by: Greg Kroah-Hartman

KAISER: Kernel Address Isolation

2018-01-05T14:44:23+00:00

This patch introduces our implementation of KAISER (Kernel Address Isolation to
have Side-channels Efficiently Removed), a kernel isolation technique to close
hardware side channels on kernel address information.

More information about the patch can be found on:

        https://github.com/IAIK/KAISER

From: Richard Fellner 
From: Daniel Gruss 
X-Subject: [RFC, PATCH] x86_64: KAISER - do not map kernel in user mode
Date: Thu, 4 May 2017 14:26:50 +0200
Link: http://marc.info/?l=linux-kernel&m=149390087310405&w=2
Kaiser-4.10-SHA1: c4b1831d44c6144d3762ccc72f0c4e71a0c713e5

To: 
To: 
Cc: 
Cc: 
Cc: Michael Schwarz 
Cc: Richard Fellner 
Cc: Ingo Molnar 
Cc: 
Cc: 

After several recent works [1,2,3] KASLR on x86_64 was basically
considered dead by many researchers. We have been working on an
efficient but effective fix for this problem and found that not mapping
the kernel space when running in user mode is the solution to this
problem [4] (the corresponding paper [5] will be presented at ESSoS17).

With this RFC patch we allow anybody to configure their kernel with the
flag CONFIG_KAISER to add our defense mechanism.

If there are any questions we would love to answer them.
We also appreciate any comments!

Cheers,
Daniel (+ the KAISER team from Graz University of Technology)

[1] http://www.ieee-security.org/TC/SP2013/papers/4977a191.pdf
[2] https://www.blackhat.com/docs/us-16/materials/us-16-Fogh-Using-Undocumented-CPU-Behaviour-To-See-Into-Kernel-Mode-And-Break-KASLR-In-The-Process.pdf
[3] https://www.blackhat.com/docs/us-16/materials/us-16-Jang-Breaking-Kernel-Address-Space-Layout-Randomization-KASLR-With-Intel-TSX.pdf
[4] https://github.com/IAIK/KAISER
[5] https://gruss.cc/files/kaiser.pdf

[patch based also on
https://raw.githubusercontent.com/IAIK/KAISER/master/KAISER/0001-KAISER-Kernel-Address-Isolation.patch]

Signed-off-by: Richard Fellner 
Signed-off-by: Moritz Lipp 
Signed-off-by: Daniel Gruss 
Signed-off-by: Michael Schwarz 
Acked-by: Jiri Kosina 
Signed-off-by: Hugh Dickins 
Signed-off-by: Greg Kroah-Hartman