37863c43b2c6464 KEYS: prevent KEYCTL_READ on negative key

Fixed in chromeos-4.4 with v4.4.92 merge. Theoretically required in older kernels, though there are _lots_ of related unpatched problems in those kernels, and it would not add much value to just fix one.
Merge request is for M-63 and chromeos-4.4 only.

This bug requires manual review: M63 has already been promoted to the beta branch, so this requires manual review
Please contact the milestone owner if you have questions.
Owners: cmasso@(Android), cmasso@(iOS), gkihumba@(ChromeOS), govind@(Desktop)

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

This issue has been approved for a merge. Please merge the fix to any appropriate branches as soon as possible!

If all merges have been completed, please remove any remaining Merge-Approved labels from this issue.

Thanks for your time! To disable nags, add the Disable-Nags label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/third_party/kernel/+/55a0de1556b058d2f6c05a29f3208357d53b3cf0

commit 55a0de1556b058d2f6c05a29f3208357d53b3cf0
Author: Eric Biggers <ebiggers@google.com>
Date: Fri Nov 10 20:49:19 2017

KEYS: prevent creating a different user's keyrings

commit 237bbd29f7a049d310d907f4b2716a7feef9abf3 upstream.

It was possible for an unprivileged user to create the user and user
session keyrings for another user.  For example:

    sudo -u '#3000' sh -c 'keyctl add keyring _uid.4000 "" @u
                           keyctl add keyring _uid_ses.4000 "" @u
                           sleep 15' &
    sleep 1
    sudo -u '#4000' keyctl describe @u
    sudo -u '#4000' keyctl describe @us

This is problematic because these "fake" keyrings won't have the right
permissions.  In particular, the user who created them first will own
them and will have full access to them via the possessor permissions,
which can be used to compromise the security of a user's keys:

    -4: alswrv-----v------------  3000     0 keyring: _uid.4000
    -5: alswrv-----v------------  3000     0 keyring: _uid_ses.4000

Fix it by marking user and user session keyrings with a flag
KEY_FLAG_UID_KEYRING.  Then, when searching for a user or user session
keyring by name, skip all keyrings that don't have the flag set.

BUG= chromium:781520 
TEST=Build and run

Fixes: 69664cf16af4 ("keys: don't generate user and user session keyrings unless they're accessed")
Signed-off-by: Eric Biggers <ebiggers@google.com>
Signed-off-by: David Howells <dhowells@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

(cherry picked from commit 539255aea88e47932a98ba7656775cbca4f3d27c)
Signed-off-by: Guenter Roeck <groeck@chromium.org>

Change-Id: If8c3abffc52354fb2188dd6b9c4b158f2f2e2f0c
Reviewed-on: https://chromium-review.googlesource.com/760896
Reviewed-by: Guenter Roeck <groeck@chromium.org>
Commit-Queue: Guenter Roeck <groeck@chromium.org>
Tested-by: Guenter Roeck <groeck@chromium.org>

[modify] https://crrev.com/55a0de1556b058d2f6c05a29f3208357d53b3cf0/security/keys/internal.h
[modify] https://crrev.com/55a0de1556b058d2f6c05a29f3208357d53b3cf0/security/keys/process_keys.c
[modify] https://crrev.com/55a0de1556b058d2f6c05a29f3208357d53b3cf0/security/keys/keyring.c
[modify] https://crrev.com/55a0de1556b058d2f6c05a29f3208357d53b3cf0/include/linux/key.h
[modify] https://crrev.com/55a0de1556b058d2f6c05a29f3208357d53b3cf0/security/keys/key.c

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/third_party/kernel/+/2477a2a011442f473af6320dedd5ef1aa74abdd5

commit 2477a2a011442f473af6320dedd5ef1aa74abdd5
Author: David Howells <dhowells@redhat.com>
Date: Fri Nov 10 20:49:24 2017

KEYS: Fix race between updating and finding a negative key

commit 363b02dab09b3226f3bd1420dad9c72b79a42a76 upstream.

Consolidate KEY_FLAG_INSTANTIATED, KEY_FLAG_NEGATIVE and the rejection
error into one field such that:

 (1) The instantiation state can be modified/read atomically.

 (2) The error can be accessed atomically with the state.

 (3) The error isn't stored unioned with the payload pointers.

This deals with the problem that the state is spread over three different
objects (two bits and a separate variable) and reading or updating them
atomically isn't practical, given that not only can uninstantiated keys
change into instantiated or rejected keys, but rejected keys can also turn
into instantiated keys - and someone accessing the key might not be using
any locking.

The main side effect of this problem is that what was held in the payload
may change, depending on the state.  For instance, you might observe the
key to be in the rejected state.  You then read the cached error, but if
the key semaphore wasn't locked, the key might've become instantiated
between the two reads - and you might now have something in hand that isn't
actually an error code.

The state is now KEY_IS_UNINSTANTIATED, KEY_IS_POSITIVE or a negative error
code if the key is negatively instantiated.  The key_is_instantiated()
function is replaced with key_is_positive() to avoid confusion as negative
keys are also 'instantiated'.

Additionally, barriering is included:

 (1) Order payload-set before state-set during instantiation.

 (2) Order state-read before payload-read when using the key.

Further separate barriering is necessary if RCU is being used to access the
payload content after reading the payload pointers.

BUG= chromium:781520 
TEST=Build and run

Fixes: 146aa8b1453b ("KEYS: Merge the type-specific data with the payload data")
Reported-by: Eric Biggers <ebiggers@google.com>
Signed-off-by: David Howells <dhowells@redhat.com>
Reviewed-by: Eric Biggers <ebiggers@google.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit 8a004caec12bf241e567e3640401256cc9bc2e45)
Signed-off-by: Guenter Roeck <groeck@chromium.org>

Change-Id: Ic96e3b92d330870f526057ab2a9162be9d8deb4b
Reviewed-on: https://chromium-review.googlesource.com/760897
Reviewed-by: Guenter Roeck <groeck@chromium.org>
Commit-Queue: Guenter Roeck <groeck@chromium.org>
Tested-by: Guenter Roeck <groeck@chromium.org>

[modify] https://crrev.com/2477a2a011442f473af6320dedd5ef1aa74abdd5/security/keys/request_key_auth.c
[modify] https://crrev.com/2477a2a011442f473af6320dedd5ef1aa74abdd5/security/keys/encrypted-keys/encrypted.c
[modify] https://crrev.com/2477a2a011442f473af6320dedd5ef1aa74abdd5/security/keys/key.c
[modify] https://crrev.com/2477a2a011442f473af6320dedd5ef1aa74abdd5/security/keys/user_defined.c
[modify] https://crrev.com/2477a2a011442f473af6320dedd5ef1aa74abdd5/security/keys/keyring.c
[modify] https://crrev.com/2477a2a011442f473af6320dedd5ef1aa74abdd5/security/keys/request_key.c
[modify] https://crrev.com/2477a2a011442f473af6320dedd5ef1aa74abdd5/security/keys/process_keys.c
[modify] https://crrev.com/2477a2a011442f473af6320dedd5ef1aa74abdd5/security/keys/gc.c
[modify] https://crrev.com/2477a2a011442f473af6320dedd5ef1aa74abdd5/security/keys/big_key.c
[modify] https://crrev.com/2477a2a011442f473af6320dedd5ef1aa74abdd5/net/dns_resolver/dns_key.c
[modify] https://crrev.com/2477a2a011442f473af6320dedd5ef1aa74abdd5/security/keys/trusted.c
[modify] https://crrev.com/2477a2a011442f473af6320dedd5ef1aa74abdd5/security/keys/proc.c
[modify] https://crrev.com/2477a2a011442f473af6320dedd5ef1aa74abdd5/include/linux/key.h
[modify] https://crrev.com/2477a2a011442f473af6320dedd5ef1aa74abdd5/security/keys/keyctl.c

This bug has been closed for more than 14 weeks. Removing security view restrictions.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot