New issue
Advanced search Search tips
Note: Color blocks (like █ or █) mean that a user may not be available. Tooltip shows the reason.

Issue 826587 link

Starred by 0 users
Status: Assigned
Owner:
kroot@chromium.org
Cc:
kerrnel@chromium.org
xzhou@chromium.org
mnissler@chromium.org
vapier@chromium.org
kroot@chromium.org
█ f...@chromium.org
mortonm@chromium.org
hidehiko@chromium.org
nya@chromium.org
Components:
EstimatedDays: ----
NextAction: ----
OS: Chrome
Pri: 3
Type: Bug



Sign in to add a comment

selinux labels not applied during emerge time (causing cros deploy to break packages in randomly due to incorrect contexts)

Project Member Reported by vapier@chromium.org, Mar 28 2018 
the way we integrate selinux labels atm is at build_image time:
src/scripts/build_library/base_image_util.sh:create_base_image:
  # Restore the extended attributes of necessary files.
  local selinux_config="${BOARD_ROOT}/etc/selinux/config"
  if [[ -e "${selinux_config}" ]]; then
    local selinux_type="$(source "${selinux_config}" && echo "${SELINUXTYPE}")"
    local file_contexts="${BOARD_ROOT}/etc/selinux/${selinux_type}/contexts/files/file_contexts"
    # If the selinux_config file exists, file_contexts must also.
    if ! [[ -e "${file_contexts}" ]]; then
      local err_msg="The SELinux config file exists at ${selinux_config}, "
      err_msg+="but an SELinux context file not found at ${file_contexts}."
      die_notrace "${err_msg}"
    fi
    sudo /sbin/setfiles -r "${root_fs_dir}" "${file_contexts}" "${root_fs_dir}"
  fi

this means that the selinux contexts are fixed at build_image time, but any time we try to use `cros deploy`, any files listed in there get the wrong context (unlabeled), and then break in fun ways when we try to use ARC++.  for example, `cros deploy upstart` and then run ARC++ tests and they fail.

portage & tar have support for preserving selinux labels.  we need to move per-package selinux labels from this centralized db and to the respective projects so they're always labeled correctly.

Comment 1 by mnissler@chromium.org, Mar 28 2018

Owner: elijahtaylor@chromium.org
Repro steps:

1. Build and run betty image in VM
2. test_that --board $BOARD localhost:9222 cheets_StartAndroid.smoke   # verify that the smoke tests pass
3. cros deploy --board $BOARD --no-ping localhost:9222 upstart
4. ssh root@localhost:9222 -- reboot
5. test_that --board $BOARD localhost:9222 cheets_StartAndroid.smoke   # observe that the smoke tests fail now

Passing to Elijah for routing.

Comment 2 by hidehiko@chromium.org, Mar 28 2018

Cc: kroot@chromium.org
> portage & tar have support for preserving selinux labels.  we need to move per-package selinux labels from this centralized db and to the respective projects so they're always labeled correctly.
 
vapier@, could you share the pointer for document etc. about this feature?

Comment 3 by vapier@chromium.org, Mar 29 2018 

we have FEATURES=xattr and USE=xattr turned on already in the sdk.  we might have to turn on USE=selinux for tar & portage in the sdk.

from there, upstream Gentoo has a number of selinux eclasses to apply labels at build time.  we could use those, or build up our own, and then update ebuilds/bashrc hooks to apply them during src_install.

then portage should save+restore things on the fly.

if the selinux context file was split out into a dedicated package, i think that'd let it still change on a per-release basis, and the selinux eclasses could refer to that when applying labels.  that way we wouldn't have to blow up the selinux policy into multiple packages directly which might be problematic when dealing with diff Android releases.

Comment 4 by kinaba@chromium.org, Jul 11

Cc: f...@chromium.org

Comment 5 by la...@chromium.org, Jul 13

Status: Assigned (was: Available)

Comment 6 by kroot@google.com, Aug 22

Owner: kroot@chromium.org
Not having this is breaking "cros deploy" for things that have enforced policy since more CrOS packages are being labelled. I'll take a look at what vapier@ suggested in comment 3.

Comment 7 by kroot@chromium.org, Aug 22 

So it looks like this would depend on the build host's kernel supporting SELinux.

Another idea without requiring build host to support SELinux is to change chromite/lib/remote_access.py to run restorecon after a CopyToDevice call.

Comment 8 by vapier@chromium.org, Aug 22 

the host kernel already has to support selinux in order to run restorecon today, so that's not a new thing, and i haven't seen any complaints thus far.

whether the FS where the sdk chroot is hosted has selinux/xattrs enabled is a new requirement, and our other solutions for xattr usage includes a fallback at postinst time (fcaps) via the ebuild/eclass itself.
►

Sign in to add a comment