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.

Sign up for GitHub

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

Jump to bottom

SELinux policy modifications override new policies during upgrades #27

Closed
cgwalters opened this issue Sep 16, 2014 · 3 comments
Closed

SELinux policy modifications override new policies during upgrades #27

cgwalters opened this issue Sep 16, 2014 · 3 comments
Labels
bug kind/enhancement

Comments

@cgwalters
Copy link
Member

See http://marc.info/?l=selinux&m=139576819325212&w=2
@jlebon jlebon mentioned this issue Apr 4, 2016
Closed
@cgwalters cgwalters mentioned this issue Aug 23, 2016
Closed
@cgwalters cgwalters mentioned this issue Sep 21, 2017
Closed
@jlebon
Copy link
Member

jlebon commented Jan 23, 2018

Just putting this here for others that get here:

One easy way to work around this is to just apply your modifications non-persistently at boot time using a systemd service. E.g. in the simple case, you can systemctl enable rc-local.service, and shove setsebool virt_use_nfs on in /etc/rc.d/rc.local. Of course, if the modifications need to be applied before some other service starts up, you should use a proper service unit file with the appropriate ordering semantics.

@jlebon jlebon changed the title upgrade with custom selinux policies SELinux policy modifications are lost during upgrades Jan 23, 2018
@jlebon jlebon changed the title SELinux policy modifications are lost during upgrades SELinux policy modifications override new policies during upgrades Jan 23, 2018
@jlebon jlebon mentioned this issue Jan 29, 2018
Merged
@cgwalters cgwalters mentioned this issue Feb 15, 2018
Open
@jlebon jlebon mentioned this issue Jun 26, 2018
Closed
@coreosbot coreosbot mentioned this issue Jul 10, 2018
Closed
@jlebon jlebon mentioned this issue Jan 21, 2020
Closed
@jlebon jlebon mentioned this issue Feb 3, 2020
Open
@jlebon
Copy link
Member

jlebon commented Feb 21, 2020

Discussions about this in coreos/fedora-coreos-tracker#368.

@jlebon jlebon mentioned this issue Feb 27, 2020
Closed
This was referenced Dec 16, 2020
Closed
Open
cgwalters referenced this issue in cgwalters/rpm-ostree Feb 2, 2021
@cgwalters
scripts: Fix a stack use-after-free
ebb0a40 
I think this changed in a recent refactoring; basically since
we're passing this stack-allocated value to the child spawn
function we need to keep it alive.  This of course would
have been caught by Rust...

```
==672376==ERROR: AddressSanitizer: stack-use-after-scope on address 0x7ffc290d9440 at pc 0x55c88c318946 bp 0x7ffc290d8b10 sp 0x7ffc290d8b08
    #0 0x55c88c318945 in script_child_setup src/libpriv/rpmostree-scripts.cxx:272
    #1 0x7f92089da902  (/lib64/libglib-2.0.so.0+0x9f902)
    #2 0x7f92089de20f  (/lib64/libglib-2.0.so.0+0xa320f)
    #3 0x7f92089de52e  (/lib64/libglib-2.0.so.0+0xa352e)
    #4 0x7f92089def02 in g_spawn_async_with_pipes (/lib64/libglib-2.0.so.0+0xa3f02)
    #5 0x7f9208b7445f  (/lib64/libgio-2.0.so.0+0xab45f)
    #6 0x7f9208b736d8 in g_subprocess_launcher_spawnv (/lib64/libgio-2.0.so.0+0xaa6d8)
    #7 0x55c88c3831b9 in rpmostree_bwrap_execute src/libpriv/rpmostree-bwrap.cxx:504
    #8 0x55c88c3836df in rpmostree_bwrap_run_captured src/libpriv/rpmostree-bwrap.cxx:450
    #9 0x55c88c31b5f1 in rpmostree_run_script_in_bwrap_container src/libpriv/rpmostree-scripts.cxx:469
    #10 0x55c88c31ca9d in impl_run_rpm_script src/libpriv/rpmostree-scripts.cxx:588
    #11 0x55c88c31d22b in run_script src/libpriv/rpmostree-scripts.cxx:637
    #12 0x55c88c31d22b in rpmostree_script_run_sync src/libpriv/rpmostree-scripts.cxx:778
    #13 0x55c88c2ef830 in run_script_sync src/libpriv/rpmostree-core.cxx:3661
    #14 0x55c88c30afa6 in rpmostree_context_assemble src/libpriv/rpmostree-core.cxx:4422
    #15 0x55c88c34a9af in install_packages src/app/rpmostree-compose-builtin-tree.cxx:451
    #16 0x55c88c34c174 in impl_install_tree src/app/rpmostree-compose-builtin-tree.cxx:925
    #17 0x55c88c350f84 in rpmostree_compose_builtin_tree src/app/rpmostree-compose-builtin-tree.cxx:1421
    #18 0x55c88c276ec8 in rpmostree_handle_subcommand src/app/libmain.cxx:405
    #19 0x55c88c27827c in rpmostree_main_inner src/app/libmain.cxx:521
    #20 0x55c88c27827c in rpmostreecxx::rpmostree_main(rust::cxxbridge1::Slice<rust::cxxbridge1::Str const>) src/app/libmain.cxx:546
    #21 0x55c88c271c25 in operator() /var/srv/walters/src/github/coreos/rpm-ostree/rpmostree-cxxrs.cxx:1257
    #22 0x55c88c271c25 in trycatch<rpmostreecxx::rpmostreecxx$cxxbridge1$rpmostree_main(rust::cxxbridge1::Slice<const rust::cxxbridge1::Str>)::<lambda()>, rpmostreecxx::rpmostreecxx$cxxbridge1$rpmostree_main(rust::cxxbridge1::Slice<const rust::cxxbridge1::Str>)::<lambda(char const*)> > /var/srv/walters/src/github/coreos/rpm-ostree/rpmostree-cxxrs.cxx:997
    #23 0x55c88c271c25 in rpmostreecxx$cxxbridge1$rpmostree_main /var/srv/walters/src/github/coreos/rpm-ostree/rpmostree-cxxrs.cxx:1255
    #24 0x55c88c0468f7 in rpmostree_rust::ffi::rpmostree_main::hfedda48c684245ce rust/src/lib.rs:25
    #25 0x55c88c0468f7 in rpm_ostree::inner_main::hf078b99ca4b270aa rust/src/main.rs:9
    #26 0x55c88c0468f7 in rpm_ostree::main::hc0ca527cfaa3f556 rust/src/main.rs:28
    #27 0x55c88c046b22 in core::ops::function::FnOnce::call_once::h8567110dac55274e /var/home/walters/.rustup/toolchains/1.48-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/ops/function.rs:227
    #28 0x55c88c046b22 in std::sys_common::backtrace::__rust_begin_short_backtrace::h1c67f2f52d05cfa0 /var/home/walters/.rustup/toolchains/1.48-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/std/src/sys_common/backtrace.rs:137
    #29 0x55c88c045fd7 in main (/usr/bin/rpm-ostree+0xc9fd7)
    #30 0x7f92076091e1 in __libc_start_main (/lib64/libc.so.6+0x281e1)
    #31 0x55c88c045b9d in _start (/usr/bin/rpm-ostree+0xc9b9d)

Address 0x7ffc290d9440 is located in stack of thread T0 at offset 272 in frame
    #0 0x55c88c31a1af in rpmostree_run_script_in_bwrap_container src/libpriv/rpmostree-scripts.cxx:349
```
cgwalters referenced this issue in cgwalters/rpm-ostree Feb 3, 2021
@cgwalters
scripts: Fix a stack use-after-free
184d641 
I think this changed in a recent refactoring; basically since
we're passing this stack-allocated value to the child spawn
function we need to keep it alive.  This of course would
have been caught by Rust...

```
==672376==ERROR: AddressSanitizer: stack-use-after-scope on address 0x7ffc290d9440 at pc 0x55c88c318946 bp 0x7ffc290d8b10 sp 0x7ffc290d8b08
    #0 0x55c88c318945 in script_child_setup src/libpriv/rpmostree-scripts.cxx:272
    #1 0x7f92089da902  (/lib64/libglib-2.0.so.0+0x9f902)
    #2 0x7f92089de20f  (/lib64/libglib-2.0.so.0+0xa320f)
    #3 0x7f92089de52e  (/lib64/libglib-2.0.so.0+0xa352e)
    #4 0x7f92089def02 in g_spawn_async_with_pipes (/lib64/libglib-2.0.so.0+0xa3f02)
    #5 0x7f9208b7445f  (/lib64/libgio-2.0.so.0+0xab45f)
    #6 0x7f9208b736d8 in g_subprocess_launcher_spawnv (/lib64/libgio-2.0.so.0+0xaa6d8)
    #7 0x55c88c3831b9 in rpmostree_bwrap_execute src/libpriv/rpmostree-bwrap.cxx:504
    #8 0x55c88c3836df in rpmostree_bwrap_run_captured src/libpriv/rpmostree-bwrap.cxx:450
    #9 0x55c88c31b5f1 in rpmostree_run_script_in_bwrap_container src/libpriv/rpmostree-scripts.cxx:469
    #10 0x55c88c31ca9d in impl_run_rpm_script src/libpriv/rpmostree-scripts.cxx:588
    #11 0x55c88c31d22b in run_script src/libpriv/rpmostree-scripts.cxx:637
    #12 0x55c88c31d22b in rpmostree_script_run_sync src/libpriv/rpmostree-scripts.cxx:778
    #13 0x55c88c2ef830 in run_script_sync src/libpriv/rpmostree-core.cxx:3661
    #14 0x55c88c30afa6 in rpmostree_context_assemble src/libpriv/rpmostree-core.cxx:4422
    #15 0x55c88c34a9af in install_packages src/app/rpmostree-compose-builtin-tree.cxx:451
    #16 0x55c88c34c174 in impl_install_tree src/app/rpmostree-compose-builtin-tree.cxx:925
    #17 0x55c88c350f84 in rpmostree_compose_builtin_tree src/app/rpmostree-compose-builtin-tree.cxx:1421
    #18 0x55c88c276ec8 in rpmostree_handle_subcommand src/app/libmain.cxx:405
    #19 0x55c88c27827c in rpmostree_main_inner src/app/libmain.cxx:521
    #20 0x55c88c27827c in rpmostreecxx::rpmostree_main(rust::cxxbridge1::Slice<rust::cxxbridge1::Str const>) src/app/libmain.cxx:546
    #21 0x55c88c271c25 in operator() /var/srv/walters/src/github/coreos/rpm-ostree/rpmostree-cxxrs.cxx:1257
    #22 0x55c88c271c25 in trycatch<rpmostreecxx::rpmostreecxx$cxxbridge1$rpmostree_main(rust::cxxbridge1::Slice<const rust::cxxbridge1::Str>)::<lambda()>, rpmostreecxx::rpmostreecxx$cxxbridge1$rpmostree_main(rust::cxxbridge1::Slice<const rust::cxxbridge1::Str>)::<lambda(char const*)> > /var/srv/walters/src/github/coreos/rpm-ostree/rpmostree-cxxrs.cxx:997
    #23 0x55c88c271c25 in rpmostreecxx$cxxbridge1$rpmostree_main /var/srv/walters/src/github/coreos/rpm-ostree/rpmostree-cxxrs.cxx:1255
    #24 0x55c88c0468f7 in rpmostree_rust::ffi::rpmostree_main::hfedda48c684245ce rust/src/lib.rs:25
    #25 0x55c88c0468f7 in rpm_ostree::inner_main::hf078b99ca4b270aa rust/src/main.rs:9
    #26 0x55c88c0468f7 in rpm_ostree::main::hc0ca527cfaa3f556 rust/src/main.rs:28
    #27 0x55c88c046b22 in core::ops::function::FnOnce::call_once::h8567110dac55274e /var/home/walters/.rustup/toolchains/1.48-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/ops/function.rs:227
    #28 0x55c88c046b22 in std::sys_common::backtrace::__rust_begin_short_backtrace::h1c67f2f52d05cfa0 /var/home/walters/.rustup/toolchains/1.48-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/std/src/sys_common/backtrace.rs:137
    #29 0x55c88c045fd7 in main (/usr/bin/rpm-ostree+0xc9fd7)
    #30 0x7f92076091e1 in __libc_start_main (/lib64/libc.so.6+0x281e1)
    #31 0x55c88c045b9d in _start (/usr/bin/rpm-ostree+0xc9b9d)

Address 0x7ffc290d9440 is located in stack of thread T0 at offset 272 in frame
    #0 0x55c88c31a1af in rpmostree_run_script_in_bwrap_container src/libpriv/rpmostree-scripts.cxx:349
```
openshift-merge-robot pushed a commit that referenced this issue Feb 3, 2021
@cgwalters @openshift-merge-robot
scripts: Fix a stack use-after-free
d616f73 
I think this changed in a recent refactoring; basically since
we're passing this stack-allocated value to the child spawn
function we need to keep it alive.  This of course would
have been caught by Rust...

```
==672376==ERROR: AddressSanitizer: stack-use-after-scope on address 0x7ffc290d9440 at pc 0x55c88c318946 bp 0x7ffc290d8b10 sp 0x7ffc290d8b08
    #0 0x55c88c318945 in script_child_setup src/libpriv/rpmostree-scripts.cxx:272
    #1 0x7f92089da902  (/lib64/libglib-2.0.so.0+0x9f902)
    #2 0x7f92089de20f  (/lib64/libglib-2.0.so.0+0xa320f)
    #3 0x7f92089de52e  (/lib64/libglib-2.0.so.0+0xa352e)
    #4 0x7f92089def02 in g_spawn_async_with_pipes (/lib64/libglib-2.0.so.0+0xa3f02)
    #5 0x7f9208b7445f  (/lib64/libgio-2.0.so.0+0xab45f)
    #6 0x7f9208b736d8 in g_subprocess_launcher_spawnv (/lib64/libgio-2.0.so.0+0xaa6d8)
    #7 0x55c88c3831b9 in rpmostree_bwrap_execute src/libpriv/rpmostree-bwrap.cxx:504
    #8 0x55c88c3836df in rpmostree_bwrap_run_captured src/libpriv/rpmostree-bwrap.cxx:450
    #9 0x55c88c31b5f1 in rpmostree_run_script_in_bwrap_container src/libpriv/rpmostree-scripts.cxx:469
    #10 0x55c88c31ca9d in impl_run_rpm_script src/libpriv/rpmostree-scripts.cxx:588
    #11 0x55c88c31d22b in run_script src/libpriv/rpmostree-scripts.cxx:637
    #12 0x55c88c31d22b in rpmostree_script_run_sync src/libpriv/rpmostree-scripts.cxx:778
    #13 0x55c88c2ef830 in run_script_sync src/libpriv/rpmostree-core.cxx:3661
    #14 0x55c88c30afa6 in rpmostree_context_assemble src/libpriv/rpmostree-core.cxx:4422
    #15 0x55c88c34a9af in install_packages src/app/rpmostree-compose-builtin-tree.cxx:451
    #16 0x55c88c34c174 in impl_install_tree src/app/rpmostree-compose-builtin-tree.cxx:925
    #17 0x55c88c350f84 in rpmostree_compose_builtin_tree src/app/rpmostree-compose-builtin-tree.cxx:1421
    #18 0x55c88c276ec8 in rpmostree_handle_subcommand src/app/libmain.cxx:405
    #19 0x55c88c27827c in rpmostree_main_inner src/app/libmain.cxx:521
    #20 0x55c88c27827c in rpmostreecxx::rpmostree_main(rust::cxxbridge1::Slice<rust::cxxbridge1::Str const>) src/app/libmain.cxx:546
    #21 0x55c88c271c25 in operator() /var/srv/walters/src/github/coreos/rpm-ostree/rpmostree-cxxrs.cxx:1257
    #22 0x55c88c271c25 in trycatch<rpmostreecxx::rpmostreecxx$cxxbridge1$rpmostree_main(rust::cxxbridge1::Slice<const rust::cxxbridge1::Str>)::<lambda()>, rpmostreecxx::rpmostreecxx$cxxbridge1$rpmostree_main(rust::cxxbridge1::Slice<const rust::cxxbridge1::Str>)::<lambda(char const*)> > /var/srv/walters/src/github/coreos/rpm-ostree/rpmostree-cxxrs.cxx:997
    #23 0x55c88c271c25 in rpmostreecxx$cxxbridge1$rpmostree_main /var/srv/walters/src/github/coreos/rpm-ostree/rpmostree-cxxrs.cxx:1255
    #24 0x55c88c0468f7 in rpmostree_rust::ffi::rpmostree_main::hfedda48c684245ce rust/src/lib.rs:25
    #25 0x55c88c0468f7 in rpm_ostree::inner_main::hf078b99ca4b270aa rust/src/main.rs:9
    #26 0x55c88c0468f7 in rpm_ostree::main::hc0ca527cfaa3f556 rust/src/main.rs:28
    #27 0x55c88c046b22 in core::ops::function::FnOnce::call_once::h8567110dac55274e /var/home/walters/.rustup/toolchains/1.48-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/ops/function.rs:227
    #28 0x55c88c046b22 in std::sys_common::backtrace::__rust_begin_short_backtrace::h1c67f2f52d05cfa0 /var/home/walters/.rustup/toolchains/1.48-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/std/src/sys_common/backtrace.rs:137
    #29 0x55c88c045fd7 in main (/usr/bin/rpm-ostree+0xc9fd7)
    #30 0x7f92076091e1 in __libc_start_main (/lib64/libc.so.6+0x281e1)
    #31 0x55c88c045b9d in _start (/usr/bin/rpm-ostree+0xc9b9d)

Address 0x7ffc290d9440 is located in stack of thread T0 at offset 272 in frame
    #0 0x55c88c31a1af in rpmostree_run_script_in_bwrap_container src/libpriv/rpmostree-scripts.cxx:349
```
@cgwalters
Copy link
Member Author

Closing as this should be fixed since ostreedev/ostree#2569 in ostree v2022.3.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
bug kind/enhancement
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@cgwalters @jlebon