[PATCH 0/2] cifs-utils: update the cap bounding set only when CAP_SETPCAP is given

[PATCH 0/2] cifs-utils: update the cap bounding set only when CAP_SETPCAP is given

[Jonas Witschel]

libcap-ng 0.8.1 tightened the error checking on capng_apply [1], returning an
error of -4 [2] when trying to update the capability bounding set without
having the CAP_SETPCAP capability to be able to do so.

Existing applications need to accommodate these changes [3], see e.g. the
corresponding changes in GNOME Keyring [4].

This patch series fixes mount.cifs and cifs.upall to work with libcapn-ng
0.8.1, while maintaining backwards compatibility with previous versions.

[1] https://github.com/stevegrubb/libcap-ng/commit/6a24a9c5e2f3af1d56430417ee8c9a04ead38e6c
[2] https://github.com/stevegrubb/libcap-ng/commit/2ab6a03b78cfa7620641c772d13ddbf3b405576b
[3] https://github.com/stevegrubb/libcap-ng/issues/21
[4] https://gitlab.gnome.org/GNOME/gnome-keyring/-/commit/ebc7bc9efacc17049e54da8d96a4a29943621113

Jonas Witschel (2):
  mount.cifs: update the cap bounding set only when CAP_SETPCAP is given
  cifs.upall: update the cap bounding set only when CAP_SETPCAP is given

 cifs.upcall.c | 7 ++++++-
 mount.cifs.c  | 7 ++++++-
 2 files changed, 12 insertions(+), 2 deletions(-)

-- 
2.29.2

[PATCH 1/2] mount.cifs: update the cap bounding set only when CAP_SETPCAP is given

[Jonas Witschel]

libcap-ng 0.8.1 tightened the error checking on capng_apply, returning an error
of -4 when trying to update the capability bounding set without having the
CAP_SETPCAP capability to be able to do so. Previous versions of libcap-ng
silently skipped updating the bounding set and only updated the normal
CAPNG_SELECT_CAPS capabilities instead.

Check beforehand whether we have CAP_SETPCAP, in which case we can use
CAPNG_SELECT_BOTH to update both the normal capabilities and the bounding set.
Otherwise, we can at least update the normal capabilities, but refrain from
trying to update the bounding set to avoid getting an error.

Signed-off-by: Jonas Witschel <diabonas@archlinux.org>
---
 mount.cifs.c | 7 ++++++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/mount.cifs.c b/mount.cifs.c
index 4feb397..88b8b69 100644
--- a/mount.cifs.c
+++ b/mount.cifs.c
@@ -338,6 +338,8 @@ static int set_password(struct parsed_mount_info *parsed_info, const char *src)
 static int
 drop_capabilities(int parent)
 {
+	capng_select_t set = CAPNG_SELECT_CAPS;
+
 	capng_setpid(getpid());
 	capng_clear(CAPNG_SELECT_BOTH);
 	if (parent) {
@@ -355,7 +357,10 @@ drop_capabilities(int parent)
 			return EX_SYSERR;
 		}
 	}
-	if (capng_apply(CAPNG_SELECT_BOTH)) {
+	if (capng_have_capability(CAPNG_EFFECTIVE, CAP_SETPCAP)) {
+		set = CAPNG_SELECT_BOTH;
+	}
+	if (capng_apply(set)) {
 		fprintf(stderr, "Unable to apply new capability set.\n");
 		return EX_SYSERR;
 	}
-- 
2.29.2

[PATCH 2/2] cifs.upall: update the cap bounding set only when CAP_SETPCAP is given

[Jonas Witschel]

libcap-ng 0.8.1 tightened the error checking on capng_apply, returning an error
of -4 when trying to update the capability bounding set without having the
CAP_SETPCAP capability to be able to do so. Previous versions of libcap-ng
silently skipped updating the bounding set and only updated the normal
CAPNG_SELECT_CAPS capabilities instead.

Check beforehand whether we have CAP_SETPCAP, in which case we can use
CAPNG_SELECT_BOTH to update both the normal capabilities and the bounding set.
Otherwise, we can at least update the normal capabilities, but refrain from
trying to update the bounding set to avoid getting an error.

Signed-off-by: Jonas Witschel <diabonas@archlinux.org>
---
 cifs.upcall.c | 7 ++++++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/cifs.upcall.c b/cifs.upcall.c
index 1559434..af1a0b0 100644
--- a/cifs.upcall.c
+++ b/cifs.upcall.c
@@ -88,6 +88,8 @@ typedef enum _sectype {
 static int
 trim_capabilities(bool need_environ)
 {
+	capng_select_t set = CAPNG_SELECT_CAPS;
+
 	capng_clear(CAPNG_SELECT_BOTH);
 
 	/* SETUID and SETGID to change uid, gid, and grouplist */
@@ -105,7 +107,10 @@ trim_capabilities(bool need_environ)
 		return 1;
 	}
 
-	if (capng_apply(CAPNG_SELECT_BOTH)) {
+	if (capng_have_capability(CAPNG_EFFECTIVE, CAP_SETPCAP)) {
+		set = CAPNG_SELECT_BOTH;
+	}
+	if (capng_apply(set)) {
 		syslog(LOG_ERR, "%s: Unable to apply capability set: %m\n", __func__);
 		return 1;
 	}
-- 
2.29.2

Re: [PATCH 0/2] cifs-utils: update the cap bounding set only when CAP_SETPCAP is given

[Aurélien Aptel]

Hi Jonas,

This sounds good but I'm not very familiar with libcap, any ideas how we
can test those code paths?

Cheers,
-- 
Aurélien Aptel / SUSE Labs Samba Team
GPG: 1839 CB5F 9F5B FB9B AA97  8C99 03C8 A49B 521B D5D3
SUSE Software Solutions Germany GmbH, Maxfeldstr. 5, 90409 Nürnberg, DE
GF: Felix Imendörffer, Mary Higgins, Sri Rasiah HRB 247165 (AG München)

Re: [PATCH 0/2] cifs-utils: update the cap bounding set only when CAP_SETPCAP is given

[Jonas Witschel]

[-- Attachment #1: Type: text/plain, Size: 1555 bytes --]

Hi Aurélien,

On 2020-11-24 13:11, Aurélien Aptel wrote:
> This sounds good but I'm not very familiar with libcap, any ideas how we
> can test those code paths?

a simple integration test would be trying to run mount.cifs as a setuid binary
with normal user rights. With libcap-ng 0.8.1 and an unpatched version of
cifs-utils 6.11, this will result in the error message "Unable to apply new
capability set."

$ git clone --branch=cifs-utils-6.11 https://git.samba.org/cifs-utils.git
$ cd cifs-utils
$ autoreconf -i
$ ./configure
$ make
$ sudo chown root:root ./mount.cifs
$ sudo chmod u+s ./mount.cifs
$ ./mount.cifs test /mnt
Unable to apply new capability set.

After applying the patch series, mount.cifs will work normally:

$ ./mount.cifs test /mnt
mount.cifs: permission denied: no match for /mnt found in /etc/fstab

For cifs.upcall, I guess this is usually run with elevated privileges, so it
will normally have CAP_SETPCAP, but for testing purposes, we can grant the
necessary capabilities manually and run as a normal user:

$ sudo setcap cap_setuid,cap_setgid,cap_sys_ptrace,cap_dac_read_search=ep ./cifs.upcall
$ ./cifs.upcall

Without the patch, this will fail with an empty stderr and an error of
"trim_capabilities: Unable to apply capability set: Success" in the syslog.
With the patch, applying the capabilities succeeds and the usage information

Usage: cifs.upcall [ -K /path/to/keytab] [-k /path/to/krb5.conf] [-E] [-t] [-v] [-l] [-e nsecs] key_serial

is displayed on stderr.

Best,
Jonas

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [PATCH 0/2] cifs-utils: update the cap bounding set only when CAP_SETPCAP is given

[Aurélien Aptel]

Thanks Jonas this is very helpful.

Cheers,
-- 
Aurélien Aptel / SUSE Labs Samba Team
GPG: 1839 CB5F 9F5B FB9B AA97  8C99 03C8 A49B 521B D5D3
SUSE Software Solutions Germany GmbH, Maxfeldstr. 5, 90409 Nürnberg, DE
GF: Felix Imendörffer, Mary Higgins, Sri Rasiah HRB 247165 (AG München)

Re: [PATCH 0/2] cifs-utils: update the cap bounding set only when CAP_SETPCAP is given

[Pavel Shilovsky]

Merged into the "next" branch. Thanks!
--
Best regards,
Pavel Shilovsky

пт, 27 нояб. 2020 г. в 02:02, Aurélien Aptel <aaptel@suse.com>:
>
>
> Thanks Jonas this is very helpful.
>
> Cheers,
> --
> Aurélien Aptel / SUSE Labs Samba Team
> GPG: 1839 CB5F 9F5B FB9B AA97  8C99 03C8 A49B 521B D5D3
> SUSE Software Solutions Germany GmbH, Maxfeldstr. 5, 90409 Nürnberg, DE
> GF: Felix Imendörffer, Mary Higgins, Sri Rasiah HRB 247165 (AG München)
>