cmd: add helpers for mounting / unmounting #2827

Merged
merged 9 commits into from Mar 1, 2017

Conversation

Projects
None yet
3 participants
Contributor

zyga commented Feb 9, 2017

This branch adds two helper function for mounting and un-mounting in snap-confine and friends.
The main benefit is that thanks to built-in debugging and error checking mount code can become
much shorter than if it was to be done manually.

Signed-off-by: Zygmunt Krynicki zygmunt.krynicki@canonical.com

zyga added some commits Jan 18, 2017

cmd/libsnap: add sc_do_umount
This patch adds a thin wrapper around umount2(2) that handles logging
and error checking.

Signed-off-by: Zygmunt Krynicki <zygmunt.krynicki@canonical.com>
cmd/libsnap: add sc_do_mount
This patch adds a thin wrapper around the mount system call. This wrapper
handles logging of attempted operations, it also handles errors if they
occur.

Signed-off-by: Zygmunt Krynicki <zygmunt.krynicki@canonical.com>

The code looks ok but I thought we agreed that we were working towards only going through all the string handling debug message code only when sc_is_debug_enabled() (and that in and of itself would become a compile time option). I'd prefer that the calls to ensure_mount_cmd() only be used with debug() and not die() (indeed, if we are only showing them with debugging enabled, the output from die() becomes redundant).

cmd/libsnap-confine-private/mount-opt.c
+ }
+ }
+
+ if (sc_is_debug_enabled()) {
@jdstrand

jdstrand Feb 14, 2017

Contributor

Note that sc_is_debug_enabled() is still only looking at SNAP_CONFINE_DEBUG, so an attacker can set that and have the whole string handling attack surface. I thought there were plans to make this compile time?

@zyga

zyga Feb 14, 2017

Contributor

I must have misunderstood then. I didn't think we agreed to compile-time only debug. If this is the case let's discuss this further because I would find this much more complicated and less useful for actual analysis.

I am also somewhat sceptical about not using this when we are about to die. This is exactly the sort of message that we will get in bug reports. Having no useful data in there will just make everything harder to analyse. What is the reason you would not like to format that when we are about to die?

@jdstrand

jdstrand Feb 14, 2017

Contributor

The reason is because this is an ever-growing setuid executable and I'm trying to keep the attack surface as small as possible. sc_mount_cmd() contains a lot of string handling and I'd like to err on the side of extreme caution.

cmd/libsnap-confine-private/mount-opt.c
+ || mount(source, target, fs_type, mountflags, data) < 0) {
+ // Save errno as ensure can clobber it.
+ int saved_errno = errno;
+ ensure_mount_cmd();
@jdstrand

jdstrand Feb 14, 2017

Contributor

This means that a failed mount goes through the whole string handling machinery of sc_mount_cmd() which I thought we agreed we would only do in debug mode, not production mode.

@zyga

zyga Feb 14, 2017

Contributor

Replied above

cmd/libsnap-confine-private/mount-opt.c
+ if (sc_faulty("umount", NULL) || umount2(target, flags) < 0) {
+ // Save errno as ensure can clobber it.
+ int saved_errno = errno;
+ ensure_umount_cmd();
@jdstrand

jdstrand Feb 14, 2017

Contributor

Same here.

Contributor

zyga commented Feb 14, 2017

I just discussed this with jamie on IRC and the agreement is to use the new debugging messages when debug is enabled (runtime choice) but only die with the new message after permanently dropping privileges.

Contributor

zyga commented Feb 14, 2017

The privilege separation helpers are on #2852

Contributor

zyga commented Feb 16, 2017

The privilege dropping code is now used before constructing a non-debug error message.

zyga added some commits Feb 17, 2017

cmd/snap-confine: drop privileges before formatting mount error message
Signed-off-by: Zygmunt Krynicki <zygmunt.krynicki@canonical.com>
cmd/libsnap: tweak code readability
Signed-off-by: Zygmunt Krynicki <zygmunt.krynicki@canonical.com>
cmd/libsnap: link libcap statically
This patch hacks Makefile.am so that libcap is linked statically while
everything else is not.

Signed-off-by: Zygmunt Krynicki <zygmunt.krynicki@canonical.com>
cmd/libsnap-confine-private/mount-opt.c
+ if (sc_is_debug_enabled()) {
+ ensure_mount_cmd();
+ debug("performing operation: %s", mount_cmd);
+ }
@jdstrand

jdstrand Feb 21, 2017

Contributor

You didn't drop privs here. Perhaps drop this stanza?

@zyga

zyga Feb 23, 2017

Contributor

Done now, this is constrained to a -debug build.

zyga added some commits Feb 23, 2017

cmd: add snap-confine-debug
This patch adds a second build of snap-confine that comes with
additional debugging output that is disabled at compile time in the
regular version. The setuid-root version cannot have this additional
(runtime-enabled) output as it might be used as an attack vector.

Signed-off-by: Zygmunt Krynicki <zygmunt.krynicki@canonical.com>
cmd/libsnap: constrain mount debug to -debug builds
In the non-debug build of snap-confine (the one that is setuid-root) we
will only print mount/umount debug data when we're about to die and
privileges are dropped.

In the -debug build we generate such messages (with all the added
complexity) depending on the runtime switch via the environment variable
(SNAP_CONFINE_DEBUG=yes)

The -debug build is not currently installed but we can eventually
install it (without any security elevation mechanism) and come up with a
way to use it (e.g. via a bind mount).

Signed-off-by: Zygmunt Krynicki <zygmunt.krynicki@canonical.com>

@zyga zyga requested a review from jdstrand Mar 1, 2017

@zyga zyga merged commit 0e9407c into snapcore:master Mar 1, 2017

5 of 6 checks passed

zesty-amd64 autopkgtest finished (failure)
Details
continuous-integration/travis-ci/pr The Travis CI build passed
Details
xenial-amd64 autopkgtest finished (success)
Details
xenial-i386 autopkgtest finished (success)
Details
xenial-ppc64el autopkgtest finished (success)
Details
yakkety-amd64 autopkgtest finished (success)
Details

@zyga zyga deleted the zyga:mount-helpers branch Mar 1, 2017

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment