summaryrefslogtreecommitdiff
blob: 8b45b293bbf9fccab40c7c80831aa4c3860094f0 (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
From 1a01e1eb870e1ab1d96a8641f1f3500af646c974 Mon Sep 17 00:00:00 2001
From: Fabian Vogt <fabian@ritter-vogt.de>
Date: Thu, 3 Aug 2017 09:27:10 +0200
Subject: Avoid dropping privileges by initializing gcrypt secmem

Summary:
It's a documented side effect that initialization of secure memory in gcrypt
drops privileges if getuid() != geteuid(). This results in breaking setuid
callers, like sudo or su.

Test Plan: Can use sudo again when pam_kwallet is involved.

Reviewers: #plasma

Subscribers: plasma-devel

Tags: #plasma

Differential Revision: https://phabricator.kde.org/D7124
---
 pam_kwallet.c | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/pam_kwallet.c b/pam_kwallet.c
index 46720a5..20d9603 100644
--- a/pam_kwallet.c
+++ b/pam_kwallet.c
@@ -722,12 +722,18 @@ int kwallet_hash(const char *passphrase, struct passwd *userInfo, char *key)
 
     gcry_error_t error;
 
+    /* We cannot call GCRYCTL_INIT_SECMEM as it drops privileges if getuid() != geteuid().
+     * PAM modules are in many cases executed through setuid binaries, which this call
+     * would break.
+     * It was never effective anyway as neither key nor passphrase are in secure memory,
+     * which is a prerequisite for secure operation...
     error = gcry_control(GCRYCTL_INIT_SECMEM, 32768, 0);
     if (error != 0) {
         free(salt);
         syslog(LOG_ERR, "%s-kwalletd: Can't get secure memory: %d", logPrefix, error);
         return 1;
     }
+    */
 
     gcry_control (GCRYCTL_INITIALIZATION_FINISHED, 0);
 
-- 
cgit v0.11.2