Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Clear ambient inherited #14133

Merged
merged 3 commits into from
Dec 4, 2019
Merged

Conversation

kkuehlz
Copy link
Contributor

@kkuehlz kkuehlz commented Nov 24, 2019

No description provided.

@kkuehlz
Copy link
Contributor Author

kkuehlz commented Nov 24, 2019

cc @anitazha

@yuwata yuwata added ci-fails/needs-rework 🔥 Please rework this, the CI noticed an issue with the PR pid1 labels Nov 24, 2019
@yuwata
Copy link
Member

yuwata commented Nov 24, 2019

test-load-fragment fails.

@yuwata
Copy link
Member

yuwata commented Nov 24, 2019

What happens when the following is specified?

AmbientCapabilities=CAP_AAA
AmbientCapabilities=clear
AmbientCapabilities=CAP_BBB
AmbientCapabilities=
AmbientCapabilities=CAP_CCC

Also, I think DBus API needs to be updated.

@yuwata yuwata added the reviewed/needs-rework 🔨 PR has been reviewed and needs another round of reworks label Nov 24, 2019
@mrc0mmand
Copy link
Member

==5697==ERROR: AddressSanitizer: stack-use-after-return on address 0x7fab7ca59d18 at pc 0x55ab9274bc57 bp 0x7ffd78d0c5f0 sp 0x7ffd78d0c5e8
READ of size 8 at 0x7fab7ca59d18 thread T0
    #0 0x55ab9274bc56 in config_parse_capability_set /build/build/../src/core/load-fragment.c:1386:25
    #1 0x55ab926e5dea in test_config_parse_capability_set /build/build/../src/test/test-load-fragment.c:582:13
    #2 0x55ab926e1040 in main /build/build/../src/test/test-load-fragment.c:791:9
    #3 0x7fab80ca7152 in __libc_start_main (/lib64/libc.so.6+0x27152)
    #4 0x55ab926e0e5d in _start (/build/build/test-load-fragment+0x2bae5d)

Address 0x7fab7ca59d18 is located in stack of thread T0 at offset 24 in frame
    #0 0x7fab815bf44f in utf8_encoded_valid_unichar /build/build/../src/basic/utf8.c:502

  This frame has 1 object(s):
    [32, 36) 'unichar' (line 503) <== Memory access at offset 24 underflows this variable
HINT: this may be a false positive if your program uses some custom stack unwind mechanism, swapcontext or vfork
      (longjmp and C++ exceptions *are* supported)
SUMMARY: AddressSanitizer: stack-use-after-return /build/build/../src/core/load-fragment.c:1386:25 in config_parse_capability_set
Shadow bytes around the buggy address:
  0x0ff5ef943350: f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5
  0x0ff5ef943360: f1 f1 f1 f1 00 f3 f3 f3 f1 f1 f1 f1 00 f3 f3 f3
  0x0ff5ef943370: f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5
  0x0ff5ef943380: f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5
  0x0ff5ef943390: f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5
=>0x0ff5ef9433a0: f5 f5 f5[f5]f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5
  0x0ff5ef9433b0: f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5
  0x0ff5ef9433c0: f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5
  0x0ff5ef9433d0: f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5
  0x0ff5ef9433e0: f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5
  0x0ff5ef9433f0: f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5
Shadow byte legend (one shadow byte represents 8 application bytes):
  Addressable:           00
  Partially addressable: 01 02 03 04 05 06 07 
  Heap left redzone:       fa
  Freed heap region:       fd
  Stack left redzone:      f1
  Stack mid redzone:       f2
  Stack right redzone:     f3
  Stack after return:      f5
  Stack use after scope:   f8
  Global redzone:          f9
  Global init order:       f6
  Poisoned by user:        f7
  Container overflow:      fc
  Array cookie:            ac
  Intra object redzone:    bb
  ASan internal:           fe
  Left alloca redzone:     ca
  Right alloca redzone:    cb
  Shadow gap:              cc
==5697==ABORTING

@poettering
Copy link
Member

hmm, is this really desirable this way? why not drop all ambient caps by default, and then allow AmbientCapabilities= as a method of passing them along?

@kkuehlz
Copy link
Contributor Author

kkuehlz commented Nov 26, 2019

@poettering Yeah, I definitely agree. Having to specify dropping caps would be an opt in security feature, which is not good. Fixed and force pushed.

cc @yuwata

@yuwata yuwata removed ci-fails/needs-rework 🔥 Please rework this, the CI noticed an issue with the PR reviewed/needs-rework 🔨 PR has been reviewed and needs another round of reworks labels Nov 26, 2019
@@ -138,6 +138,42 @@ int capability_ambient_set_apply(uint64_t set, bool also_inherit) {
return 0;
}

int capability_ambient_set_clear(uint64_t set) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

hmm, iiuc the parameter specifies the ones to keep, right? hence call it "keep" or so, to make this clearer?

return -errno;

return 0;
}
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

shouldn't this be done in capability_ambient_set_apply()? i.e. that the function is changed to drop all ambient caps not specified and set all ambient caps specified? that would be much shorter and simpler and still do what you need, no?

Modify the functions capability_update_inherited_set() and
capability_ambient_set_apply() to drop capabilities not explicitly
requested by the user.
@kkuehlz
Copy link
Contributor Author

kkuehlz commented Nov 26, 2019

@poettering Changes made.

@poettering
Copy link
Member

looks great! one more tiny fix

@kkuehlz
Copy link
Contributor Author

kkuehlz commented Nov 27, 2019

@poettering Fixed and force pushed (also added the assert_se to the other call to cap_get_proc from the existing test)

Change test_set_ambient_caps() to test_apply_ambient_caps(), since the
function capability_ambient_set_apply() not only sets ambient
capabilities, but clears inherited capabilities that are not explicitly
requested by the caller.
The function capability_ambient_set_apply() now drops capabilities not
in the capability_ambient_set(), so it is necessary to call it when
the ambient set is empty.

Fixes systemd#13163
@poettering
Copy link
Member

thanks! lgtm, but let's merge that after the 244 release

@poettering poettering merged commit eaadc03 into systemd:master Dec 4, 2019
kkuehlz added a commit to kkuehlz/systemd that referenced this pull request Mar 27, 2020
systemd#14133 made
capability_ambient_set_apply() acquire capabilities that were explicitly
asked for and drop all others. This change means the function is called
even with an empty capability set, opening up a code path for users
without ambient capabilities to call this function. This function will
error with EINVAL out on kernels < 4.3 because PR_CAP_AMBIENT is not
understood. This turns capability_ambient_set_apply() into a noop for
kernels < 4.3

Fixes systemd#15225
keszybz pushed a commit that referenced this pull request Mar 29, 2020
#14133 made
capability_ambient_set_apply() acquire capabilities that were explicitly
asked for and drop all others. This change means the function is called
even with an empty capability set, opening up a code path for users
without ambient capabilities to call this function. This function will
error with EINVAL out on kernels < 4.3 because PR_CAP_AMBIENT is not
understood. This turns capability_ambient_set_apply() into a noop for
kernels < 4.3

Fixes #15225
keszybz pushed a commit to systemd/systemd-stable that referenced this pull request Apr 1, 2020
systemd/systemd#14133 made
capability_ambient_set_apply() acquire capabilities that were explicitly
asked for and drop all others. This change means the function is called
even with an empty capability set, opening up a code path for users
without ambient capabilities to call this function. This function will
error with EINVAL out on kernels < 4.3 because PR_CAP_AMBIENT is not
understood. This turns capability_ambient_set_apply() into a noop for
kernels < 4.3

Fixes systemd/systemd#15225

(cherry picked from commit 7ea4392)
Yamakuzure pushed a commit to elogind/elogind that referenced this pull request Aug 31, 2020
systemd/systemd#14133 made
capability_ambient_set_apply() acquire capabilities that were explicitly
asked for and drop all others. This change means the function is called
even with an empty capability set, opening up a code path for users
without ambient capabilities to call this function. This function will
error with EINVAL out on kernels < 4.3 because PR_CAP_AMBIENT is not
understood. This turns capability_ambient_set_apply() into a noop for
kernels < 4.3

Fixes systemd/systemd#15225
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Development

Successfully merging this pull request may close these issues.

None yet

5 participants